共计 3657 个字符，预计需要花费 10 分钟才能阅读完成。
Circuit breaker 是微服务架构里常见的一种设计模式，用来避免某个出问题的服务拖垮整条链路的情况。它的职责在于，当一个服务不能正常响应的时候，与其继续执行该服务的逻辑，不如断开该部分链路，直接返回错误或者某个降级的内容（比如只显示个静态页面）。
今天我们就来聊聊如何实现一个 circuit breaker。为简单起见，本文中的代码均为伪代码描述。如果你需要在项目中使用 circuit breaker，请尽量用久经考验的开源项目。
我们先搭一个 circuit breaker 的架子。首先 circuit breaker 是一个 decorator，把真正的业务逻辑包裹起来。在入口处，需要判断是否执行该业务逻辑；在出口处，更新 circuit breaker 的状态。
def circuit_breaker(f):
breaker = new_breaker()
def wrapper(f, …):
if not breaker.allow():
return breaker.fallback()
res = f(…)
breaker.update_state(res)
return res
return wrapper
基于 rate limiter 的伪 circuit breaker
初看之下，我们可以用 rate limiter 来实现 allow 方法里的逻辑。rate limiter 通常是用令牌桶（或者漏桶，两者只是硬币的正反面）判断当前请求会不会超过限制的平均速率。如果超过了，需要把当前请求拖迟多久。如果超过平均速率的部分比配置的 burst 还多，则会干脆直接丢弃请求。假使舍弃了中间的拖迟阶段，不就是个 circuit breaker 吗？
表面上，用 rate limiter 就能满足 circuit breaker 的需求了。但实际上两者是不一样的。rate limiter 实现的是如果某个服务达到一定的访问频率，就进行降级；而 circuit breaker 需要实现的是如果某个服务不能正常响应，就进行降级。用 rate limiter 实现 circuit breaker，只能通过预估什么样的访问频率可能导致服务不能正常响应，来设置限制。但这个预估可能是错的，也可能服务因为访问频率大之外的原因导致不能正常响应。
真正的 circuit breaker — 状态机模块
我们现在来看看真正的 circuit breaker 是怎么实现的。
这张图来自于 Azure 关于 circuit breaker 的介绍：https://docs.microsoft.com/en…
真正的 circuit breaker 需要有个 success / failure 的反馈，以及 half-open 这个中间状态。在不同状态下，根据 success / failure，做状态的变化。我们来看下这个状态机：
def breaker.update_state(res):
failure = not is_success(res)
breaker.count_res(failure)
switch breaker.state:
case CLOSED:
if failure and breaker.reach_failure_threshod():
breaker.state = OPEN
kick off a timer to run cooldown
case HALF_OPEN:
if failure:
breaker.state = OPEN
kick off a timer to run cooldown
elif breaker.reach_success_threshod():
breaker.state = CLOSED
breaker.clear_failure_counter()
def breaker.cooldown():
assert(breaker.state == OPEN)
breaker.state = HALF_OPEN
breaker.clear_success_counter()
规则很简单，顺时针从 CLOSED 到 OPEN 到 HALF_OPEN 即可。其中 CLOSED 到 OPEN 是因为失败率太高，OPEN 到 HALF_OPEN 是因为冷却时间到了，HALF_OPEN 到 CLOSED 是满足有足够的成功尝试。然后 HALF_OPEN 也有可能返回到 OPEN，如果尝试失败的话。
注意伪代码中我没有考虑多个线程同时获取 / 更新状态的情况，假定所有的逻辑都只在一个线程里运行。
再看下 allow 函数的实现：
def breaker.allow():
switch breaker.state:
case CLOSED:
return true
case OPEN:
return false
case HALF_OPEN:
return breaker.allow_more_tries()
需要解释下 HALF_OPEN 状态下的逻辑。因为 HALF_OPEN 的时候，我们需要给个机会继续尝试下，说不定服务已经好了。但是我们也不能一下子全放开，所以需要设置一个 max tries。如果 max tries 里面有失败的，就重新退回到 OPEN 状态来；如果全部成功了（reach_success_threshod），就走到 CLOSED 状态中去。
这里可以有一个名为 lazy state 的变化：我们可以根据当前时间判断现在真正的状态是不是 HALF_OPEN。这样能省下创建 cool down timer，和 timer 跟 circuit 交互的开销。但同时却增加了每次执行函数 f 前获取当前时间的开销。对于像是 OpenResty 那样 timer 开销大而获取时间开销小的环境，这个算得上一个优化。不过对于其他环境，需要 benchmark 一把。
真正的 circuit breaker — 统计模块
讲完状态机模块，我们来看下 circuit breaker 的统计模块，即伪代码中 count_res 和 reach_failure_threshod 的实现。统计模块的作用在于计算一段时间间隔内的失败率，如果失败率过高，就会触发 CLOSED 到 OPEN 的状态切换。
各家 circuit breaker 的状态机部分的实现都大同小异，毕竟这里有个可遵循的标准。而统计模块的实现则各有各的不同。
一个普遍的实现是，使用 ring buffer 存储每秒的 counts bucket，然后在计算失败率时把每个 bucket 汇总计算。由于这是 Hystrix 所采用的方式，我称之为“Hystrix 式”。
在 rate limit 的计算中，我们只需维护一个随时间变化的变量，因为 rate limit 的数据是一维的。而 circuit breaker 不仅仅要知道请求的数目，还要知道每秒对应的失败的请求数目。这是个二维的指标，所以需要维护一个随时间变化的 buckets。
注意这里一定要维护一个滑动窗口。假如采用每过一个时间间隔，就把之前的数据清空的策略，虽然不需要维护多个 buckets，但是存在逻辑问题。考虑下面的情况：假设同时有 10000 个请求打到后端服务上来，时间间隔为 10 秒，从第 1 秒开始，每秒有 1000 个请求完成，直到第 11 秒结束。如果第 11 秒时有 900 个请求因为超时失败了，在采用滑动窗口的情况下，失败率是 9%（900 / (1000 * 10)），而如果采用丢弃前面间隔的数据的做法，则失败率是 90%（900 / 1000）。显然，前者才更符合实际情况。
再回到 ring buffer 的讨论上来。如果我们完成了一个时间间隔，就会重新写到 ring buffer 的开头，无需另外开辟空间。注意这里的步长是每秒，如果两个相邻的请求间隔了 N 秒，需要把 N 个位置清零然后写入，而不是直接写到 pos + 1 的位置上。
这里可以做一个优化，与其每次有请求失败时汇总所有的 buckets，我们可以维护各个 buckets 的失败总和与请求总和。如果有 buckets 在 ring buffer 中被清零，则在总和中减去该 bucket 的值。你可以认为该优化就是把汇总的开销分摊到每次需要准备新 buckets 的时候。由于只有某个请求跟上一个请求不位于同一秒时，才会创建新的 bucket；而且失败请求往往是扎堆出现的，我认为这个应该算是个优化。
resilience4j 采用了跟 Hystrix 不同的统计方式。它不是存储每秒的 count，而是存储每个请求的结果。它用一个 bit 代表一个请求，0 表示成功，1 表示失败。这么一来，统计的就不是一个时间间隔内的失败率，而是若干个请求内的失败率。resilience4j 宣称这种方式更能适应各种并发度下的后端系统。但是我怀疑它能否达到这个目的。对于高并发系统，resilience4j 式的统计需要占用比 Hystrix 式更多的内存。比如每秒 1000 个请求的系统，以 10 秒为间隔，Hystrix 式只需要几十 byte，而 resilience4j 式需要有容纳 10000 个请求的空间，大概 1 KB 多一点吧。如果给的空间不够大，比如只容纳 1000 个请求，则会犯前面不用滑动窗口时的错误，算出 90% 的失败率。一个需要根据并发度调整预留空间的设计，是称不上“能适应各种并发度下的后端系统”的。
