服务化可能遇到的问题

• 注册中心宕机
• 服务提供者某节点服务宕机、变慢等
• 消费者和注册中心网络异常
• 服务提供者和注册中心网络异常
• ……

服务治理

服务治理的作用是保证服务能够（绕过或解决上述问题）调用成功。

常用服务治理手段

节点管理

注册中心主动摘除机制

• 注册终于要求服务汇报心跳
• 注册中心根据汇报情况（时间间隔等）判定服务是否正常
• 注册中心根据服务情况摘除异常访问
• 注册中心把最近可用的服务推送给消费者

心跳开关保护机制

• 作用：注册中心保护机制之一；即使在网络抖动较频繁的情况下，服务消费者不至于同时去请求注册中心（导致注册中心带宽占满等情况）
• 原理：设置开关；在注册中心抖动时，不同时给所有服务消费者推送消息
• 优点：一定程度上保护注册中心
• 缺点：降低消费者感知变化的能力

服务节点摘除机制

• 作用：防止服务提供者被大量摘除，导致消费者可以调用的节点不足（甚至引起雪崩）
• 原理：设置心跳回报机制，检测服务提供者心跳间隔，如果间隔大于设置值，则判断访问不可用，随即摘除服务
• 优点：状态明确
• 缺点：如果由于网络原因导致大量服务被摘除，将引起雪崩等后果

服务消费者摘除机制

• 消费者探测服务可用性
• 将不可用服务（提交给注册中心）移除

静态注册中心

• 作用：不具备实时监测服务状态变化的注册中心
• 原理：注册中心不主动监测服务提供者的状态，由服务消费者进行服务可用性维护
• 优点：服务可用性准确度高（调用者才是最了解服务可用状态的）
• 缺点：实时性没有那么高

负载均衡（算法）

1. 随机算法
   • 原理：从可用服务节点中随机选取一个
   • 特点：一般来说随机算法是均匀的（每个服务节点最终可能被调用的次数差不多）
   • 使用场景：各服务器性能差异不大的情况下可以使用
2. 轮询算法
   • 原理：对可用服务节点进行轮询调用
   • 特点：每个节点被调用次数理论上完全一致
   • 使用场景：各服务器性能差异不大的情况下可以使用
3. 加权轮询算法
   • 原理：按照固定权重对可用服务节点进行轮询
   • 特点：可根据服务器状态（性能等）对服务器按照不同的权重进行轮询（提高整体硬件资源利用率）
   • 使用场景：各服务器性能差异较大的情况下可以使用
4. 最少活跃调用算法
   • 原理：维护每个服务节点的消费者网络连接数，将新请求分配到连接数最少的服务节点（理论性能最优）
   • 使用场景：服务器性能差异大，但是不太好设置权重时可以使用
5. 一致性 Hash 算法
   • 原理：相同请求参数发到同一个节点，某服务节点故障时，将请求（基于虚拟节点机制）平摊到其它节点上（不会引起剧烈波动）
   • 使用场景：同一个用户请求到同一个节点有优势（缓存等）的情况下可以使用
6. 自适应最优选择算法
   • 原理：在客户端维护服务器的性能快照（定时更新），发起请求时，根据二八原则，将大量请求发往性能更好的服务器（设置高权重），少量请求发往性能略差服务器（设置低权重）
   • 特点：可以更加快均衡的分发请求，且资源使用率更加高；但会增加开发难度以及客户端本身的资源使用量
   • 场景：服务器性能差异大，节点众多的情况下可以使用

服务路由

即通过一定的规则（正则表达式、条件表达式等）来限定服务节点选择范围。

场景

1. 业务存在灰度发布
   • 如：根据规则限定某版本只允许某些用户访问
2. 多机房就近访问
   • 如：多 IDC 部署，按 IP 段限制用户访问机房
3. 流量切换
   • 如：某机房光缆被挖断了，需要把流量切换到其它机房

路由规则

1. 条件路由：基于条件表达式的路由规则
   • 应用场景
     • 排除某个节点（排除预发布节点或者故障节点）
     • 白名单、黑名单
     • 机房隔离（多 IDC 部署情况下，就近访问同 IDC 服务）
     • 读写分离
2. 脚本路由：基于脚本语言（JS、Groovy、Lua 等）的路由规则
   • 应用场景
     • 同上

配置方法

1. 静态配置
   • 在服务消费者本地存放调用规则
   • 服务期间路由规则不发生改变
   • 改变规则需要修改消费者本地配置，并重新上线（才能生效）
2. 动态配置
   • 注册（配置）中心存在配置
   • 消费者定期同步配置

服务容错

常见故障

1. 集群故障
   • 产生原因
     • 代码 BUG
     • 突发流量冲击（超出系统承载力）
   • 应对方法
     • 限流
       • 超出设定的流量限制（可以使用工作线程数等指标）后，抛弃请求，保证其它服务正常
     • 降级（故障后的措施）
       • 停止（按影响大小分级）系统中的某些服务，以保证整体可用性
2. 单 IDC 故障（多 IDC 部署的场景下）
   • 产生原因
     • 机房着火、光缆被挖断等
   • 应对方法
     • 基于 DNS 解析的流量切换
       • 将域名解析从一个 IDC 切到另一个 IDC（延迟可能变长）
     • 基于 RPC 分组的流量切换
       • 以 IDC 为分组，通过配置中心路由规则等，把流量切到其它分组
3. 单机故障
   • 产生原因
     • 网络故障、内存溢出、硬件问题等
   • 应对方式
     • 自动重启
       • 摘除异常机器，在重启解决后再加入集群
     • 更换机器等

服务调用失败常用处理方法

1. FailOver（失败自动切换）
   • 原理：消费者调用失败后，自动从可用服务节点选择下一个服务节点重新发起调用（可以限定次数）
   • 要求：服务必须有幂等性（调用同一个方法，输入一样，输出必然一样）
   • 场景：适合读请求场景
2. FailBack（失败通知）
   • 原理：调用失败不再重试，根据失败详细信息决定后续操作
   • 要求：无特殊要求
   • 场景：适合非幂等调用场景
3. FailCache（失败缓存）
   • 原理：调用失败后，隔一段时间再次发起调用
   • 要求：实时性要求不严苛
   • 场景：实时性要求不严苛的场景
4. FailFast（快速失败）
   • 原理：调用失败后不再重试（记录失败日志）
   • 要求：无特殊要求
   • 场景：适合非核心业务场景