微服务可靠性-负载均衡和最佳实践
负载均衡
数据中心内部的负载均衡
在理想情况下,某个服务的负载会完全均匀地分发给所有的后端任务。在任何时刻,最忙和最不忙的节点永远消耗同样数量的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 控制策略。
- 超时控制:
- 进程内 + 服务间 超时控制。
- 极限压测 + 故障演练。
- 扩容 + 重启 + 消除有害流量