【转】Hystrix的原理及使用

在真正学习Hystrix之前，让我们愉悦的谈谈Hystrix产生的背景

一、背景介绍
1、服务雪崩
分布式系统环境下，服务间类似依赖非常常见，一个业务调用通常依赖多个基础服务。如下图，

如果各个服务正常运行，那大家齐乐融融，高高兴兴的，但是如果其中一个服务崩坏掉会出现什么样的情况呢？如下图，

当Service A的流量波动很大，流量经常会突然性增加！那么在这种情况下，就算Service A能扛得住请求，Service B和Service C未必能扛得住这突发的请求。
此时，如果Service C因为抗不住请求，变得不可用。那么Service B的请求也会阻塞，慢慢耗尽Service B的线程资源，Service B就会变得不可用。紧接着，Service A也会不可用。

So，简单地讲。一个服务失败，导致整条链路的服务都失败的情形，我们称之为服务雪崩。

2、引起雪崩的原因和服务雪崩的三个阶段
原因大致有四：
1、硬件故障；
2、程序Bug；
3、缓存击穿（用户大量访问缓存中没有的键值，导致大量请求查询数据库，使数据库压力过大）；
4、用户大量请求；

服务雪崩的第一阶段: 服务不可用；
第二阶段：调用端重试加大流量（用户重试/代码逻辑重试）；
第三阶段：服务调用者不可用（同步等待造成的资源耗尽）；

3、解决方案
1） 应用扩容（扩大服务器承受力）

加机器
升级硬件
2）流量控制（超出限定流量，返回类似重试页面让用户稍后再试）

限流
关闭重试
3） 缓存

将用户可能访问的数据大量的放入缓存中，减少访问数据库的请求。

4）服务降级

服务接口拒绝服务
页面拒绝服务
延迟持久化
随机拒绝服务
5） 服务熔断

如果对服务降级和服务熔断的概念模糊点此了解 关于服务熔断和服务降级的详解

Hystrix技术点
设计目标：

1. 对来自依赖的延迟和故障进行防护和控制——这些依赖通常都是通过网络访问的
2. 阻止故障的连锁反应
3. 快速失败并迅速恢复
4. 回退并优雅降级
5. 提供近实时的监控与告警

设计原则：

1. 防止任何单独的依赖耗尽资源（线程）
2. 过载立即切断并快速失败，防止排队
3. 尽可能提供回退以保护用户免受故障
4. 使用隔离技术（例如隔板，泳道和断路器模式）来限制任何一个依赖的影响
5. 通过近实时的指标，监控和告警，确保故障被及时发现
6. 通过动态修改配置属性，确保故障及时恢复
7. 防止整个依赖客户端执行失败，而不仅仅是网络通信

Hystrix如何实现:

使用命令模式将所有对外部服务（或依赖关系）的调用包装在HystrixCommand或HystrixObservableCommand对象中，并将该对象放在单独的线程中执行；
每个依赖都维护着一个线程池（或信号量），线程池被耗尽则拒绝请求（而不是让请求排队）。
记录请求成功，失败，超时和线程拒绝。
服务错误百分比超过了阈值，熔断器开关自动打开，一段时间内停止对该服务的所有请求。
请求失败，被拒绝，超时或熔断时执行降级逻辑。
近实时地监控指标和配置的修改。