背景说明
在微服务系统中一个业务操作会由多个不同的服务来共同完成。所以，这些依赖的服务的稳定性与否对系统的影响非常大。但是，由于依赖的服务存在很多不可控问题：如网络延迟、资源繁忙，服务暂时不可用、甚至宕机等。
我们先来看一张请求示意图：
上图所示，举例说明了依赖服务由于支撑服务暂时不可用问题导致系统问题。（注：ServiceA为集群服务，ServiceB为单点故意服务）
用户请求由于ServiceB的不可用，导致一次请求需要等待6S才能响应（示意图，假设APP端的请求不会超时）。那么，所有的请求都会堆积直到达到系统上限直接打死所有服务。
该过程，称之为服务雪崩效应。
那么，如何在真实的微服务环境中如何防止由于某服务问题而导致的整个服务雪崩呢？那就是，当调用方调用服务发生异常时，调用方记录该服务接口不可用。 下次请求到达时，根据记录知道该请求是不可完成的，直接响应拒绝请求。这就是熔断器最初始的设计。
上面，我们对熔断器的出现背景进行了一小部分的讲解，下面，以开始介绍熔断器的设计。
熔断器工作模式
在熔断器中，最重要的一个概念是： 服务的健康情况。 熔断器的设计基本上都是围绕该概念进行的。
Note：服务的健康情况 = 请求失败数 / 请求总数
如图所示，定义了熔断器的工作模式与开关相互转换的逻辑。
熔断器定义了三种状态来决定是否允许请求通过：
1. 关闭（Close）：在关闭状态时，请求允许通过，如果请求失败计算服务健康情况，当健康情况低于设定阈值时，将状态设置为开启（Open），否则保持关闭状态（Close）。
2. 开启（Open）：在开启状态时，请求被禁止通过。
3. 半开（HalfOpen）：当熔断器处理开启（Open）状态时，经过一段时间，进入半开状态，这时允许部份请求进入，如果请求调用成功，则恢复到关闭状态（Close）。若请求失败，则重新设置为开启（Open）。
也就是说，熔断器最重要的在于保证服务调用者在调用异常服务时，快速返回结果，避免大量的同步等待。 并且，在一段时间后，熔断器能自动判断服务恢复调用的可能。
