设计原则
-
防止单个服务的故障，耗尽整个系统服务的容器（比如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
网友评论