Spring Cloud Hystrix组件

简介

Spring Cloud Netflix Hystrix是隔离措施的一种实现，可以设置在某种超时或失败的情形下断开依赖调用，或者返回指定逻辑，从而提高分布式系统的稳定性。

举个生活中的例子，如电力过载保护器，当电流过大的的时候，保护器会自动断开，从而保护电器不受烧坏。因此Hystrix请求熔断的机制跟电力过载保护器的原理很类似。

雪崩效应

在微服务架构中，存在很多的微服务单元，各个微服务之间通过网络进行通讯，难免出现依赖关系，若某一个单元出现故障，就很容易因依赖关系而引发故障的蔓延，产生“雪崩效应”，最终导致整个系统的瘫痪。

如图所示：A作为服务提供者，B为A的服务消费者，C和D是B的服务消费者。A不可用引起了B的不可用，并将不可用像滚雪球一样放大到C和D时，雪崩效应就形成了。也就应了那句话：星星之火，可以燎原！

导致服务不可用的原因
在分布式系统中必然会出现很多远程调用，每一次远程调用都对应着一个线程/进程，如果响应太慢，这个线程得不到释放，那么就会一直占用着系统资源，如果此类线程过多，就会耗尽资源，最终导致服务不可用。

断路器模式
所以我们会使用断路器模式，断路器可理解为对容易导致错误的操作的代理，这种代理能够统计一段时间内调用失败的次数，并决定是正常请求依赖的服务还是直接返回。断路器也可以自动诊断依赖的服务是否已经恢复正常，如已恢复，那么就会恢复请求该服务。

断路器状态转换的逻辑

• 正常情况下，断路器是关闭状态，也就是不起任何作用的状态，可以正常的进行远程调用服务。
• 当一段时间内，请求失败率达到一定阈值(错误率达到50%，100次/分钟)断路器就会打开，这时所有请求会直接失败而不会发送到后端服务。
• 断路器打开一段时间后（Hystrix默认是5秒），会自动进入半开路状态，这个时候断路器可允许一个请求访问依赖的服务，如果请求调用成功，则关闭断路器，否则继续保持打开状态。

Hystrix特性

1. 请求熔断： 当Hystrix Command请求后端服务失败数量超过一定比例(默认50%)，断路器会切换到开路状态(Open)。这时所有请求会直接失败而不会发送到后端服务，断路器保持在开路状态一段时间后(默认5秒),，自动切换到半开路状态(HALF-OPEN)。 这时会判断下一次请求的返回情况, 如果请求成功, 断路器切回闭路状态(CLOSED), 否则重新切换到开路状态(OPEN). Hystrix的断路器就像我们家庭电路中的保险丝, 一旦后端服务不可用, 断路器会直接切断请求链, 避免发送大量无效请求影响系统吞吐量, 并且断路器有自我检测并恢复的能力.
2. 服务降级：Fallback相当于是降级操作。对于查询操作，我们可以实现一个fallback方法，当请求后端服务出现异常的时候，可以使用fallback方法返回的值。fallback方法的返回值一般是设置的默认值或者来自缓存。告知后面的请求服务不可用了，不要再来了。
3. 依赖隔离(采用舱壁模式，Docker就是舱壁模式的一种)：在Hystrix中，主要通过线程池来实现资源隔离。 通常在使用的时候我们会根据调用的远程服务划分出多个线程池，比如说，一个服务调用另外两个服务，你如果调用两个服务都用一个线程池，那么如果一个服务卡在哪里，资源没被释放，后面的请求又来了，导致后面的请求都卡在哪里等待，导致你依赖的A服务把你卡在哪里，耗尽了资源，也导致了你另外一个B服务也不可用了。这时如果依赖隔离，某一个服务调用A B两个服务，如果这时我有100个线程可用，我给A服务分配50个，给B服务分配50个，这样就算A服务挂了，我的B服务依然可以用。
4. 请求缓存：比如一个请求过来请求我userId=1的数据，你后面的请求也过来请求同样的数据，这时我不会继续走原来的那条请求链路了，而是把第一次请求缓存过来，把第一次的请求结果返回给后面的请求。
5. 请求合并：我依赖于某一个服务，我要调用N次，比如说查数据库的时候，我发了N条请求发了N条SQL然后拿到一堆结果，这时候我们可以把多个请求合并成一个请求，发送一个查询多条数据的SQL的请求，这样我们只需查询一次数据库，提升了效率。