Spring-Cloud-Hystrix

一、引入原因 微服务架构，各服务之间通过RPC进行调用，如果中间一个服务出现故障，导致任务积压，最终引发整个系统瘫痪。通过Hystrix，对故障进行监控，出现错误向调用方返回错误码，而不是长时间等待。 二、原理分析 本文基础架构如下

⚠️

• 在Ribbon-consumer上通过@EnableCircuitBreaker或者使用@SpringCloudApplication一步到位。

原理分析

1. 创建HystrixCommand或HystrixObservableCommand对象 命令模式

• 用于实现请求者与行为实现者的解耦

Reciever接收者 处理具体的业务逻辑 Command抽象命令 定义了一系列命令，触发Reciever去做具体的业务逻辑 ConcreteCommand 命令的具体实现 Invoker调用者，持有一个Command对象，通过command完成业务逻辑 HystrixCommand：服务返回单个操作结果 HystrixObservableCommand 服务返回多个操作结果 2. 执行命令（有四种方式）

• execute 同步执行
• queue 异步执行
• observer 返回Hot Observable（不管是否有订阅者，直接发布）
• toObservable() 返回Cold Observable（等到有订阅者才发布事件）

3. 结果是否被缓存，如果命中，以Observable对象形式返回。 4. 断路器是否打开（缓存没有命中，执行【4】）

• 断路器打开：Hystrix不会执行命令，跳转到fallback处理（【8】）
• 断路器关闭：检查是否有可用资源执行命令（【5】）

5. 线程池/请求队列/信号量是否占满

• 占满：跳转到fallback处理逻辑【8】
  ⚠️：这里的线程池是每个依赖服务隔离的专有线程池，不是容器的线程池。

6. 请求依赖服务construct()或run()

• HystrixCommand.run():返回单一结果，或者抛出异常
• HystrixObservableCommand.construct()：返回一个Observable对象发射多个结果，或者发送错误通知onError
• run（）或者construct（）超时，转到【8】

7. 计算断路器健康度

• 断路器统计信息，根据“成功”、“失败”、“拒绝”、“超时”等信息，断路器会决定是否对某个依赖服务打开断路器进行熔断，直到恢复期结束。等到恢复期结束，再次判断是否到达健康指标，否则再次熔断。

8. fallback处理逻辑（也称为服务降级） 引起fallback的情况

• 【4】命令处于熔断状态，断路器打开
• 【5】当前命令的线程池、请求队列、信号量被占满
• 【6】construct()或run()抛出异常的时候

9. 返回成功的响应

• 成功执行Hystrix命令后，处理结果直接返回或者返回Observable对象

依赖隔离 舱壁模式（Docker）

• Docker用于实现进程的隔离，Hystrix用于实现依赖服务的线程池隔离

三、使用详解 创建请求命令 1. extends HystrixCommand/HystrixObservableCommand 2. @HystrixCommand 定义服务降级

• extends方法：重写getFallback方法
• @HystrixCommand方法：添加fallbackMethod参数

异常处理

• ignoreExceptions参数：忽略制定的异常，不会出发fallback逻辑
• 在fallback方法参数中加入Throwable e，可以在fallback中实现获取抛出的异常内容。

命令名称、分组、线程池划分 请求缓存 请求合并 属性详解