IDEA激活码
本文，我们来学习断路器。断路器在软件设计模式中，当一个服务影响到另一个服务时常被用到。如果你对电子电器工程有一定了解到话，一定听过断路或微型断路器。
这基本上是一个电子开关，用来保护我们的家庭电器设备。当电路出现异常时，它就会切换以保护整个电路。这种断路的概念类似于我们在软件世界中使用的概念，在软件世界中，服务实际上与许多其他服务进行交互。让我们举个例子来理解它到底是什么。
假设有3个微服务，并且这3个微服务之间相互同步通信。当向微服务1发送一个请求，微服务1将调用微服务2进一步的微服务2会调用微服务3。如果所有服务正常的话，请求结果会从微服务3返回给微服务2，然后到微服务1。但可能有一些服务不可用。并非所有的服务都是可用的。
如果微服务3故障了将会发生什么？
请求将发送到微服务1和微服务2，当请求到微服务3会返回错误。现在，微服务2将接收到错误并将错误返回给微服务1，最后客户端接收到一个错误响应。这并不合适，因为客户端不想要接收到错误。需要以更合适的方式处理。也可能有其他的问题，如果微服务2有重试机制的话为了获得正常响应会向微服务3发送多次重试请求。假如微服务2重试5次。当微服务3因负载过重而返回错误的话，重试会导致微服务3返回更多错误。因此这里需要更好的方式处理。
如何让服务变得更好？
让我们向这个请求路径中添加断路器。假设我们在每个微服务中都实现了断路器。断路器有3种方式可以实现服务正常响应。
缓存响应
当请求发送到微服务1，然后发送到微服务2最后到微服务3。现在微服务2知道微服务3出现异常。微服务2中的断路器知道微服务3返回错误。断路器会将缓存中的响应返回。这意味着，每当我们从服务接收到错误时，我们可以配置断路器以返回缓存中的响应。缓存中的响应是之前请求成功的响应或服务没有故障时缓存的响应。因此，现在当服务失败时，我们实际上会得到缓存的响应。用户可以通过缓存响应接收返回码为200的成功响应。
回退机制
不返回缓存的响应，可以将发送到微服务3的请求重定向到其他类似的服务上进行处理。请求重定向到类似微服务3，就可以从第三方服务获得成功的响应，而不会得到任何错误。因此，当实际服务失败时，我们可以使用另一个服务替代故障服务。
修复机制
这里当一个请求来临时，微服务断路器保留微服务3的失败次数。在达到给定的失败次数之后，我们可以告诉微服务2上的断路器，停止向微服务3发送请求。让它恢复一段时间。我们也可以配置恢复时间。在此之后，任何针对微服务2的请求都不会调用微服务3，直到定义的时间间隔结束。现在我们可以使用缓存响应或回退机制返回响应。可以断开微服务3并让它恢复。
如何才能恢复？
- 如果队列中有任何等待的请求，它等待处理并结束。
- 可以关闭故障服务并部署一个新实例，或者配置启动一个新实例。
超过恢复时间后会如何？
在某个超时后，微服务2将调用微服务3并检查响应如何。 如果仍然失败，微服务2将继续返回缓存响应或使用回退机制。如果请求成功，那么微服务2缓存成功响应，并将响应返回给微服务1，并保持正确的请求路径。
线路图
- Closed：当一切正常，断路器处于关闭状态，所有请求经过服务。当请求失败次数超出阈值时，断路器触发处于Open状态。
- Open：断路器在不执行函数的情况下对调用返回一个错误。
-
Half-Open：经过一个超时时间后，电路切换到半开状态，以测试潜在问题是否仍然存在。如果在这种半开状态下单个调用失败，断路器将再次触发。如果调用成功，断路器复位到正常关闭状态。
如果微服务一切正常，断路器就处于Closed状态。如果现在微服务3失败，链路与微服务3断开连接，进入Open状态并开始返回缓存响应。经过一段延迟之后，再次调用微服务3，并进入半开状态，这实际是检查微服务3是否返回一个成功的响应。如果它返回一个成功的响应，可以进入Closed状态，如果仍然返回一个错误，我们可以进入Open状态。这是断路器的整个状态转移过程。
