一文讲透自适应熔断的原理和实现

为什么需要熔断

微服务集群中，每个应用基本都会依赖一定数量的外部服务。有可能随时都会遇到网络连接缓慢，超时，依赖服务过载，服务不可用的情况,在高并发场景下如果此时调用方不做任何处理，继续持续请求故障服务的话很容易引起整个微服务集群雪崩。 比如高并发场景的用户订单服务，一般需要依赖一下服务：

1. 商品服务

2. 账户服务

3. 库存服务

假如此时 账户服务 过载，订单服务持续请求账户服务只能被动的等待账户服务报错或者请求超时，进而导致订单请求被大量堆积，这些无效请求依然会占用系统资源：cpu，内存，数据连接...导致订单服务整体不可用。即使账户服务恢复了订单服务也无法自我恢复。

这时如果有一个主动保护机制应对这种场景的话订单服务至少可以保证自身的运行状态,等待账户服务恢复时订单服务也同步自我恢复，这种自我保护机制在服务治理中叫熔断机制。

熔断

熔断是调用方自我保护的机制（客观上也能保护被调用方），熔断对象是外部服务。

降级

降级是被调用方（服务提供者）的防止因自身资源不足导致过载的自我保护机制，降级对象是自身。

熔断这一词来源时我们日常生活电路里面的熔断器，当负载过高时（电流过大）保险丝会自行熔断防止电路被烧坏，很多技术都是来自生活场景的提炼。

工作原理

熔断器一般具有三个状态：

1. 关闭：默认状态，请求能被到达目标服务，同时统计在窗口时间成功和失败次数，如果达到错误率阈值将会进入断开状态。

2. 断开： 此状态下将会直接返回错误，如果有 fallback 配置则直接调用 fallback 方法。

3. 半断开：进行断开状态会维护一个超市时间，到达超时时间开始进入 半断开 状态，尝试允许一部门请求正常通过并统计成功数量，如果请求正常则认为此时目标服务已恢复进入 关闭 状态，否则进入 断开 状态。半断开 状态存在的目的在于实现了自我修复，同时防止正在恢复的服务再次被大量打垮。

使用较多的熔断组件：

1. hystrix circuit breaker（不再维护）

2. hystrix-go

3. resilience4j（推荐）

4. sentinel（推荐）

什么是自适应熔断

基于上面提到的熔断器原理，项目中我们要使用好熔断器通常需要准备以下参数：

1. 错误比例阈值：达到该阈值进入 断开 状态。

2. 断开状态超时时间:超时后进入 半断开 状态。

3. 半断开状态允许请求数量。

4. 窗口时间大小。

实际上可选的配置参数还有非常非常多，参考 https://resilience4j.readme.io/docs/circuitbreaker

对于经验不够丰富的开发人员而言，这些参数设置多少合适心里其实并没有底。

那么有没有一种自适应的熔断算法能让我们不关注参数，只要简单配置就能满足大部分场景？

其实是有的，google sre提供了一种自适应熔断算法来计算丢弃请求的概率：

算法参数：

1. requests： 窗口时间内的请求总数

2. accepts：正常请求数量

3. K：敏感度，K 越小越容易丢请求，一般推荐 1.5-2 之间

算法解释：

1. 正常情况下 requests=accepts，所以概率是 0。

2. 随着正常请求数量减少，当达到 requests == K* accepts 继续请求时，概率 P 会逐渐比 0 大开始按照概率逐渐丢弃一些请求，如果故障严重则丢包会越来越多，假如窗口时间内 accepts==0 则完全熔断。