云设计模式之: 断路器模式

1. 缘由

在分布式环境中，远程调用可能因为网络延迟等各种各样的问题导致暂时性的不可访问，这种情况下可以使用重试模式来解决，因为导致不可访问的环境很快就会恢复了。然而，有时候导致不可访问的环境并不那么容易恢复，需要比较长的时间才有可能重新变得可用。这时候如果还是不停地重试，基本也不会成功，只会白白浪费系统资源，而应该采取的措施是，马上接受故障已发生的现实并尝试解决此类故障。不这样做的话，可能还会引起系统雪崩效应，本来没有问题的系统也跟着出现了故障，因为已经出故障的部分可能占据一些重要的系统资源不释放，导致其它部分的崩溃。

2. 解决方案

断路器模式就是用来解决这个问题的，它可以让应用程序停止频繁无效地重试，并且有可能会间歇性地探测导致出故障的环境条件，如果环境恢复了，再尝试去调用。重试模式是不断去尝试调用并期望成功，而断路器模式则是停止尝试不太可能成功的调用。断路器模式的结构图如下：

上面图中，断路器的实现就像一个状态机，具有以下不同的状态：

1) Closed. 断路器保存有最近失败的计数器，如果一个请求过来再次失败，计数器将加1。在一个时间范围内，如果计数器值超过了某个阈值，断路器将被置为Open状态。然后断路器启动一个定时器，当定时器超时后，断路器被置为Half-Open状态。定时器的目的就是为了让系统有时间自我恢复。

2) Open. 应用程序的请求马上失败，并且有异常返回给应用程序。

3) Half-Open. 限定次数的请求数允许通过，如果这些请求成功了，那说明之前引起故障的环境已经恢复，这时候断路器被置为Closed状态。如果某个请求失败了，那么断路器将重新被置为Open状态并像之前那样重新启动定时器。

Half-Open状态的目的是，在环境故障恢复期间，防止请求泛洪，因为这时候系统还没有完全治愈。期间的状态转换细节，这里就不多说了，需要大家自己去看图体会。

3. 何时使用

当需要阻止应用程序不断重试远程调用，并且这些远程调用很可能会失败的情况下，可以使用该模式。在使用时，需要考虑异常处理，比如断路器本身不能正常工作时，应用程序该如何处理，需要记录详细的日志供维护人员定位问题。还有更多需要注意的地方，可能在你具体使用该模式时，才会慢慢考虑到。

4. 代码示例

这里有一些代码示例，可以参考下，通过阅读这个模式的简单实现代码，可加深对断路器模式的认识和理解。

微信扫码，进入【技术人成长】社群逛逛。