（十二）服务雪崩-熔断器

由于分布式系统将不同模式做成不同的服务，在一个系统1中，可能会调用了不同服务，比如会调用服务A、B、C，
而服务跟服务之间也会相互调用的，比如服务D、E会调用服务A；
当调用服务A失败时，系统1、服务D、服务E都会失败了，这样由于一个服务有问题，从而导致多个系统或者服务不可用，产生了服务雪崩。

因此，提出一个熔断器，快速返回一个失败值（而不是在阻塞等待服务的返回，或者服务失败抛出来的异常导致调用者也失败了）

使用Hystrix，可以实现熔断器的功能。

熔断器模式定义了熔断器开关相互转换的逻辑:


服务的健康状况 = 请求失败数 / 请求总数.
熔断器开关由关闭到打开的状态转换是通过当前服务健康状况和设定阈值比较决定的.

    当熔断器开关关闭时, 请求被允许通过熔断器. 如果当前健康状况高于设定阈值, 开关继续保持关闭. 如果当前健康状况低于设定阈值, 开关则切换为打开状态.

    当熔断器开关打开时, 请求被禁止通过.

    当熔断器开关处于打开状态, 经过一段时间后, 熔断器会自动进入半开状态, 这时熔断器只允许一个请求通过. 当该请求调用成功时, 熔断器恢复到关闭状态. 若该请求失败, 熔断器继续保持打开状态, 接下来的请求被禁止通过.

熔断器的开关能保证服务调用者在调用异常服务时, 快速返回结果, 避免大量的同步等待. 并且熔断器能在一段时间后继续侦测请求执行结果, 提供恢复服务调用的可能.

Hystrix的内部处理逻辑

构建Hystrix的Command对象, 调用执行方法.

Hystrix检查当前服务的熔断器开关是否开启, 若开启, 则执行降级服务getFallback方法.

若熔断器开关关闭, 则Hystrix检查当前服务的线程池是否能接收新的请求, 若超过线程池已满, 则执行降级服务getFallback方法.

若线程池接受请求, 则Hystrix开始执行服务调用具体逻辑run方法.

若服务执行失败, 则执行降级服务getFallback方法, 并将执行结果上报Metrics更新服务健康状况.

若服务执行超时, 则执行降级服务getFallback方法, 并将执行结果上报Metrics更新服务健康状况.

若服务执行成功, 返回正常结果.

若服务降级方法getFallback执行成功, 则返回降级结果.
若服务降级方法getFallback执行失败, 则抛出异常.

自己写了个RPC：

https://github.com/nytta

可以给个star,^0^.

Dubbo整合Hystrix作为熔断器，可以基于Dubbo的Filter来实现熔断器功能，代码有
https://github.com/jjavaboy/lam-nio/blob/master/lam-dubbo-consumer/src/main/java/lam/dubbo/consumer/filter/FallbackHystrixFilter.java