go-zero高可用-自适应熔断器

Posted 2023-03-14

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

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

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

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

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

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

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

使用较多的熔断组件：

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

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

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

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

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

算法参数：

算法解释：

接下来思考一个熔断器如何实现。

初步思路是：

下面来逐步分析 go-zero 的源码实现：

core/breaker/breaker.go

兵马未动，粮草先行，明确了需求后就可以开始规划定义接口了，接口是我们编码思维抽象的第一步也是最重要的一步。

核心定义包含两种类型的方法：

Allow()：需要手动回调请求结果至熔断器，相当于手动挡。

DoXXX()：自动回调请求结果至熔断器，相当于自动挡，实际上 DoXXX() 类型方法最后都是调用

DoWithFallbackAcceptable(req func() error, fallback func(err error) error, acceptable Acceptable) error

circuitBreaker 继承 throttle，实际上这里相当于静态代理，代理模式可以在不改变原有对象的基础上增强功能，后面我们会看到 go-zero 这样做的原因是为了收集熔断器错误数据，也就是为了实现可观测性。

熔断器实现采用静态代理模式，看起来稍微有点绕脑。

throttle 接口实现类：

loggedThrottle 增加了为了收集错误日志的滚动窗口，目的是为了收集当请求失败时的错误日志。

errorWindow 是一个环形数组，新数据不断滚动覆盖最旧的数据，通过取余实现。

看到这里我们还没看到实际的熔断器实现，实际上真正的熔断操作被代理给了 internalThrottle 对象。

可以看到熔断器属性其实非常简单，数据统计采用的是滑动时间窗口来实现。

滑动窗口属于比较通用的数据结构，常用于最近一段时间内的行为数据统计。

它的实现非常有意思，尤其是如何模拟窗口滑动过程。

先来看滑动窗口的结构体定义：

window 是数据的实际存储位置，其实就是一个数组，提供向指定 offset 添加数据与清除操作。
数组里面按照 internal 时间间隔分隔成多个 bucket。

window 添加数据：

window 统计数据：

熔断器对外暴露两种类型的方法

func (b *googleBreaker) allow() (internalPromise, error)

func (b *googleBreaker) doReq(req func() error, fallback func(err error) error, acceptable Acceptable) error

Acceptable 参数目的是自定义判断请求是否成功。

微软 azure 关于熔断器设计模式

索尼参考微软的文档开源的熔断器实现

go-zero 自适应熔断器文档