### Hystrix熔断原理 服务容错组件，实现了断路器模式，为依赖服务的出错和延迟提供了容错能力； Netflix的开源组件Hystrix的流程：  图中流程的说明: 1. 将远程服务调用逻辑封装进一个HystrixCommand。 2. 对于每次服务调用可以使用同步或异步机制，对应执行execute()或queue()。 3. 判断熔断器(circuit-breaker)是否打开或者半打开状态，如果打开跳到步骤8，进行回退策略，如果关闭进入步骤4。 4. 判断线程池/队列/信号量（使用了舱壁隔离模式）是否跑满，如果跑满进入回退步骤8，否则继续后续步骤5。 5. run方法中执行了实际的服务调用。 a. 服务调用发生超时时，进入步骤8。 6. 判断run方法中的代码是否执行成功。 a. 执行成功返回结果。 b. 执行中出现错误则进入步骤8。 7. 所有的运行状态(成功，失败，拒绝，超时)上报给熔断器，用于统计从而影响熔断器状态。 8. 进入getFallback()回退逻辑。 a. 没有实现getFallback()回退逻辑的调用将直接抛出异常。 b. 回退逻辑调用成功直接返回。 c. 回退逻辑调用失败抛出异常。 9. 返回执行成功结果。 注意：熔断是否开启熔断器主要由依赖调用的错误比率决定的，依赖调用的错误比率=请求失败数/请求总数。Hystrix中断路器打开的默认请求错误比率为50%（这里暂时称为请求错误率），还有一个参数，用于设置在一个滚动窗口中，打开断路器的最少请求数（这里暂时称为滚动窗口最小请求数），这里举个具体的例子：如果滚动窗口最小请求数为默认20，在一个窗口内（默认10秒，统计滚动窗口的时间可以设置），收到19个请求，即使这19个请求都失败了，此时请求错误率高达95%，但是断路器也不会打开。对于被熔断的请求，并不是永久被切断，而是被暂停一段时间（默认是5000ms）之后，允许部分请求通过，若请求都是健康的（ResponseTime<250ms）则对请求健康恢复（取消熔断），如果不是健康的，则继续熔断。（这里很容易出现一种错觉：多个请求失败但是没有触发熔断。这是因为在一个滚动窗口内的失败请求数没有达到打开断路器的最少请求数）