Spring Cloud Hystrix——熔断器

1、雪崩效应
在微服务架构中通常会有多个服务层调用，基础服务的故障可能会导致级联故障，进而造成整个系统不可用的情况，这种现象被称为服务雪崩效应。服务雪崩效应是一种因“服务提供者”的不可用导致“服务消费者”的不可用，并将不可用逐渐放大的过程。

如下图所示：A作为服务提供者，B为A的服务消费者，C和D是B的服务消费者。A不可用引起了B的不可用，并将不可用像滚雪球一样放大到C和D时，雪崩效应就形成了。

2、服务雪崩原因分析
2.1、服务提供者不可用
2.2、重试加大流量
2.3、服务调用者不可用

3、使用Hystrix预防服务雪崩
Hystrix [hɪst'rɪks]的中文含义是豪猪，因其背上长满了刺而拥有自我保护能力。Netflix的 Hystrix 是一个帮助解决分布式系统交互时超时处理和容错的类库，它同样拥有保护系统的能力。

Hystrix的设计原则包括:
资源隔离
熔断器(断路器)
命令模式

4、Hystrix特性
4.1、熔断器机制
断路器很好理解，当Hystrix Command请求后端服务失败数量超过一定比例(默认50%)，断路器会切换到开路状态(Open)。这时所有请求会直接失败而不会发送到后端服务。 断路器保持在开路状态一段时间后(默认5秒)，自动切换到半开路状态(HALF-OPEN)。这时会判断下一次请求的返回情况， 如果请求成功，断路器切回闭路状态(CLOSED)， 否则重新切换到开路状态(OPEN)。 Hystrix的断路器就像我们家庭电路中的保险丝，一旦后端服务不可用，断路器会直接切断请求链，避免发送大量无效请求影响系统吞吐量， 并且断路器有自我检测并恢复的能力。

熔断器开关相互转换的逻辑图：

4.2、Fallback
Fallback相当于是降级操作。对于查询操作，我们可以实现一个fallback方法，当请求后端服务出现异常的时候，可以使用fallback方法返回的值。 fallback方法的返回值一般是设置的默认值或者来自缓存。

4.3、资源隔离
在Hystrix中，主要通过线程池来实现资源隔离。通常在使用的时候我们会根据调用的远程服务划分出多个线程池。例如调用产品服务的Command放入A线程池， 调用账户服务的Command放入B线程池。这样做的主要优点是运行环境被隔离开了。这样就算调用服务的代码存在bug或者由于其他原因导致自己所在线程池被耗尽时， 不会对系统的其他服务造成影响。但是带来的代价就是维护多个线程池会对系统带来额外的性能开销。如果是对性能有严格要求而且确信自己调用服务的客户端代码不会出问题的话， 可以使用Hystrix的信号模式(Semaphores)来隔离资源。