go-zero⾼可⽤-⾃适应熔断器
为什么需要熔断器
微服务集中，每个应⽤基本都会依赖⼀定数量的外部服务。有可能随时都会遇到⽹络连接缓慢，超时，依赖服务过载，服务不可⽤的情况，在⾼并发场景下如果此时调⽤⽅不做任何处理，继续持续请求故障服务的话很容易引起整个微服务集雪崩。 ⽐如⾼并发场景的⽤户订单服务，⼀般需要依赖⼀下服务：
1. 商品服务
2. 账户服务
3. 库存服务
image
磁流变阻尼器
假如此时 账户服务 过载，订单服务持续请求账户服务只能被动的等待账户服务报错或者请求超时，进⽽导致订单请求被⼤量堆积，这些⽆效请求依然会占⽤系统资源：cpu，内存，数据连接...导致订单服务整体不可⽤。即使账户服务恢复了订单服务也⽆法⾃我恢复。
image
这时如果有⼀个主动保护机制应对这种场景的话订单服务⾄少可以保证⾃⾝的运⾏状态，等待账户服务恢复时订单服务也同步⾃我恢复，这种⾃我保护机制在服务治理中叫熔断机制。 熔断施万细胞红蓝图
熔断是调⽤⽅⾃我保护的机制（客观上也能保护被调⽤⽅），熔断对象是外部服务。
降级
降级是被调⽤⽅（服务提供者）的防⽌因⾃⾝资源不⾜导致过载的⾃我保护机制，降级对象是⾃⾝。
image
熔断这⼀词来源时我们⽇常⽣活电路⾥⾯的熔断器，当负载过⾼时（电流过⼤）保险丝会⾃⾏熔断防⽌电路被烧坏，很多技术都是来⾃⽣活场景的提炼。
⼯作原理
image液压压力机
熔断器⼀般具有三个状态：
1. 关闭：默认状态，请求能被到达⽬标服务，同时统计在窗⼝时间成功和失败次数，如果达到错误率
阈值将会进⼊断开状态。
2. 断开： 此状态下将会直接返回错误，如果有 fallback 配置则直接调⽤ fallback ⽅法。
3. 半断开：进⾏断开状态会维护⼀个超市时间，到达超时时间开始进⼊ 半断开 状态，尝试允许⼀部门请求正常通过并统计成功数量，如果请求
正常则认为此时⽬标服务已恢复进⼊ 关闭 状态，否则进⼊ 断开 状态。半断开 状态存在的⽬的在于实现了⾃我修复，同时防⽌正在恢复的服务再次被⼤量打垮。
使⽤较多的熔断组件：
1. hystrix circuit breaker（不再维护）
2. hystrix-go
3. resilience4j（推荐）
4. sentinel（推荐）
什么是⾃适应熔断器
基于上⾯提到的熔断器原理，项⽬中我们要使⽤好熔断器通常需要准备以下参数：
1. 错误⽐例阈值：达到该阈值进⼊ 断开 状态。
2. 断开状态超时时间：超时后进⼊ 半断开 状态。
3. 半断开状态允许请求数量。
4. 窗⼝时间⼤⼩。
对于经验不够丰富的开发⼈员⽽⾔，这些参数设置多少合适⼼⾥其实并没有底。
那么有没有⼀种⾃适应的熔断算法能让我们不关注参数，只要简单配置就能满⾜⼤部分场景？
其实是有的，google sre提供了⼀种⾃适应熔断算法来计算丢弃请求的概率：
image
算法参数：
1. requests： 窗⼝时间内的请求总数
2. accepts：正常请求数量
3. K：敏感度，K 越⼩越容易丢请求，⼀般推荐 1.5-2 之间
算法解释：
彩钢管1. 正常情况下 requests=accepts，所以概率是 0。
2. 随着正常请求数量减少，当达到 requests == K* accepts 继续请求时，概率 P 会逐渐⽐ 0 ⼤开始按照概率逐渐丢弃⼀些请求，如果故障严
重则丢包会越来越多，假如窗⼝时间内 accepts==0 则完全熔断。
3. 当应⽤逐渐恢复正常时，accepts、requests 同时都在增加，但是 K*accepts 会⽐ requests 增加的更快，所以概率很快就会归 0，关闭熔led驱动电路
断。
代码实现
接下来思考⼀个熔断器如何实现。
初步思路是：
1. ⽆论什么熔断器都得依靠指标统计来转换状态，⽽统计指标⼀般要求是最近的⼀段时间内的数据（太久的数据没有参考意义也浪费空间），所
以通常采⽤⼀个 滑动时间窗⼝ 数据结构 来存储统计数据。同时熔断器的状态也需要依靠指标统计来实现可观测性，我们实现任何系统第⼀步需要考虑就是可观测性，不然系统就是⼀个⿊盒。
2. 外部服务请求结果各式各样，所以需要提供⼀个⾃定义的判断⽅法，判断请求是否成功。可能是 de 、de、de，熔断兔子全自动设备
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议