Go语言进阶(二十二)微服务可靠性-负载均衡和最佳实践

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

负载均衡

数据中心内部的负载均衡

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

image-20211228143353915

目标:

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

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

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

image-20211228143646509

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

image-20211228143725892

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

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

image-20211228143931734

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

最佳实践

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