微服务可靠性-负载均衡和最佳实践

负载均衡

数据中心内部的负载均衡

在理想情况下，某个服务的负载会完全均匀地分发给所有的后端任务。在任何时刻，最忙和最不忙的节点永远消耗同样数量的CPU。

目标：

• 均衡的流量分发。
• 可靠的识别异常节点。
• scale-out，增加同质节点扩容。
• 减少错误，提高可用性。

我们发现在 backend 之间的 load 差异比较大：

• 每个请求的处理成本不同。
• 物理机环境的差异:
  • 服务器很难强同质性。
  • 存在共享资源争用（内存缓存、带宽、IO等）。
• 性能因素:
  • FullGC。
  • JVM JIT。

（最闲轮训JSQ）负载均衡算法带来的问题，缺乏的是服务端全局视图，因此我们目标需要综合考虑：负载+可用性。

参考了《The power of two choices in randomized load balancing》的思路，使用 p2c 算法，随机选取的两个节点进行打分，选择更优的节点:

• 选择 backend：CPU，client：health、inflight、latency 作为指标，使用一个简单的线性方程进行打分。
• 对新启动的节点使用常量惩罚值（penalty），以及使用探针方式最小化放量，进行预热。
• 打分比较低的节点，避免进入“永久黑名单”而无法恢复，使用统计衰减的方式，让节点指标逐渐恢复到初始状态(即默认值)。
• 当前发出去的请求超过了 predict lagtency，就会加惩罚。

指标计算结合 moving average，使用时间衰减，计算$vt = v(t-1) * β + at * (1-β)$ ，β 为若干次幂的倒数即: $Math.Exp((-span) / 600ms)$

最佳实践

• 变更管理:
  • 70％的问题是由变更引起的，恢复可用代码并不总是坏事。
• 避免过载:
  • 过载保护、流量调度等。
• 依赖管理:
  • 任何依赖都可能故障，做 chaos monkey testing，注入故障测试。
• 优雅降级:
  • 有损服务，避免核心链路依赖故障。
• 重试退避:
  • 退让算法，冻结时间，API retry detail 控制策略。
• 超时控制:
  • 进程内 + 服务间 超时控制。
• 极限压测 + 故障演练。
• 扩容 + 重启 + 消除有害流量