分布式服务治理

从RPC走向服务化

  • 具体分布式业务场景里，除了能够调用远程方法RPC，我们还要考虑什么？
  • 多个服务如何管理？
  • 服务的注册发现机制？
  • 如何负载均衡，路由集群？
  • 熔断，限流等治理能力
  • 心跳，重试等策略

  • 高可用，监控，性能等

    RPC与分布式服务化区别

    RPC

  • 远程过程调用

  • 需要考虑性能优化、易用性优化（spring-boot-starter封装）

  • 系统的功能性需求

    分布式服务化

  • 服务是业务语义，偏向于业务与系统的集成

  • 关键的一部分是如何设计分布式的业务服务

  • 系统的非功能性需求

    分布式服务化与SOA/ESB的区别

    ESB.png
    SOA.png
    分布式服务化.png

  • RPC之上的增强

    • 有状态的部分，放到配置/注册/元数据中心
    • 无状态的部分，放到应用侧（具体来说是框架和配置部分，尽量不影响业务代码）

增强.png

配置/注册/元数据中心

三大中心

  • 配置中心
    • ConfigCenter
    • 管理系统需要的配置参数信息
    • port/threads
  • 注册中心
    • RegistryCenter
    • 管理服务注册/发现/协调
    • 目前可用的服务

  • 元数据中心

    • MetadataCenter
    • 管理各个节点使用的元数据

      对比

  • 相同点

    • 都需要保存和读取数据/状态
    • 都支持变更通知

  • 不同点

    • 配置是全局非业务参数
    • 注册是运行期状态快照
    • 元数据是业务模型

      配置中心

      背景

  • 大规模集群下，如何管理配置信息，特别是批量更新问题

  • 大公司和金融行业，要求开发、测试、运维分离（物理隔离）

  • 运行期的一些开关控制，总不能不断重启？

    解决方案

  • zookeeper

  • etcd
  • nacos

  • apollo

    注册中心

    背景

  • 让消费者动态知道生产者集群的状态变化

  • 集群的管控，分布式服务治理都要考这个状态

    解决方案

  • 早起服务拉起后 echo “ok” > hello.html，消费者请求这个页面

  • DNS
  • VIP
  • LVS

  • 主动报告+心跳（目前主流）

    元数据中心

  • 一般情况下，没有也没问题，有了更好

  • 元数据中心定义了所有业务服务模型

    如何实现

  • 核心要素

    • 需要有存取数据的能力（配置中心、元数据中心），特别是临时数据（注册中心）
    • 数据有更新时有实时通知机制，全量或增量两种方式
  • 主流的基座，一般都可以使用namespace的概念，用来顶层隔离不同环境
  • zk没有，但我们一般用第一个根节点作为namespace/group

实现三大中心.png

ZK

  • 集群大了会有性能问题
  • 一般不使用zk的client，而是使用curator，其带了Guava的Cache，可以不用实时与zk交互

  • zooInspector客户端工具连接zk

    服务的注册/发现

    注册

  • 服务

    • 启动时将自己注册到注册中心的临时节点
    • 停止或宕机时，临时节点消失

  • 数据格式

    • 节点key，代表当前服务，或者服务+版本
    • 多个子节点，每一个为提供者的描述信息

      发现

  • 客户端

    • 从注册中心代表服务的主节点拿到多个代表提供者的临时节点列表，并本地缓存
    • 根据router和loadbalance算法从其中的某一个执行调用
    • 如果可用的提供者集合发生变化，注册中心通知消费者刷新本地缓存的列表

  • zk可以使用curator作为客户端的实现

    服务的集群/路由

    集群

  • 对于完全相同能力的多个服务，希望协同工作，分摊处理流量

    • 路由（多选多）
    • 负载均衡（多选一）

      路由

  • 跟网关的路由一样

    • 基于IP段的过滤
    • 基于tag的选择

      负载均衡

  • Random（dubbo默认）

  • RoundRobin
  • LeastActive

  • ConsistentHashLoadBalance

    服务的过滤/流控

    过滤

  • 所有复杂的处理，都可以抽象为管道+过滤器模式（Channel+Filter）

  • 可以用来实现额外的增强处理，也可以中断当前处理流程，返回特定的数据

    流控

  • FlowControl

  • 系统的容量是有限的
  • 当系统有故障时可以选择保障部分关键服务的能力
  • 需要流控的本质原因是输入请求大于处理能力
  • 级别
    • 限流
      • 内部线程数
      • 外部调用数
      • 数据量大小
      • 可用redis实现
    • 降级
      • 去掉不必要的业务逻辑
      • 只保留核心逻辑
    • 熔断
      • 过载保护
      • 系统短时间不提供新的业务处理，积压处理完后再恢复
      • 推荐框架 sentinel，shiro