Go 微服务可用性设计

本文最后更新于:5 个月前

Go 微服务可用性设计知识点

隔离

服务隔离

动静隔离

如 CND 缓存加速、mysql LRU 算法改进

业务可以拆成两张表,静态表(字段机会不会改)和动态表(字段经常改)

读写隔离

  • 主从
  • CQRS

轻重隔离

  • 核心:服务按核心与否进行分离,越核心的服务可用性要求也高
  • 快慢
  • 热点
    • 小表广播: 存为到内存,定期更新
    • 主动预热:旁路预热

物理隔离

  • 线程:使用线程池,不同业务逻辑用不同的池子
  • 进程:容器化
  • 集群:region.zone.cluster.appid
  • 机房

超时控制

核心理念: fail fast

起因

  • 网络具有不确定性
  • 客户端和服务端不一致的超时策略

方案

  • 进程内:每一个请求前查看是否有剩余时间,并继承超时策略
  • 服务间: GRPC 支持基于 grpc-timeout 的 Header 传递
  • 监控要看 95th、99th

过载保护

常见限流算法

  • 令牌桶:按固定速率往桶里加令牌,可以消费多个令牌
  • 漏斗桶: 按固定速率流出水滴,可以以任意速率流入水滴

痛点:阈值不好设置

自适应过载保护

inflight: 当前服务正在进行的请求数量(atomic.add 来加减)
pass: 每个采样窗口内成功的请求数
rt: 单个采样窗口的平均 响应时间

CPU 统计:使用独立的 goroutine 每隔 250ms 统计一次,计算均值时,使用简单滑动平均(考虑前一次的均值)去除峰值的影响

统计 CPU 的滑动均值作为启发阈值(如 80%),一旦触发进入过载保护阶段,算法:(pass * rt) < inflight

另外过载保护需要保证持续最小时间如 2s,以避免一个短时间的 CPU 下降可能导致大量请求被放行,严重是会打满 CPU

限流

定义:在一段时间内某个客户或应用可以处理多少个请求

作用:过滤流量峰值

常规方案

  • 令牌桶:针对单个节点无法分布式限流
  • QPS 限流:
    • 不同的请求可能消耗的资源完全不同
    • 静态阈值很难设置准确
  • 使用 redis 分布式限流
    • 单个大流量接口容易产生热点 key
    • 每次请求需要拿一个 quota –> 优化:基于历史窗口数据批量拿 quota,减少请求 redis 频次

资源分配:Max-Min Fairness 算法

重要性 criticality

  • 将请求按重要性分级,配额不足时,先拒绝优先级低的
    • critical_plus
    • critical
    • sheddable_plus
    • sheddable
  • 通常 BFF 层接口分级,重要性可往下游传递

熔断: 客户端自适应节流

请求拒绝率: max(0, requests - K * accepts/(requests+1))

客户端流控

作用:避免 positive feedback 积极重试访问不可达的服务

  • 限制请求频次,重试添加 backoff 退让策略

Gutter

gutter 集群只需要主集群的 10%的资源
主集群发生熔断被抛弃的请求会转移到 gutter 集群
如果 gutter 集群也接受不住流量,会重现抛到主集群

降级

本质为提供有损服务
通过降低回复的质量来答复以减少所需的计算量或时间

通常采用错误或者 CPU 指标作为决定性指标

通常在 BFF 层或网关来做

重试

随机化+指数避让

只应该在失败层重试,以免指数放大次数,如收到 503 就表示下游已重试过则直接往上抛结果当前层不在重试了

业务不幂等:尽量不重试,即使重试也需要避免数据发生重复

负载均衡

目标

  • 均衡流量分发
  • 识别异常节点
  • 水平扩容
  • 高可用 N+2

可能的问题

  • 不同节点负载不一样
    • 原因:
      • 不同请求处理成本不一样
      • 机器性能不一样
      • 可能有节点 FullGC 中
      • 多个 LB 中每个 LB 都没有全局视角

Power of Two Choices (P2C)

随机请两个节点进行打分,选择更优的节点

打分:服务端 CPU(通过 rpc response head 获取)、耗时、成功率,inflight

新加入节点开始权重较小,这个特性尤其对 Java 服务比较友好

指标计算结合滑动均值且使用时间衰减

最佳实践

变更管理:

70%的问题是由变更引起的,恢复可用代码并不总是坏事。

避免过载:

过载保护、流量调度等。

依赖管理:

任何依赖都可能故障,做 chaos monkey testing,注入故障测试。

优雅降级:

有损服务,避免核心链路依赖故障。

重试退避:

退让算法,冻结时间,API retry detail 控制策略。

超时控制:

进程内 + 服务间 超时控制。

极限压测 + 故障演练。

扩容 + 重启 + 消除有害流量。

references