Hystrix

灾难性的雪崩效应

在微服务架构的项目中，尤其是中大型项目，肯定会出现一个服务调用其他的服务，其他服务又调用别的服务，服务和服务之间形成了一种链式的调用关系。

如果少量请求最终访问的都是一个最终服务。当其中某个服务突然遇到大量请求时，整个链条上所有服务负载。这种情况就称为灾难性的雪崩效应。

原因：

服务提供者(Application Service)不可用。如：硬件故障，程序BUG，缓存击穿，并发请求量过大

重试加大流量。如：用户重试，代码重试逻辑等

服务调用者（Application client)不可用。如：同步请求阻塞造成的资源耗尽等

雪崩效应最终结果是：

服务链条中的某个服务不可用，导致一系列的服务不可用，最终造成服务逻辑崩溃。这种问题造成的后果，往往是无法预料的。

如何防止灾难性雪崩效应

降级

超时降级、资源不足时（线程或者信号量）降级，降级后可以配合降级接口返回托底数据，实现一个fallback方法，当请求后端服务出现异常时，可以使用fallback方法返回的值

保证：服务出问题整个项目还可以继续运行

降级指，当请求超时时，资源不足等情况发生时进行服务降级处理，不调用真实服务逻辑，而是使用快速失败（fallback)方式直接返回一个托底数据，保证服务链条的完整，避免服务雪崩

解决：避免application client请求application service时，出现服务调用错误或网络问题。处理手法都是在application client中实现。我们需要在application client相关工程中导入hystrix依赖信息。并在对应的启动类上增加新的注解@EnableCircuitBreaker,这个注解是用于开启hystrix熔断器的，简言之，就是让代码中hystrix相关注解生效

熔断

当失败率（如网络故障/超时造成的失败率高）达到阈值自动触发降级，熔断器欻的快速失败会进行快速恢复

通俗理解：熔断就时具有特定条件的降级，当出现熔断时在设定的时间内容就不再请求Application Service了。所以再代码上熔断和降级都是一个注解

保证：服务出现问题整个项目还可以继续运行。

当一定时间内，异常请求比例（请求超时、网络故障、服务异常等）达到阈值时，启动熔断器，熔断器一旦启动，则会停止调用具体服务逻辑，通过fallback快速返回托底数据，保证服务链的完整

熔断有自动恢复机制，如：当熔断器启动后， 每隔5s，尝试将新的请求发送给Application Service,如果服务可正常执行并返回结果，则关闭熔断器，服务恢复。如果仍旧调用失败，则继续返回托底数据，熔断器持续开启状态。

降级是出错了返回托底数据，熔断是出错后如果开启了熔断将会一定时间不再访问application service

请求缓存

提供了请求缓存。服务A调用服务B，如果在A中添加请求缓存，第一次请求后走缓存了，就不再访问服务B了，即使出现大量请求时，也不会对B产生高负载

请求缓存可以使用Spring Cache实现。

请求合并

提供请求合并。当服务A调用服务B时，设定在5毫秒内所有请求合并倒一起，对于服务B的负载就会大大减少，解决了对于服务B负载激增的问题。

保证：减少对Application Service的调用

什么情况下使用请求合并？

在微服务架构中，我们将一个项目拆分成很多个独立的项目，这些独立的项目通过远程调用来互相配合工作，但是，在高并发情况下，通信次数的增加会导致总的通信时间增加，同时线程池的资源也是有限的，高并发环境会导致有大量的线程处于等待状态，进而导致响应延迟。

请求合并的缺点

设置请求合并后，本来一个请求可能5ms就搞定了，但是现在必须再等10ms看看还有没有其他的请求一起的，这样一个请求的耗时就从5ms增加倒15ms了，不过，如果我们要发起的命令本身就是一个高延迟的命令，那么这个时候就可以使用请求合并了，因为这个时候时间窗的时间消耗就显得微不足道了，另外高并发也是请求合并的一个非常重要的场景

隔离

隔离分为线程池隔离和信号量隔离。通过判断线程池或者信号量是否已满，超出容量的请求直接降级，从而达到限流的作用

线程池隔离：

Hystrix采用Bulkhead Partition舱壁隔离技术

舱壁隔离指的是将船体内部分为多个隔舱，一旦其中某几个隔舱发生破损进水，水流不会在其他舱壁中流动，从而保证船舱依然具有足够的浮力和稳定性，降低沉船的危险

优点：

1. 任何一个服务都会被隔离在自己的线程池内，即使自己的线程池资源填满也不会影响其他服务

2. 当依赖的服务重新恢复时，可通过清理线程池，瞬间恢复服务的调用。但是如果时tomcat线程池被填满，再恢复就会很麻烦

3. 每个都是独立线程池。一定程度上解决了高并发问题

4. 由于线程池中线程个数是有限制，所以也解决了限流问题

缺点：

1. 增加了CPU开销。因为不仅仅有Tomcat的线程池，还需要有Hystrix线程池

2. 每个操作都是独立的线程，就有排队、调度和上下文切换等问题

信号量隔离

信号量：java.util.concurrent.Semaphore用来控制可同时并发的线程数。通过构造方法指定内部虚拟许可的数量。每次线程执行操作时先通过acquire方法获得许可，执行完毕再通过release方法释放许可。如果无可用许可，那么acquire方法将一种阻塞，直到其他线程释放许可。

每接受一个请求，都是服务自身线程去直接调用依赖服务，信号量就相当于一道管卡，每个线程通过关卡后，信号量-1，当为0时不再允许线程通过，而是直接执行fallback逻辑并返回，说白了仅做了一个限流