让服务在流量暴增时保持不倒

服务自适应降载保护设计

设计目的

• 保证系统不被过量请求拖垮
• 在保证系统稳定的前提下，尽量提供更高的吞吐量

设计考虑因素

• 如何衡量系统负载
  • 是否处于虚机或容器内，须要读取cgroup相关负载
  • 用1000m表示100%CPU，推荐使用800m表示系统高负载
• 尽量小的Overhead，不显著增长RT
• 不考虑服务自己所依赖的DB或者缓存系统问题，这类问题经过熔断机制来解决

机制设计

• 计算CPU负载时使用滑动平均来下降CPU负载抖动带来的不稳定，关于滑动平均见参考资料

  • 滑动平均就是取以前连续N次值的近似平均，N取值能够经过超参beta来决定
  • 当CPU负载大于指定值时触发降载保护机制

• 时间窗口机制，用滑动窗口机制来记录以前时间窗口内的QPS和RT(response time)

  • 滑动窗口使用5秒钟50个桶的方式，每一个桶保存100ms时间内的请求，循环利用，最新的覆盖最老的
  • 计算maxQPS和minRT时须要过滤掉最新的时间没有用完的桶，防止此桶内只有极少数请求，而且RT处于低几率的极小值，因此计算maxQPS和minRT时按照上面的50个桶的参数只会算49个

• 知足如下全部条件则拒绝该请求

  1. 当前CPU负载超过预设阈值，或者上次拒绝时间到如今不超过1秒(冷却期)。冷却期是为了避免能让负载刚下来就立刻增长压力致使立马又上去的来回抖动

  2. averageFlying > max(1, QPS*minRT/1e3)

     • averageFlying = MovingAverage(flying)

     • 在算MovingAverage(flying)的时候，超参beta默认取值为0.9，表示计算前十次的平均flying值

     • 取flying值的时候，有三种作法：

       1. 请求增长后更新一次averageFlying，见图中橙色曲线
       2. 请求结束后更新一次averageFlying，见图中绿色曲线
       3. 请求增长后更新一次averageFlying，请求结束后更新一次averageFlying

       咱们使用的是第二种，这样能够更好的防止抖动，如图：

     • QPS = maxPass * bucketsPerSecond

       • maxPass表示每一个有效桶里的成功的requests
       • bucketsPerSecond表示每秒有多少个桶

     • 1e3表示1000毫秒，minRT单位也是毫秒，QPS*minRT/1e3获得的就是平均每一个时间点有多少并发请求

降载的使用

• 已经在rest和zrpc框架里增长了可选激活配置
  • CpuThreshold，若是把值设置为大于0的值，则激活该服务的自动降载机制
• 若是请求被drop，那么错误日志里会有dropreq关键字

参考资料

• 滑动平均
• Sentinel自适应限流

项目地址

github.com/tal-tech/go…

若是以为文章不错，欢迎 github 点个 star 🤝