在分布式架构中，当某个服务单元发生故障（类似用电器发生短路）之后，通过断路器的故障监控（类似熔断保险丝），向调用方返回一个错误响应，而不是长时间的等待。这样就不会使得线程因调用故障服务被长时间占用不释放，避免了故障在分布式系统中的蔓延。
hystrix适用场景
核心无降级业务
计费业务，id生成器业务作为核心业务，是整个短信业务的核心，如果引入熔断机制会导致业务流程失败，相当于整个短信业务不可用，所以这类核心无降级的服务是不应该启动hystrix的。
边缘业务或者可降级的业务
- 相对的，短信发送微服务，因为对接了多个渠道，当某个渠道不可用的情况下，hystrix熔断掉，然后采取另外的渠道进行下发。在发送量级比较大的情况，可以减少短信发送进行重试的时间。
- 如果需要保护后端的es集群，需要协调调用方限制自己的请求，当后端请求返回比较慢的情况下，通过hystrix超时进行熔断，避免后端es挂掉。前提是调用方对查询的数据容忍度比较高，就算查询不到数据也可以接受（短暂性）
hystrix vs dubbo
dubbo对于调用方，可以设置超时时间来打断未响应的调用，但是并不能减轻提供方的压力。
hystrix可以有丰富的配置，其原理是：在一个窗口时间内针对错误进行计数，当达到阈值则熔断提供方，不在请求该熔断的提供方，然后快速返回。
总结
- 是否启动hystrix和hystrix作用阈值应该根据不同业务进行不同精细化的配置，才能发挥出最大的作用。
- 并不是每一个业务都需要开启hystrix的支持
- 在启用hystrix的情况下，对于整个分布式服务集群来讲，并不能完全避免服务雪崩，仅能保证调用方服务在发生网络雪崩发时候自己不被拖死，减少雪崩的影响范围。