开始Hystrix的学习~~
首先Hystrix是为了提供更强大的容错能力而设计的，通过控制那些访问远程服务、系统或第三方库的节点来应对延迟或故障。微服务架构中各节点间的访问和请求是频繁的，Hystrix具备了服务降级、服务熔断、线程和信号隔离、请求缓存、请求合并以及服务监控等功能。

Hystrix

工作流程

1. 创建HystrixCommand或HystrixObservableCommand对象。前者用在依赖的服务返回单个操作结果，后者用在依赖的服务返回多个操作结果。
2. 命令执行。
   HystrixCommand实现两个执行方式：execute()，同步执行；queue()，异步执行，返回Future对象。
   HystrixObservableCommand也有两个执行方式：observe()返回observable对象，是一个Hot Observable；toObservable()返回的是cold Observable对象
3. 结果是否缓存。若缓存功能启用，且命中缓存，缓存的结果会以Observable对象的形式返回。
4. 断路器是否打开
5. 线程池、信号量、请求队列是否已满
6. HystrixCommand.run()或HystrixObservableCommand.construct()。
7. 计算断路器的健康度
8. Fallback处理
9. 返回成功的响应

---

断路器

public interface HystrixCircuitBreaker{//维护一个Hystrix命令与Breaker的ConcurrentHashMappublic static class Factory{...}/*接口实现类，定义了四个对象*HystrixCommandProperties、HystrixCommandMetrics、circuitOpen、circuitOpenOrLastTestedTime*并对接口方法进行实现：isOpen()若表示是true，则返回true；否则从metrics*中获取信息进一步判断，包括QPS、错误百分比。allowRequest()方法中有一个*allowSingleTest方法会在休眠时间后再次允许请求尝试访问。markSuccess方法*在半开路状态时使用，若Hystrix命令调用成功，通过调用它将打开的断路器关闭，*并重置度量指标对象HystrixCommandMetrics metrics*/static class HystrixCircuitBreakerImpl implements HystrixCircuitBreaker{...}//定义了一个什么都不做的Breakerstatic class NoOpCicuitBreaker implements HystrixCircuitBreaker{...}public boolean allowRequest();//Hystrix命令的请求通过它判断是否执行public boolean isOpen();//判断当前断路器是否打开void markSuccess();//用来闭合断路器
}

---

依赖隔离

使用舱壁模式实现线程的隔离，为每个服务创建一个独立的线程池。
还可以使用信号量控制单个服务的并发量，但不能设置超时和实现异步访问。
其中设置命令名称、分组以及线程池划分，可以通过@HystrixCommand中commandKey、groupKey、threadPoolKey属性来设置。

---

fallback

前文提到的工作流程第八步fallback处理，fallback是命令执行失败后的后备方法。在HystrixCommand中重载getFallback方法。也可以使用注解@HystrixCommand(fallbackMethod="MethodName")。在执行写操作的命令或批处理或离线计算的命令不需要降级处理，失败时将错误信息传递给调用者即可。
抛出HystrixBadRequestException不会进入降级逻辑。可以配置@HystrixCommand的ignoreExceptions参数，忽略指定的异常，不触发fallback。
在异常后进入降级逻辑后，如何获取是什么异常：若是继承的方式，可以通过getExecutionException()；若是注解的方式，则在fallback的实现方法的参数中加一个Throwable类型的参数。

---

缓存

继承形式下，重载getCacheKey方法开启请求缓存。
首先尝试获取请求缓存，判断是否启用了请求缓存。如果开启了并重写了getCacheKey方法，返回非null的缓存key值，通过该值调用get方法获取HystrixCachedObservable缓存对象。
然后将请求结果加入缓存，仍需判断并返回key值，获取HystrixCachedObservable。请求缓存对象HystrixRequestCache中维护了一个线程安全的map存放请求缓存的响应。
使用注解实现缓存：@CacheResult与@HystrixCommand结合使用，标记返回结果应该被缓存；@CacheRemove，让缓存失效；@CacheKey标记参数为缓存的key值。

---

请求合并

提供了HystrixCollapser实现。在HystrixCommand之前放一个合并处理器，将处于一个很短的时间窗内对同一依赖服务的多个请求进行整合，并已批量的方式发起请求。未合并时，每个请求都会在服务的独立线程池里申请一个线程完成请求；合并后，合并为一个请求发向服务的批量接口，批量结果再由请求合并器拆分并分配给每个被合并的请求。
注解的方式：

@HystrixCollapser(batchMethod="方法名字/findAll",collapserProperties={@HystrixProperty(name="timerDelayInMilliseconds",value="5000")})
public User find(){}@HystrixCommand
public List<User> findAll(List<String> ids){}

实例使用时，注意在启动类上加上注解**@EnableHystrix**，否则请求不会合并。
需要注意请求合并会有额外开销，用于请求合并的延迟时间窗会使依赖服务的延迟增高。因此使用时，需考虑请求命令本身的延迟以及延迟时间窗内的并发量。

---

Hystrix Dashboard

主类上加上@EnableHystrixDashboard。默认为集群监控。指定的集群监控通过url的?cluster=[clusterName]来实现。单体应用的监控则需要为服务实例添加端点：需要添加actuator的依赖，主类则使用@EnableCircuitBreaker注解。
还可通过Turbine汇集监控信息，依赖加上Turbine，主类使用@EnableTurbine，配置上

turbine.app-config=RIBBON-CONSUMER;
turbine.cluster-name-expression="default";
turbine.combine-host-port=true;

还可现将所有的监控信息输出到信息代理中，然后由Turbine从中异步获取信息，最后聚集显示在Dashboard.