熔断 Circuit Breaker Pattern

在实际环境中，当下游服务或者存储出现错误，而且需要大量时间来恢复时，服务如何正确处理这些错误决定了服务本身的健壮性和稳定性，而熔断模式则是解决方法之一。

背景

在分布式系统中，一个服务会与多个下游服务打交道，当它访问下游时，很可能因为网络问题(连接过慢、连接超时)、下游服务负载过高或者暂时不可用，导致访问失败。这些问题通常持续时间很多，所以服务为了保证自己对外接口的稳定性，一般会采取一些错误处理措施，例如 重试 。
然而，如果下游服务出现比较严重的问题，需要较长的时间进行恢复，这种情况下重试是不能解决问题的，反而可能会妨碍问题的恢复，甚至带来"雪崩"效应。

解决方案

熔断可以让服务在执行某个操作出现大量失败时，不再继续尝试执行操作。同时熔断可以让服务去检测操作是否恢复正常，如果恢复正常，再去正常执行操作。
注意，熔断和重试不同，重试 让服务在执行操作失败后，再次执行，直到执行成功(每次重试时间间隔不一样，详细可以参考 重试 Retry Pattern)。
针对那些可能会失败的操作，熔断器会提供一个Proxy，介于服务和执行操作之间。这个Proxy会检测服务执行操作失败的比例，然后决定是否继续让服务执行操作，还是直接返回操作执行失败。
为了满足熔断器最基本的功能，Proxy会实现一个状态机，拥有下面一些状态，

• Closed。在Closed状态下，针对服务的请求，Proxy会去实际执行操作。熔断器会记录最近一段时间操作失败的次数，每次操作执行失败都会加一。如果失败次数超过了一个给定的阈值，熔断器会切换到Open状态。在Open状态下，Proxy会开启一个定时器，到了指定的时间后，熔断器会进入到Half-Open状态。注：设置定时器的目的是给出现问题的下游一些时间进行恢复，在这段时间内不再访问下游，避免问题加剧。
• Open。在Open状态下，针对服务的请求，Proxy直接返回失败，而不是执行操作。
• Half-Open。在Half-Open状态下，一小部分请求会被放过，去执行实际的操作(其余的还是直接拒绝，返回执行失败)。如果被放过的请求全部执行成功，Proxy会认为下游已经从错误状态中恢复，熔断器会切换到Closed状态(同时清空之前累积的错误信息)。如果任何一个请求执行失败，熔断器依旧会认为下游不可用，切换到Open状态，同时再次开启一个定时器。Half-Open是一个过渡状态，避免由于状态切换，服务向下游发送过多请求，加剧下游服务的问题恢复。
  
  上图展示了熔断器三个状态之间的切换。需要注意的是，Closed状态下，熔断器的错误计数是基于时间进行统计的，每隔一段时间计数就会重置，这样可以避免少许错误(例如下游的轻微抖动)导致熔断器进入Open状态。也就是说错误计数是基于时间桶的，只有当某个时间桶累积的错误数达到阈值，熔断器才会切换到Open状态。

个人看法

熔断器的应用其实可以很广，

• 服务访问下游存储、访问其他服务等。熔断可以避免造成服务雪崩
• 服务本身的处理逻辑。例如优惠券发放等业务逻辑，如果由于系统漏洞或者恶意攻击导致大量发放大额优惠券，熔断器及时开启可以避免大量损失

实现

todo 熔断器的实现待补充

参考文章：

• https://docs.microsoft.com/en-us/previous-versions/msp-n-p/dn589784(v=pandp.10)