共计 4096 个字符，预计需要花费 11 分钟才能阅读完成。
一、容错限流的需要
在简单的分布式系统中通常有很多依赖，如果一个利用不能对来自依赖故障进行隔离，那么利用自身就处于被拖垮的危险中。在一个高流量的网站中，某一个繁多后端一旦产生提早，将会在数秒内导致所有的利用资源被耗尽，这也就是咱们常说的雪崩效应。
比方在电商零碎的下单业务中，在订单服务创立订单后同步调用库存服务进行库存的扣减，如果库存服务呈现了故障，那么会导致下单申请线程会被阻塞，当有大量的下单申请时，则会占满利用连接数从而导致订单服务无奈对外提供服务。
二、容错限流的原理
对于根本的容错限流模式，次要有以下几点须要考量：
- 被动超时：在调用依赖时尽快的超时，能够设置比拟短的超时工夫，比方 2s，避免长时间的期待。
- 限流：限度最大并发数。
- 熔断：谬误数达到阈值时，相似于保险丝熔断。
- 隔离：隔离不同的依赖调用
- 服务降级：资源有余时进行服务降级
1. 断路器模式
实现流程为：当断路器的开关为敞开时（对应图中的绿色），每次申请进来都是胜利的，当后端服务呈现问题，申请呈现的谬误数达到肯定的阈值，则会触发断路器为关上状态（对应图中的红色），在断路器为关上状态时，进来的所有申请都会被回绝，当然也不是始终会拒绝请求，而是弹性的，过了特定的工夫后，断路器会进入半关上状态（对应图中的黄色），这是会让一部分申请通过进行尝试，如果尝试还是有问题，则持续进入关上状态，如果尝试没有问题了，则会进入敞开状态。
2. 舱壁隔离模式
舱壁隔离模式能够对资源进行隔离，相似于船的船舱都是被隔离开来的，当其中一个或者几个船舱呈现问题，比方漏水，是不会影响到其余的船舱的，从而实现一种资源隔离的成果。
3. 容错理念
- 但凡依赖都有可能会失败。
- 但凡资源都有限度，比方 CPU、Memory、Threads、Queue。
- 网络并不牢靠，可能存在网络抖动等其余问题。
- 提早是利用稳固的杀手，提早会占据大量的资源。
三、什么是 Hystrix
Hystrix 是 Netflix 公司开源的一款容错框架。它能够实现以下几件事件：
- 资源隔离，包含线程池隔离和信号量隔离，防止某个依赖呈现问题会影响到其余依赖。
- 断路器，当申请失败率达到肯定的阈值时，会关上断路器开关，间接回绝后续的申请，并且具备弹性机制，在后端服务复原后，会主动敞开断路器开关。
- 降级回退，当断路器开关被关上，服务调用超时 / 异样，或者资源有余（线程、信号量）会进入指定的 fallback 降级办法。
- 申请后果缓存，hystrix 实现了一个外部缓存机制，能够将申请后果进行缓存，那么对于雷同的申请则会间接走缓存而不必申请后端服务。
- 申请合并，能够实现将一段时间内的申请合并，而后只对后端服务发送一次申请。
四、Hystrix 外围概念
1. 资源隔离
资源隔离的思维参考上述的舱壁隔离模式，在 hystrix 中提供了两种资源隔离策略：线程池隔离、信号量隔离。
线程池隔离：线程池隔离会为每一个依赖创立一个线程池来解决来自该依赖的申请，不同的依赖线程池互相隔离，就算依赖 A 出故障，导致线程池资源被耗尽，也不会影响其余依赖的线程池资源。
- 长处：反对排队和超时，反对异步调用。
- 毛病：线程的创立一个调度会造成肯定的性能开销。
- 实用场景：适宜耗时较长的接口场景，比方接口解决逻辑简单，且与第三方中间件有交互，因为线程池模式的申请线程与理论转发线程不是同一个，所以能够保障容器有足够的线程来解决新的申请。
信号量隔离模式：初始化信号量 currentCount=0，每进来一个申请须要先将 currentCount 自增，再判断 currentCount 的值是否小于零碎最大信号量，小于则继续执行，大于则间接返回，拒绝请求。
代码如下：
public boolean tryAcquire() {int currentCount = this.count.incrementAndGet();
if (currentCount > (Integer)this.numberOfPermits.get()) {this.count.decrementAndGet();
return false;
} else {return true;}
}- 长处：轻量，无额定的开销，只是一个简略的计数器
- 毛病：不反对工作排队和被动超时；不反对异步调用
- 实用场景：适宜能疾速响应的接口场景，不适宜一些耗时较长的接口场景，因为信号量模式下的申请线程与转发解决线程是同一个，如果接口耗时过长有可能会占满容器的线程数。
| 隔离形式 | 是否反对超时 | 是否反对熔断 | 隔离原理 | 是否异步调用 | 资源耗费 |
|---|---|---|---|---|---|
| 线程池隔离 | 反对，可间接返回 | 反对，当线程池达到 maxSize 后，再申请会触发 fallback 接口进行熔断 | 每个服务独自用线程池，申请线程与转发解决线程不是同一个 | 能够是异步，也能够是同步。看调用的办法 | 大，大量线程的上下文切换，容易造成机器负载高 |
| 信号量隔离 | 不反对，如果阻塞，只能通过调用协定（如：socket 超时能力返回） | 反对，当信号量达到 maxConcurrentRequests 后。再申请会触发 fallback | 通过信号量的计数器，申请线程与转发解决线程是同一个 | 同步调用，不反对异步 | 小，只是个计数器 |
2. 断路器
断路器工作原理如下：
Hystrix 是基于滚筒式来解决，每一秒会产生一个 buckets，每产生一个新的 buckets 就会移除一个最老的 buckets，默认是 10 秒一个窗口。buckets 在内存中就是一种数据结构，每个 buckets 会记录 Metrics 的相干数据，比方胜利、失败、超时、回绝。
当一个 HystrixCommand 进来后，会先通过 allowRequest()办法判断是否容许通过该次申请，allowRequest()办法会通过 isOpen 判断断路器是否关上。断路器敞开，则容许通过该次申请；断路器关上，则会判断是否过了睡眠周期。没有过睡眠周期则返回 false，回绝通过该次申请，过了睡眠周期则会尝试放行。
isOpen()办法会依照 (failure) / (success+failure) 公式计算出失败率，如果失败率大于阈值，则会触发熔断。公式中的胜利、失败的数据就来源于每 10 秒中一个窗口的滚筒数据。
对于一个依赖调用，要么调用胜利，要么调用失败（包含异样、超时、回绝），这些调用后果都会记录到 buckets 中。对于调用胜利后果来说，还会判断断路器开关是否关上，如果是关上状态的话，则会敞开断路器并重置相干的计数器。
3. 降级回退
降级，通常指事务高峰期，为了保障外围服务失常运行，须要停掉一些不太重要的业务，或者某些服务不可用时，执行备用逻辑从故障服务中疾速失败或疾速返回，以保障主体业务不受影响。Hystrix 提供的降级次要是为了容错，保障以后服务不受依赖服务故障的影响，从而进步服务的健壮性。
1）哪些状况会进入降级逻辑
- 断路器关上
- 线程池 / 信号量资源有余
- 执行依赖调用超时
- 执行依赖调用异样
2）降级回退形式
（1）Fail Fast 疾速失败
疾速失败是最一般的命令执行办法，命令没有重写降级逻辑。如果命令执行产生任何类型的故障，它将间接抛出异样。
（2）Fail Fast 无声失败
指在降级办法中通过返回 null，空 Map，空 List 或其余相似的响应来实现。
（3）FallBack：Static
指在降级办法中返回动态默认值。这不会导致服务以“无声失败”的形式被删除，而是导致默认行为产生。如：利用依据命令执行返回 true / false 执行相应逻辑，但命令执行失败，则默认为 true。
（4）FallBack：Stubbed
当命令返回一个蕴含多个字段的复合对象时，适宜以 Stubbed 的形式回退。
（5）FallBack：Cache via Network
有时，如果调用依赖服务失败，能够从缓存服务（如 redis）中查问旧数据版本。因为又会发动近程调用，所以倡议从新封装一个 Command，应用不同的 ThreadPoolKey，与主线程池进行隔离。
（6）Primary+Secondary with FallBack
有时零碎具备两种行为 - 次要和主要，或次要和故障转移。次要和主要逻辑波及到不同的网络调用和业务逻辑，所以须要将主次逻辑封装在不同的 Command 中，应用线程池进行隔离。为了实现主从逻辑切换，能够将主次 command 封装在外观 HystrixCommand 的 run 办法中，并联合配置核心设置的开关切换主从逻辑。因为主次逻辑都是通过线程池隔离的 HystrixCommand，因而外观 HystrixCommand 能够应用信号量隔离，而没有必要应用线程池隔离引入不必要的开销。
4. 申请后果缓存
理论利用场景很少，不予过多介绍。
5. 申请合并
理论利用场景很少，不予过多介绍。
五、Hystrix 工作流程
对于一次依赖调用，会被封装在一个 HystrixCommand 对象中，调用的执行有两种形式，一种是调用 execute()办法同步调用，另一种是调用 queue()办法进行异步调用。
执行时会判断断路器开关是否关上，如果断路器关上，则进入 getFallback()降级逻辑；如果断路器敞开，则判断线程池 / 信号量资源是否已满，如果资源满了，则进入 getFallback()降级逻辑；如果没满，则执行 run()办法。再判断执行 run()办法是否超时，超时则进入 getFallback()降级逻辑，run()办法执行失败，则进入 getFallback()降级逻辑，执行胜利则报告 Metrics。Metrics 中的数据包含执行胜利、超时、失败等状况的数据，Hystrix 会计算一个断路器的衰弱值，也就是失败率，当失败率超过阈值后则会触发断路器开关关上。
getFallback()逻辑为：如果没有实现 fallback()办法，则间接抛出异样，另外 fallback 降级也是须要资源的，在 fallback 时须要获取一个针对 fallback 的信号量，只有获取胜利能力 fallback，获取信号量失败，则抛出异样，获取信号量胜利，才会执行 fallback 办法并且会响应 fallback 办法中的内容。
六、参考资料
杨波老师的《微服务架构实战 160 讲》
https://github.com/Netflix/Hy…