README
¶
熔断器/断路器
用途
避免重复调用很大可能会失败的服务，并能自动感知远端服务状态，如果远端服务不会失败(系统自我判断)，则不对请求进行干预，放行所有请求。
常见于Api Gateway中。
Client 调用 Service A(Service A中调用了Service B,Service C)，则Service A中可以增加熔断器。 避免B,C服务有问题，响应时间过长或者根本不能响应，拖死A，最终造成A不可用。
三种状态
闭合状态
原始状态，允许继续执行,同时进行数据的统计，比如执行成功数量，每秒执行的数量，执行失败的数量等。比如执行失败数量超过5次(此判断依据应该自行定义)，则进入断开状态。
半开状态
有限制的允许执行，比如放行10个请求，对10个请求的执行结果进行统计。如果10个请求都执行成功，则认为远端服务已经恢复，状态变为闭合状态(会重置所有闭合状态的统计数据，比如错误数量归零)，如果有任意一个请求执行失败，则认为远端服务仍然有问题，继续进入断开状态。
断开状态
限制执行，直接返回错误，避免后续调用。同时启动超时定时器(比如超时时间=1分钟)，超时后，状态转变为半开状态。又叫超时定时器或者半开状态定时器。
-
如何知道很大可能会失败？
通过统计，根据闭合状态下的统计结果，自定义断开的判断条件。
-
如何避免重复调用？
一旦满足断开状态的判断条件，立刻进入断开状态，所有请求直接返回错误，不在执行远端的服务调用，也就不需要等待远端的结果返回，减少了响应时间和不必要的资源浪费。
-
如何感知远端服务状态
通过统计，根据半开状态下的统计结果，自定义闭合的判断条件。 通常认为半开状态下放行的所有请求都执行成功，则可以变为闭合状态。
失败判断
失败次数或者失败率通常决定了是否进入断开状态，所以哪种失败需要计算进来，十分重要。按照理解，应该是已经失败，并且以后有可能会恢复的失败，才应该计算进来，如果这种失败是不可挽回的或者短期内不能恢复的，则不需要熔断，应该直接返回失败或者增加熔断的超时时间。总之，要根据不同的错误状态，执行不同的超时策略。
注意：
半开状态下放行的请求不易过大，因为不确定远端的服务是否已经恢复，过多的请求可能会造成不必要的麻烦。
半开状态定时器的时间可以采用指数级退避方式在赋值。比如第一次定时10秒，半开状态后，远端服务仍未恢复，第二次定时20秒，延长半开的恢复时间，给远端一定的恢复时间。
提供手动修改熔断器状态的接口，是个不错的选择。
状态转移
一旦状态变为断开状态，应该发送警告消息，长时间未恢复到闭合状态，应该发送故障消息，这些消息应该可以被其他第三方订阅，比如某监控系统，或者其他不能自动感知服务状态的第三方，帮助他们手动或自动做出相应的策略。
Directories