微服务的限流与熔断

限流,熔断

Posted by hughnian on February 25, 2022

微服务限流

传统限流方式

传统的限流算法,如漏桶、令牌桶等,他们的缺点是单一限流和无差别限流。此外,系统需要先做压测,拿到一个初始的限流参考值,超过这个值才启动限流机制,缺乏系统的弹性伸缩性。

自适应限流保护

1.bbr拥塞控制限流,bbr是自适应限流的一种,系统自适应限流从整体维度对应用入口流量进行控制,结合应用的 Load、CPU使用率、总体平均RT、入口QPS和并发线程数等几个维度的监控指标,通过自适应的流控策略,让系统的入口流量和系统的负载达到一个平衡,让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。这就要求根据系统能够处理的请求,和允许进来的请求,来做平衡,而不是根据一个间接的指标(系统 load)来做限流。最终我们追求的目标是 在系统不被拖垮的情况下,提高系统的吞吐率,而不是 load 一定要到低于某个阈值。如果我们还是按照固有的思维,超过特定的 load 就禁止流量进入,系统 load 恢复就放开流量,这样做的结果是无论我们怎么调参数,调比例,都是按照结果来调节因,都无法取得良好的效果。简言之,自适应限流就是根据当前负载情况,来嗅探load的值,尽可能提高系统的吞吐量。

2.codel限流,codel是实现了用于过载检测的受控延迟算法,提供了一种在过载时卸载负载的机制。它优化延迟,同时保持高吞吐量,即使下游速率动态变化。codel通过在等待延迟较长时抢先减少一些负载,即使在严重过载时也能保持较低的延迟。它类似于使用队列来处理突发负载,但通过避免处理队列中所有先前条目所需的延迟来改进此技术。在流量超负荷情况下,对比正常的队列,基本不改变系统最大处理速率以及正确率情况下,能较大程度改善单次请求平均耗时。codel有一套基本固定的算法,核心是流量大就多丢,流量少就少丢,能处理就不丢;丢“老”流量不丢“新”流量。

3.bbr与codel,CoDel的出现为了解决网络中越来越长的排队长度和不断增加的端到端的时延。BBR的出现,纠正了TCP拥塞控制的发展方向,而CoDel则是纠正网络队列管理机制的发展方向,CoDel应该与BBR配合使用。CoDel存在的价值在于为BBR提供一个良好环境,CoDel是BBR的保护者,而非限制者,也非监管者,CoDel保护BBR免受传统的TCP拥塞控制算法盲目探测之害,同时也在一定程度上阻止了恶意的竞速流量侵占宝贵的带宽。

参考实现

微服务熔断

Circuit Breaker Pattern(环形容断器)

         Closed 
         /    \
     Half-Open <--> Open

1.关闭(Closed):默认情况下Circuit Breaker是关闭的,此时允许操作执行。Circuit Breaker内部记录着最近失败的次数,如果对应的操作执行失败,次数就会续一次。如果在某个时间段内,失败次数(或者失败比率)达到阈值,Circuit Breaker会转换到开启(Open)状态。在开启状态中,Circuit Breaker会启用一个超时计时器,设这个计时器的目的是给集群相应的时间来恢复故障。当计时器时间到的时候,Circuit Breaker会转换到半开启(Half-Open)状态。

2.开启(Open):在此状态下,执行对应的操作将会立即失败并且立即抛出异常。

3.半开启(Half-Open):在此状态下,Circuit Breaker 会允许执行一定数量的操作。如果所有操作全部成功,Circuit Breaker就会假定故障已经恢复,它就会转换到关闭状态,并且重置失败次数。如果其中 任意一次 操作失败了,Circuit Breaker就会认为故障仍然存在,所以它会转换到开启状态并再次开启计时器(再给系统一些时间使其从失败中恢复)。

参考实现

sony gobreaker实现