1、断路器
在消费服务的启动类，添加注解：@EnableCircuitBreaker，在消费服务的调用类上，添加注解：@HystrixCommand(fallbackMethod = "") -> 失败了调的方法。（熔断超时默认 2s ）
当被调用的服务，超时或者未反应/down掉，就会触发熔断请求，返回定义的逻辑。
工作流程：
1）、加注解：@HystrixCommand 或 @HystrixObservableCommand ，前者用于依赖的服务返回单个操作结果的时候，后者用于依赖的服务返回多个操作结果的时候。(具体的实现看书籍)
命令模式，将客户端请求封装为一个对象，能让不同的请求对客户端进行参数化。（让不同类型的参数，都可以请求）
2）、命令执行：
HystrixCommand 实现了 execute()、queue() 执行方法。
execute()：同步执行，从依赖的服务返回一个单一的结果对象，或错误时抛出异常，R value = command.execute()；
queue()：异步执行，直接返回一个 Future 对象，其中包含了服务执行结束时返回的单一结果对象，Future<R> fValue = command.queue()；
HystrixObservableCommand 实现了 observe()、toObservable() 执行方法。
Observable<R> obValue = command.observe()，代表操作了多个结果，返回 HotObservanle；
Observable<R> ocValue = command.toObservable()，也代表操作了多个结果，返回 Cold Observable;
Hystrix 底层实现了大量的 RxJava，RxJava 的观察者-订阅者模式。
Observable 向订阅者 Subscriber 对象发布事件(即异服务调用)，一个Observable 可以发出多个事件，直到结束或者发生异常。每发出一个事件，就会调用对应观察者 Subscriber.onNext() 方法。最后一定会调用 Subscriber.onCompleted() 或者 Subscriber.onError() 结束该时间的操作流。
3）、结果是否被缓存：当命令的请求缓存功能开启，命令缓存命中，缓存的结果就会以 Observable 对象的形式返回。
4）、断路器是否打开： - 断路器是否已经开始运行
命令结果没有命中缓存中，如果断路器打开，Hystrix 不会执行命令，而是转到 fallback 处理逻辑。如果断路器关闭，则继续执行。
5）、线程池/请求队列/信号量是否占满： - 线程太多
如果与命令相关的线程池或请求队列或者信号量已经占满，则 Hystrix 也不会执行命令，而是转接到 fallback 处理逻辑。
该线程池并非容易的线程池，而是每个依赖服务的专有线程池。
6）、请求依赖服务：
HystrixObserveableCommand.construct() 或 HystrixCommand.run()，决定了采取什么样的方式去请求依赖服务。
第一种返回一个 Observable 对象来发射多个结果，或通过 onError 发送错误通知；
第二种返回一个单一的结果，或者抛出异常。
超时也会转到 fallback 处理逻辑。
7）、计算断路器的健康度： - 服务调用失败/超时等超过设置
Hystrix 会将成功、失败、拒绝、超时等信息报告给断路器，断路器会维护一组计数器来统计这些数据。根据数据值，来对某个依赖服务的请求进行 "熔断/短路"，直到恢复期结束。在恢复期结束后，再根据统计数据判断是否还是未达到健康指标，或再次"熔断/短路"。
8）、fallback 处理：- 回退 - 服务降级
当命令执行失败的时候，Hystrix 会进入 fallback 尝试回退处理，该操作叫做 "服务降级"。
第4、5、6步都可能会引起服务降级。
最终的降级逻辑一定不是一个依赖网络请求的处理，而是一个能够稳定返回结果的处理逻辑。
HystrixCommand.getFallback() 来实现服务降级；
HystrixObservableCommand.resumeWithFallback() 来实现降级逻辑。
9）、返回成功的响应：
2、断路器原理
HystrixCricuitBreaker 接口：
allowRequest：每个 hystrix 命令的请求都通过它判断是否被执行；
isOpen：返回当前断路器是否打开；
markSuccess()：用来闭合断路器，并重置度量指标对象。
HystrixCricuitBreakImpl 是实现类，有几个重要核心对象，一个是 HystrixCommand 实例的属性对象，一个是记录各个度量指标的对象，一个是断路器是否打开的标志，一个是断路器打开或上一次测试的时间戳。
断路器从关闭到打开（默认时间窗10s的请求信息快照）：
1）、请求总数 QPS 在预设的阈值范围内就返回 false，表示断路器还是关闭。阈值默认值20。
2）、错误百分比在阈值范围内就返回 false，表示断路器还是关闭。默认是50。
3）、以上两个条件都不满足，断路器就设置为打开状态（熔断/短路）。如果是从关闭状态切到打开状态，就将当前时间记录到上面的时间戳对象中。
allowSingleTest() 为断路器再设置一个休眠时间（默认5s），在该休眠时间达到只有，再次允许请求尝试访问。若请求再次失败，断路器又进入打开状态。请求成功，则是关闭状态。
所以 allowSingleTest() 与 isOpen() 方法的配合，实现了断路器的打开和关闭状态的切换。
3、依赖隔离
会为每个依赖服务创建一个独立的线程池，这样就算某个依赖服务出现问题后，也只对该依赖服务的调用产生影响，不影响其他依赖服务。
特点：
依赖的服务从失效恢复正常后，它的线程池会被清理并且能够马上恢复健康服务。容器级别的清理 恢复速度慢的多；
当依赖的服务出现配置错误的时候，线程池会被快速反映出此问题（失败、延迟、超时、拒绝等增加情况）。
线程池的开销在设计的时候做过实验，消耗相对于来说是微乎其微的。对于某些需求来说，如果该消耗觉得很大，又用了信号量来优化。
信号量控制单个依赖服务的并发量，但是不能设置超时和实现异步访问。线程池和信号量可以切换。
在降级逻辑，Hystrix 尝试降级逻辑时，会在调用线程中使用信号量。或者命令执行。
4、使用详解
1）、创建请求命令
可以用继承 HystrixCommand 或者 @HystrixCommand 来实现熔断，注解添加在异服务之间调用的接口上。
并且该注解可以实现 同步/异步 的操作。异步用 Future<T> 接收返回参数。
2）、定义服务降级
fallback 是 Hystrix 命令执行失败后使用的后备办法，实现服务的降级处理逻辑。
继承方式的话，用重载 getFallback() 方法来实现降级处理；
注解方式 @HystrixCommand(fallbackMethod = "failMethod") ，定义一个 faliMethod 方法，作为降级处理。（在同一个类中）
3）、异常处理
当服务调用发生异常，除了 HystrixBadRequestException 之外，其他异常都会被 Hystrix 认为命令执行失败，并触发服务降级的处理逻辑。
使用注解 @HystrixCommand(ignoreExceptions = {XXException.class}) 可以忽略指定异常类型。当遇到该类型的异常时，就会被包装 HystrixBadRequestException 异常抛出，而不会触发降级的处理逻辑。
4）、异常获取
异常获取到后，可以根据不同的异常判断，做出不同的处理方式。直接在 fallback() 方法里定义一个 Throwable e ，就可以获取触发降级的具体异常内容。（e.getMessage()）
5）、命令名称、分组以及线程池划分
Hystrix 会让相同组名的命令使用同一个线程池。所以创建 Hystrix 命令时，为其制定命令组名来实现默认的线程池划分。（还提供了 HystrixThreadPoolKey 来对线程池进行设置，进行更加细粒度的线程池划分，实际情况通常使用这一种划分方式）
注解方式实现：@HystrixCommand(commandKey="getUserById"，groupKey="UserGroup"，ThreadPoolKey="getUserByIdThread")
6）、请求缓存
开启请求缓存功能：继承方式，重载 getCacheKey() 方式来开启请求缓存。
好处：
减少重复请求数，降低依赖服务的并发度（降低压力）；
在同一用户请求的上下文中，相同依赖服务的返回数据一致；
请求缓存在 run() 和 construct() 执行之前生效，可以减少不必要的线程开销；
清理失效缓存功能：通过 HystrixRequestCache.clear() 方法来进行缓存的清理，在做更新操作时，就将缓存清理掉。
注解方式：@CacheResult 标记请求命令返回的结果应该被缓存，必须和 @HystrixCommand 结合使用；
@CacheRemove 让请求命令的缓存失效，失效的缓存是根据 key 来的。（commandKey）
@CacheKey 给参数添加标记，使之成为缓存的 key。
7）、请求合并
远程调用最常见的问题就是 通信消耗和连接总数。Hystrix 提供了 HystrixCollapser 来实现请求的合并，以减少通信消耗和线程池的占用。
HystrixCollapser 实现了 在 @HystrixCommand 之前放置了一个合并处理器，将处于一个很短时间内（默认10ms）对同一依赖服务的多个请求进行整合并以批量方式发起请求。