IDEA激活码前言
在分布式环境中，完成一个业务，往往会依赖很多服务。比如用户购买一个商品，可能会经过订单、库存、支付等等服务。由于分布式环境的复杂性，避免不了其中某一个服务因为网络通讯问题连接不上或者资源占用过高导致down机等等，如果没有服务保护措施，那么很有可能因为其中一个服务的问题，拖垮整个服务调用链。
SpringCloud就提供了一个组件Hystrix来解决此问题，Hystrix可以设置在某种超时或者失败情形下断开依赖调用或者返回指定逻辑,从而提高分布式系统的稳定性。
什么是Hystrix？
Hystrix 是一个用于处理分布式环境下的容错组件，在分布式系统里，许多服务依赖不可避免的会调用失败，比如超时、异常等，Hystrix能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性和高可用。
降级：在高并发情况下，服务无法同时处理大量的请求，防止用户一直等待，消耗服务资源，使用服务降级的方式返回一个友好的提示。Hystrix会调用指定的fallBack来进行服务降级。
例如：我们对一个查询用户信息的接口, 实现一个fallback方法, 当请求后端服务出现异常或者等待超过一定的时间就会触发fallback方法返回的相应的信息。
熔断：Hystrix的熔断就好比我们在生活中常见的断路器，当电路短路或者负载过高的时候，断路器会自动切断电源，防止发生更严重的事故。
例如：用户购买商品，点击下单，订单服务会先调用库存服务进行扣件库存，结果发送一个请求过去，库存系统因为出现了故障，没有任何响应，此时就会一直等待，同时其它用户也在下单，不断的在请求库存服务，不断的创建线程，因为没有返回结果，也就资源没有释放，最终导致了系统资源被耗尽，订单服务也出现问题。订单系统本来是好好的，结果访问了一个有问题的库存系统，结果导致订单系统也奔溃了，再继续调用更多的依赖服务，可能会导致更多的系统奔溃。此时出现故障的服务就没有必要要再让其他的请求去访问这个服务了，这个时候就应该使用熔断进行快速失败，保护服务，并给用户返回一个友好的提示。通常服务熔断和降级是一起使用的。
限流：限流模式主要是提前对各个类型的请求设置最高的QPS阈值，若高于设置的阈值则对该请求直接返回，不再调用后续资源。这种模式不能解决服务依赖的问题，只能解决系统整体资源分配问题，因为没有被限流的请求依然有可能造成雪崩效应。Hystrix通过线程池或者信号量技术进行限流访问。
Hystrix设计原则
- 防止单个服务的故障，耗尽整个系统服务的容器（比如tomcat）的线程资源，避免分布式环境里大量级联失败。通过第三方客户端访问（通常是通过网络）依赖服务出现失败、拒绝、超时或短路时执行回退逻辑；
- 用快速失败代替排队(每个依赖服务维护一个小的线程池或信号量，当线程池满或信号量满，会立即拒绝服务而不会排队等待)和优雅的服务降级；当依赖服务失效后又恢复正常，快速恢复；
- 提供接近实时的监控和警报，从而能够快速发现故障和修复。监控信息包括请求成功，失败（客户端抛出的异常），超时和线程拒绝。如果访问依赖服务的错误百分比超过阈值,断路器会跳闸，此时服务会在一段时间内停止对特定服务的所有请求；
- 将所有请求外部系统（或请求依赖服务）封装到HystrixCommand或
HystrixObservableCommand对象中，然后这些请求在一个独立的线程中执行。使用隔离技术来限制任何一个依赖的失败对系统的影响。每个依赖服务维护一个小的线程池（或信号量），当线程池满或信号量满，会立即拒绝服务而不会排队等待；
Hystrix特性
- 请求熔断： 当Hystrix Command请求后端服务失败数量超过一定比例(默认50%), 断路器会切换到开路状态(Open). 这时所有请求会直接失败而不会发送到后端服务. 断路器保持在开路状态一段时间后(默认5秒), 自动切换到半开路状态(HALF-OPEN)，这时会判断下一次请求的返回情况, 如果请求成功, 断路器切回闭路状态(CLOSED), 否则重新切换到开路状态(OPEN). Hystrix的断路器就像我们家庭电路中的保险丝, 一旦后端服务不可用, 断路器会直接切断请求链, 避免发送大量无效请求影响系统吞吐量, 并且断路器有自我检测并恢复的能力.
- 服务降级：Fallback相当于是降级操作. 对于查询操作, 我们可以实现一个fallback方法, 当请求后端服务出现异常的时候, 可以使用fallback方法返回的值. fallback方法的返回值一般是设置的默认值或者来自缓存.告知后面的请求服务不可用了，不要再来了。
-
依赖隔离(采用舱壁模式，Docker就是舱壁模式的一种)：在Hystrix中, 主要通过线程池来实现资源隔离. 通常在使用的时候我们会根据调用的远程服务划分出多个线程池.比如说，一个服务调用两外两个服务，你如果调用两个服务都用一个线程池，那么如果一个服务卡在哪里，资源没被释放，后面的请求又来了，导致后面的请求都卡在哪里等待，导致你依赖的A服务把你卡在哪里，耗尽了资源，也导致了你另外一个B服务也不可用了。这时如果依赖隔离，某一个服务调用A B两个服务，如果这时我有100个线程可用，我给A服务分配50个，给B服务分配50个，这样就算A服务挂了，我的B服务依然可以用。
-
请求缓存：比如一个请求过来请求我userId=1的数据，你后面的请求也过来请求同样的数据，这时我不会继续走原来的那条请求链路了，而是把第一次请求缓存过了，把第一次的请求结果返回给后面的请求。
-
请求合并：我依赖于某一个服务，我要调用N次，比如说查数据库的时候，我发了N条请求发了N条SQL然后拿到一堆结果，这时候我们可以把多个请求合并成一个请求，发送一个查询多条数据的SQL的请求，这样我们只需查询一次数据库，提升了效率。
Hystrix工作流程
流程图：
流程说明：
- 每次调用创建一个新的
HystrixCommand，把依赖调用封装在run()方法中； - 执行
execute()/queue做同步或异步调用； - 判断熔断器(
circuit-breaker)是否打开,如果打开跳到步骤7,进行降级策略，否额进入步骤4； - 判断线程池/队列/信号量是否跑满，如果跑满进入降级步骤7,否则继续后续步骤5；
- 调用
HystrixCommand的run方法.运行依赖逻辑：
5.1. 依赖逻辑调用超时,进入步骤7； - 判断逻辑是否调用成功：
6.1. 返回成功调用结果
6.2. 调用出错，进入步骤8. - 计算熔断器状态,所有的运行状态(成功, 失败, 拒绝,超时)上报给熔断器，用于统计从而判断熔断器状态.
- getFallback()降级逻辑.以下四种情况将触发
getFallback调用：
1).run()方法抛出非HystrixBadRequestException异常。
2).run()方法调用超时
3). 熔断器开启拦截调用
4). 线程池/队列/信号量是否跑满
8.1. 没有实现getFallback的Command将直接抛出异常
8.2.fallback降级逻辑调用成功直接返回
8.3. 降级逻辑调用失败抛出异常 - 返回执行成功结果
参考：
https://github.com/Netflix/Hystrix/wiki
https://www.cnblogs.com/huangjuncong/p/9026949.html
