背景

本文讲的熔断器结构参照Hystrix结构。

雪崩

在微服务架构中通常会有多个服务层调用，基础服务的故障可能会导致级联故障，进而造成整个系统不可用的情况，这种现象被称为服务雪崩效应。
如下图：

雪崩示意图

当A服务出现问题的时候，直接造成B不可用，进而造成CD不可用。
雪球越滚越大。
尽管有人为的限流以及ACL之类的开关，但是毕竟有随机以及滞后性

因此服务治理中，引入一种保护机制，减少上述问题的出现，熔断器应运而生。

思路

熔断器的原理很简单，如同电力过载保护器。 它可以实现快速失败，如果它在一段时间内侦测到许多类似的错误，会强迫其以后的多个调用快速失败，不再访问远程服务器，从而防止应用程序不断地尝试执行可能会失败的操作，使得应用程序继续执行而不用等待修正错误，或者浪费CPU时间去等到长时间的超时产生。熔断器也可以使应用程序能够诊断错误是否已经修正，如果已经修正，应用程序会再次尝试调用操作。
简单思路如下

熔断器的状态机

三种状态:关闭（正常情况），开，半开

如果调用失败，将失败调用的数量增加1
如果调用失败次数超过某个阈值，则打开电路
如果电路打开，立即返回错误或默认响应
如果电路是打开的，过了一段时间，半打开电路
如果电路是半开的，下一个呼叫失败，再打开它
如果电路是半开的，成功次数到达阈值，关闭它

里面隐藏了一个问题：成功，失败次数是最近一段时间内累计的，并不是历史所有时间的（不然没有意义），因此要引入时间窗口来统计各个时间段内的数据

窗口处理

含窗口处理的流程

上图按照最近10s统计，每1s一个窗口，记录请求处理结果，分为Success，Timeout，Fail和Rejection，这几个维度自己实现的时候可以调整，比如Rejection见得比较少

那么窗口大小设置多少，窗口个数设置多少。
上图是10个窗口每个1s

这样过了10s的时候，会把[0s,1s)这个窗口给清空掉，由此计算出来新的错误率，准确率等指标会有波动。
（比如正确率本来是SUC[0:9]/TOTAL[0:9],变成了SUC[1:9]/TOTAL[1:9]）

为了尽量减小波动，会把窗口数量设置多一点，每个窗口代表的时间短一点
比如10s可以设置10个1s的窗口，也可以设置成50个0.2s的窗口

总结

本节没有代码实现，这个可以参照refer或其他开源代码
主要理解熔断器里面的三种状态以及状态机的流转，并且对时间窗口统计数据进行介绍

refer

http://www.servicemesher.com/blog/istio-vs-hystrix-circuit-breaker/
http://www.ityouknow.com/springcloud/2017/05/16/springcloud-hystrix.html
https://github.com/Netflix/Hystrix/wiki/How-it-Works