|
|
## SpringCloud Netflix Hystrix
|
|
|
|
|
|
|
|
|
### SpringCloud Netflix Hystrix 概览
|
|
|
- Hystrix 是什么、设计目标是什么
|
|
|
- Hystrix 是一个库，通过添加延迟容忍和容错逻辑，帮助你控制这些分布式服务之间的交互
|
|
|
- Hystrix 通过隔离服务之间的访问点、停止级联失败和提供回退选项来实现服务之间的容错
|
|
|
- Hystrix 有四大设计目标
|
|
|
- 对客户端访问的延迟和故障进行保护和控制
|
|
|
- 在复杂的分布式系统中阻止级联故障
|
|
|
- 快速失败，快速恢复
|
|
|
- 兜底回退，尽可能优雅的降级
|
|
|
---
|
|
|
- Hystrix 解决了什么问题
|
|
|
- 复杂分布式系统中服务之间存在许多依赖项，依赖项可能会存在故障，如果不做故障隔离整个服务可能会被拖垮
|
|
|
---
|
|
|
- Hystrix 是如何实现它的目标的
|
|
|
- 对依赖项(服务)进行包装代理，不直接与依赖项交互
|
|
|
- 调用超时时间允许自行设定，超时之后立刻熔断报错
|
|
|
- 每一个依赖项都在自己的空间内(线程池或信号量隔离)，依赖项之间不存在干扰
|
|
|
- 请求依赖项失败后，可以选择出错或者是兜底回退
|
|
|
|
|
|
### 使用注解方式实现服务的容错、降级
|
|
|
---
|
|
|
- SpringCloud Netflix Hystrix 的三种模式
|
|
|
- Hystrix 的断路器模式和后备策略模式
|
|
|
- 断路器模式:设置超时或者失败等熔断策略
|
|
|
- 后备策略模式:断路器模式触发之后，如果存在后备策略，则执行后备
|
|
|
- Hystrix 的舱壁模式：Hystrix 舱壁模式的启发:货船为了进行防止漏水和火灾的扩散，会将货仓分隔为多个当发生灾害时，将所在货仓进行隔离就可以降低整艘船的风险
|
|
|
- 舱壁模式功能就是:我们可以通过为各个服务分别指定线程池
|
|
|
- 每一个远程资源调用都被放置在自己的线程池中，每一个线程池只有一定数量的线程来处理远程调用
|
|
|
- 一个性能低下的服务，只会影响到同一个线程池中的其他服务调用。所以降低了会产生的负面影响
|
|
|
|
|
|
### 使用编程方式实现服务的容错、降级
|
|
|
- [NacosClientHystrixCommand.java] - [NacosClientHystrixObservableCommand.java]
|
|
|
|
|
|
### 编程方式开启 Hystrix 请求缓存
|
|
|
- Hystrix 的结果缓存指的是在一次 Hystrix 的请求上下文中
|
|
|
- Hystrix 请求缓存的两种实现方式
|
|
|
- 编程(继承 HystrixCommand)方式，重写 getCacheKey 方法即可
|
|
|
- 注解方式
|
|
|
- @CacheResult：该注解用来标记请求命令返回的结果应该被缓存，它必须与@HystrixCommand注解结合使用, 属性: cacheKeyMethod
|
|
|
- @CacheRemove: 该注解用来让请求命令的缓存失效，失效的缓存根据commandKey进行查找。属性: commandKey,cacheKeyMethod
|
|
|
- @CacheKey: 该注解用来在请求命令的参数上标记，使其作为cacheKey，如果没有使用此注解则会使用所有参数列表中的参数作为cacheKey, 属性: value
|
|
|
|
|
|
### 注解方式开启 Hystrix 请求缓存
|
|
|
-
|
|
|
### 编程方式应用 Hystrix 请求合并
|
|
|
- 默认情况下，每一个请求都会占用一个线程和一次网络请求，高并发场景下效率不高\
|
|
|
- 使用 Hystrix 的请求合并，将多个请求 merge 为一个，提高服务的并发能力
|
|
|
---
|
|
|
- 请求合并的适用场景与注意事项
|
|
|
- 适用场景:单个对象的查询并发数很高，服务提供方负载较高，就可以考虑使用请求合并
|
|
|
- 注意事项
|
|
|
- 请求在代码中人为的设置了延迟时间，会降低请求的响应速度
|
|
|
- 可能会提高服务提供方的负载，因为返回 List 结果数据量偏大
|
|
|
- 实现请求合并比较复杂
|
|
|
### 注解方式应用 Hystrix 请求合并
|
|
|
- 使用注解的方式比较多
|
|
|
### OpenFeign 集成 Hystrix 开启后备模式
|
|
|
- OpenFeign 集成 Hystrix 的步骤
|
|
|
- 在配置文件中开启 Hystrix 的熔断功能:feign.hystrix.enabled: true
|
|
|
- @FeignClient 注解的 fallback 和 fallbackFactory 属性
|
|
|
- fallback 和 fallbackFactory 都是用于配置响应回退，但是不可以同时使用
|
|
|
- fallbackFactory 能够获取到 OpenFeign 调用抛出的异常
|
|
|
### 使用 Hystrix 监控面板监测客户端容错
|
|
|
- Hystrix Dashboard 是一个单独的应用，用来实时的对 Hystrix 的『使用情况』进行实时的监控
|
|
|
### SpringCloud Netflix Hystrix 容错组件总结
|
|
|
- 
|
|
|
---
|
|
|
- Hystrix 完整的工作流程
|
|
|
- 构造-个 HystrixCommand 或者 HystrixObservableCommand 对象
|
|
|
- 表示对一个对依赖项请求的包装
|
|
|
- 执行命令获取响应
|
|
|
- execute():阻塞，直到收到响应或者抛出异常, 同步执行的, 调用的是 queue().get()
|
|
|
- queue():返回一个 Future, 异步执行的, 调用的是 observable.toBlocking().toFuture()
|
|
|
- observe():订阅代表响应的 Observable
|
|
|
- toObservable():返回一个 Observable,当你订阅它以后，将会执行Hystrix 命令并且推送它的响应
|
|
|
- 总结: 最终每一个 HystrixCommand, 都是 Observable 的实现
|
|
|
- 响应是否已经被缓存
|
|
|
- 如果请求在缓存中的结果是存在的, 该请求在缓存中对应的结果是可用的, 缓存就会立即以一个 Observable 的形式被返回
|
|
|
- 断路器是否打开
|
|
|
- 缓存不存在的时候, 当你执行命令的时候, Hystrix 检查断路器是否打开, 如果打开, 不会执行任何命令, 执行回退逻辑, 如果是关闭, 检查容量是否可用
|
|
|
- 线程池、信号量是否已经使用率 100%
|
|
|
- 判断, 线程池和信号量是否已经满了, 如果满了, 不会执行命令, 立马执行回退逻辑
|
|
|
- HystrixObservableCommand.construct() or HystrixCommand.run()
|
|
|
- 对依赖项的调用请求, 真正的逻辑编写在这里, run 会返回一个响应, 或者抛出一个异常, construct 会返回一个 Observable 对象, 会推送一个响应或者一个 ERROR 通知, 会抛出一个 Timeout 异常
|
|
|
- 计算电路健康
|
|
|
- Hystrix 报告成功, 失败, 拒绝, 超时给断路器, 断路器会维护一组计算统计的计数器, 断路器会用这些统计数据来决定, 什么时候要跳闸, 后续的所有请求都会被短路, 直到一个恢复周期耗尽以后, 在第一次检查健康检查之后, 才会重新打开电路
|
|
|
- 回退或返回成功响应
|
|
|
- 一, 当你失败以后, HystrixCommand 会回退一个单一的回退值, HystrixObservableCommand 会返回一个或者多个回退值, 通过 fallback, 当 fallback 有异常也会被进一步抛出, 给调用者发送 ERROR 通知, 命令调用者进行处理
|
|
|
- 二, 成功会直接抛出响应给调用者, 返回一个 Observable |
