一、为什么要用hystrix？
在大中型分布式系统中，通常系统很多依赖，如下图:
在高并发访问下，这些依赖的稳定性与否对系统的影响非常大，但是依赖有很多不可控问题：如网络连接缓慢，资源繁忙，暂时不可用，服务脱机等，如下图：
在高流量的情况下，一个后端依赖项的延迟可能导致所有服务器上的所有资源在数秒内饱和
（PS：意味着后续再有请求将无法立即提供服务）
点击获取Spring全家桶、SpringCloud Alibaba技术栈课程及学习资料。
例如，对于一个依赖于30个服务的应用程序，每个服务都有99.99%（全年不可用时间52.56分钟）的正常运行时间，期望如下：
0.9999^30 = 99.7% 可用
也就是说一亿个请求的0.3% = 300000 会失败
如果一切正常，那么一年有26.2个小时服务是不可用的
当集群依赖50个服务时：
0.9999^50 = 99.5% 可用， 一年43.8小时不可用
分布式系统环境下，服务间类似依赖非常常见，一个业务调用通常依赖多个基础服务。如下图
对于同步调用，当会员服务不可用时，订单服务请求线程被阻塞，当有大批量请求调用会员服务时， 最终可能导致整个会员服务资源耗尽，无法继续对外提供服务。并且这种不可用可能沿请求调用链向上传递，这种现象被称为雪崩效应。
二、雪崩效应常见场景：
硬件故障：
如剔除坏盘抖动，服务器宕机，网络抖动，机房断电，光纤被挖断等；
流量激增： 如异常流量，重试加大流量等；
缓存穿透： 短时间内大量缓存失效时，大量的缓存不命中，使请求直击后端服务，造成服务提供者超负荷运行，引起服务不可用；
程序BUG： 如程序逻辑导致内存泄漏，JVM长时间FullGC，流量高峰期执行定时任务等；
同步等待： 服务间采用同步调用模式，同步等待造成的资源耗尽。
三、雪崩效应应对策略
针对造成雪崩效应的不同场景，可以使用的应对策略，参考如下：
硬件故障： 多机房容灾、异地多活等；
流量激增： 服务自动扩容、流量控制（限流、关闭重试）等；
缓存穿透： 缓存预加载、缓存异步加载等；
程序BUG： 修改程序bug、及时释放资源、定时任务分散到流量低峰时执行等；
同步等待：资源隔离、MQ解耦、不可用服务调用快速失败等。资源隔离通常指不同服务调用采用不同的线程池；不可用服务调用快速失败一般通过熔断器模式结合超时机制实现。
Hystrix，中文含义是豪猪，因其背上长满棘刺，从而拥有了自我保护的能力。本文所说的 Hystrix是Netflix开源的一款容错框架，同样具有自我保护能力，实现了容错和自我保护。
Netflix Hystrix是SOA/微服务架构中提供服务隔离、熔断、降级机制的工具/框架。Netflix Hystrix是断路器的一种实现，用于高微服务架构的可用性，是防止服务出现雪崩的利器。
点击获取Spring全家桶、SpringCloud Alibaba技术栈课程及学习资料哦！
