Spring Cloud Hystrix 原理简介和实现

设计原则

• 防止单个服务的故障，耗尽整个系统服务的容器（比如tomcat）的线程资源，避免分布式环境里大量级联失败。

  通过第三方客户端访问（通常是通过网络）依赖服务出现失败、拒绝、超时或短路时执行回退逻辑

• 用快速失败代替排队(每个依赖服务维护一个小的线程池或信号量，当线程池满或信号量满，会立即拒绝服务而不会排队等待)和优雅的服务降级；

  当依赖服务失效后又恢复正常，快速恢复   

• 提供接近实时的监控和警报，从而能够快速发现故障和修复。

  监控信息包括请求成功，失败（客户端抛出的异常），超时和线程拒绝。

  如果访问依赖服务的错误百分比超过阈值,断路器会跳闸，此时服务会在一段时间内停止对特定服务的所有请求   

• 将所有请求外部系统（或请求依赖服务）封装到HystrixCommand或HystrixObservableCommand对象中，然后这些请求在一个独立的线程中执行。

  使用隔离技术来限制任何一个依赖的失败对系统的影响。

  每个依赖服务维护一个小的线程池（或信号量），当线程池满或信号量满，会立即拒绝服务而不会排队等待

Hystrix特性

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

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

• 依赖隔离(采用舱壁模式，Docker就是舱壁模式的一种)：在Hystrix中, 主要通过线程池来实现资源隔离. 通常在使用的时候我们会根据调用的远程服务划分出多个线程池.比如说，一个服务调用两外两个服务，你如果调用两个服务都用一个线程池，那么如果一个服务卡在哪里，资源没被释放后面的请求又来了，导致后面的请求都卡在哪里等待，导致你依赖的A服务把你卡在哪里，耗尽了资源，也导致了你另外一个B服务也不可用了。这时如果依赖隔离，某一个服务调用A B两个服务，如果这时我有100个线程可用，我给A服务分配50个，给B服务分配50个，这样就算A服务挂了，我的B服务依然可以用。

• 请求缓存：比如一个请求过来请求我userId=1的数据，你后面的请求也过来请求同样的数据，这时我不会继续走原来的那条请求链路了，而是把第一次请求缓存过了，把第一次的请求结果返回给后面的请求。

• 请求合并：我依赖于某一个服务，我要调用N次，比如说查数据库的时候，我发了N条请求发了N条SQL然后拿到一堆结果，这时候我们可以把多个请求合并成一个请求，发送一个查询多条数据的SQL的请求，这样我们只需查询一次数据库，提升了效率。

Hystrixl流程图如下：

Hystrix流程说明:

　1:每次调用创建一个新的HystrixCommand,把依赖调用封装在run()方法中.

    2:执行execute()/queue做同步或异步调用.

　3:判断熔断器(circuit-breaker)是否打开,如果打开跳到步骤8,进行降级策略,如果         关闭进入步骤.

　4:判断线程池/队列/信号量是否跑满，如果跑满进入降级步骤8,否则继续后续骤.

　5:调用HystrixCommand的run方法.运行依赖逻辑

　      5a:依赖逻辑调用超时,进入步骤8.

　6:判断逻辑是否调用成功

　     6a:返回成功调用结果

　     6b:调用出错，进入步骤8.

　7:计算熔断器状态,所有的运行状态(成功, 失败, 拒绝,超时)上报给熔断器，用于统计从而判断熔断器状态.

　8:getFallback()降级逻辑.以下四种情况将触发getFallback调用：

　　(1):run()方法抛出非HystrixBadRequestException异常。

　　(2):run()方法调用超时

　　(3):熔断器开启拦截调用

　　(4):线程池/队列/信号量是否跑满

　　    8a:没有实现getFallback的Command将直接抛出异常

　　    8b:fallback降级逻辑调用成功直接返回

　　    8c:降级逻辑调用失败抛出异常

　9:返回执行成功结果

• Hystrix 是 Netflix 开源的一款容错系统

• Hystrix 具备拥有回退机制和断路器功能的线程和信号隔离，请求缓存和请求打包（request collapsing，即自动批处理），以及监控和配置等功能。

• Hystrix具备服务降级、服务熔断、线程隔离、请求缓存、请求合并及服务监控等强大功能。

实战

创建一个hystrix-service模块

在pom.xml中添加相关依赖

在application.yml进行配置

主要是配置了端口、注册中心地址及user-service的调用路径

在启动类上添加@EnableCircuitBreaker来开启Hystrix的断路器功能

创建UserHystrixController接口用于调用user-service服务

服务降级演示

启动eureka-server、user-service、hystrix-service服务；

关闭user-service

@HystrixCommand中的常用参数

fallbackMethod：指定服务降级处理方法；

ignoreExceptions：忽略某些异常，不发生服务降级；

commandKey：命令名称，用于区分不同的命令；

groupKey：分组名称，Hystrix会根据不同的分组来统计命令的告警及仪表盘息

threadPoolKey：线程池名称，用于划分线程池。

设置命令、分组及线程池名称

使用ignoreExceptions忽略某些异常降级

Hystrix的请求缓存

当系统并发量越来越大时，我们需要使用缓存来优化系统，达到减轻并发请求线程数，提供响应速度的效果。

• @CacheResult：开启缓存，默认所有参数作为缓存的key，cacheKeyMethod可以通过返回String类型的方法指定key；

• @CacheKey：指定缓存的key，可以指定参数或指定参数中的属性值为缓存key，cacheKeyMethod还可以通过返回String类型的方法指定；

• @CacheRemove：移除缓存，需要指定commandKey。

只打印了一次日志 其他两次是读取的缓存

移除缓存测试

两次查询都没走缓存

缓存使用过程中的问题

在缓存使用过程中，我们需要在每次使用缓存的请求前后对HystrixRequestContext进行初始化和关闭，否则会出现如下异常：

java.lang.IllegalStateException: Request caching is not available. 

这里我们通过使用过滤器，在每个请求前后初始化和关闭HystrixRequestContext来解决该问题：

请求合并

微服务系统中的服务间通信，需要通过远程调用来实现，随着调用次数越来越多，占用线程资源也会越来越多。Hystrix中提供了@HystrixCollapser用于合并请求，从而达到减少通信消耗及线程数量的效果。

@HystrixCollapser的常用属性

batchMethod：用于设置请求合并的方法；

collapserProperties：请求合并属性，用于控制实例属性，有很多；

timerDelayInMilliseconds：collapserProperties中的属性，用于控制每隔多少时间合并一次请求；

功能演示

在UserHystrixController中添加testCollapser方法，这里我们先进行两次服务调用，再间隔200ms以后进行第三次服务调用：

使用@HystrixCollapser实现请求合并，所有对getUserFuture的的多次调用都会转化为对getUserByIds的单次调用：

访问接口测试http://localhost:8401/user/testCollapser，由于我们设置了100毫秒进行一次请求合并，前两次被合并，最后一次自己单独合并了。

Hystrix的常用配置

全局配置

实例配置

配置文件中相关key的说明

HystrixComandKey对应@HystrixCommand中的commandKey属性；

HystrixCollapserKey对应@HystrixCollapser注解中的collapserKey属性；

HystrixThreadPoolKey对应@HystrixCommand中的threadPoolKey属性

源码地址

https://gitee.com/pingfanrenbiji/springcloud-learning

使用到的模块

参考文章

https://my.oschina.net/dyyweb/blog/1919586

https://blog.csdn.net/zhenghongcs/article/details/100984837