高可用--限流熔断降级

熔断

熔断是应对微服务雪崩效应的一种链路保护机制。

场景

• 服务端出现问题
  • 服务指标：响应时间、错误率、连续错误数等，超过阈值出发熔断。
  • 硬件指标：CPU、网络IO、内存

目的

• 服务端恢复需要时间、服务端需要休息
• 避免全调用链路崩溃，不能再把请求再发给Server了，一旦堆积也会造成其他服务出现问题

手段

• 熔断器直接抛出熔断的异常响应，三个状态切换，决定是否处于熔断状态
  

流程

1. Server被监控到异常，出发熔断，熔断器抛出熔断的异常响应
2. Client收到异常，利用负载均衡重新选择节点，后续请求不再打到被熔断的节点
3. 一段时间后，Client再对这个节点重新请求，如果正常响应，则缓慢对这个节点放开流量，如果仍然是熔断状态，则继续执行Step2，如此循环

限流

场景 & 目的

• 突发的流量增大，使系统崩溃

• 判断指标：节点当前连接数、QPS等

静态算法

一般情况下，令牌产生速率/漏桶“开口速率”决定处理请求速率。

• 令牌桶：系统以恒定速率产生并把令牌放到桶里，每个请求从桶里拿到令牌才会被执行，反之被限流

• 漏桶：（令牌桶的桶容量是0就是漏桶）系统匀速产生令牌，没被取走也不会积攒下来。系统处理请求时均匀的。

• 固定窗口：固定时间段内，只执行固定数量的请求。

• 滑动窗口：滑动窗口随着时间线挪动窗口。

动态算法：BBR

类似于 TCP 的拥塞控制，根据一系列指标来判定是否需要触发限流。

流程

• 在中间件记录流量和阈值，并在中问件中实现限流算法。
• 对于偶发性的触发限流，只要在超时范围内，可以同步阻塞等待请求被处理。
• server的某个节点触发了 非偶发性限流，Client 利用负载均衡调低该节点的权重，尽量少向这个节点发请求。

如何确定阈值

• 阈值太低，导致资源被闲置；國值太高，导致系统撑不住而崩溃。
• 上线后看监控，根据业务峰值 QPS 来约定阈值。
• 上线前做压测，找准限流的阈值。

熔断&限流&降级关系

熔断是完全不再发请求，限流是降低发送请求的频率。
熔断是防止雪崩效应发生提前触发；

降级

场景&目的

• 系统出现故障后的补救措施；或可预见的故障前的应对措施，来保证整体的可用性。
• 对非核心业务降级，为核心业务留出更多资源。

手段

• 考虑停用部分监控埋点、日志上报等观测类中间件。
• 根据业务场景判断，停用边缘服务，返回服务繁忙之类的响应。
• 对于有缓存的接口，降级时只查缓存，不查 DB，没命中缓存则返回错误的响应。

终：核心思想

• 如何判断节点的健康状态？是否需要熔断/限流/降级？
  • 通过监控看指标：QPS、连接数、节点负载等
• 熔断/限流/降级后，怎么恢复？
  • 熔断/限流搭配负载均衡，等节点恢复正常后，再重新选择
  • 降级有时是手动恢复