学习SpringCloud微服务是参考纯洁的微笑博客，看到他提到股市的熔断我也忍不住吐槽一下，记得当时实施熔断第一天就熔断了，现在想想也还是搞笑，从之前的全民炒股到现在的全民炒房，都是一个炒字，问题是现在的房市和之前股市的5000点一样，再加上贸易战、人口老龄化等因素，不知道能撑多久，可能是一悲观主义者，我是不太乐观。
熔断和家里的保险丝一样，启动保护作用，电压过高或过低会导致电器损坏，保险丝的作用就是当电压异常时直接断掉，不至于影响其他电器的使用，而且保险丝也只是一根线，坏掉也影响不大，是预防雪崩的一种方法。Redis里面有雪崩和穿透，SpringCloud中也有雪崩。A服务调用B服务、B服务调用C服务，C服务调用D服务，如果D服务挂了，那如果不做保护，C服务也会挂断，C挂了B也会挂，B挂了A也挂，这样就会都挂了，这就需要有一个壮士断腕的勇气，和习大大的理论是异曲同工之妙。一旦雪崩那恢复的顺序正好相反，应该先恢复D服务，再依次恢复C、B、A。不然假如先恢复A，那B还是挂了的，到时候A还是会挂。下面是比较书面的介绍。
1.断路器机制
断路器很好理解, 当Hystrix Command请求后端服务失败数量超过一定比例(默认50%), 断路器会切换到开路状态(Open). 这时所有请求会直接失败而不会发送到后端服务. 断路器保持在开路状态一段时间后(默认5秒), 自动切换到半开路状态(HALF-OPEN). 这时会判断下一次请求的返回情况, 如果请求成功, 断路器切回闭路状态(CLOSED), 否则重新切换到开路状态(OPEN). Hystrix的断路器就像我们家庭电路中的保险丝, 一旦后端服务不可用, 断路器会直接切断请求链, 避免发送大量无效请求影响系统吞吐量, 并且断路器有自我检测并恢复的能力.
2.Fallback
Fallback相当于是降级操作. 对于查询操作, 我们可以实现一个fallback方法, 当请求后端服务出现异常的时候, 可以使用fallback方法返回的值. fallback方法的返回值一般是设置的默认值或者来自缓存.
3.资源隔离
在Hystrix中, 主要通过线程池来实现资源隔离. 通常在使用的时候我们会根据调用的远程服务划分出多个线程池. 例如调用产品服务的Command放入A线程池, 调用账户服务的Command放入B线程池. 这样做的主要优点是运行环境被隔离开了. 这样就算调用服务的代码存在bug或者由于其他原因导致自己所在线程池被耗尽时, 不会对系统的其他服务造成影响. 但是带来的代价就是维护多个线程池会对系统带来额外的性能开销. 如果是对性能有严格要求而且确信自己调用服务的客户端代码不会出问题的话, 可以使用Hystrix的信号模式(Semaphores)来隔离资源.
在SpringCloud中实现也比较简单，Feign中已经依赖了Hystrix所以在maven配置上不用做任何改动，只需要三步即可。
1.配置文件
在上一博客的EurekaConsumer基础上，在属性文件中启动fegin的Hystrix功能。
feign.hystrix.enabled=true