关于hystrix:hystrix学习

一，hystrix 整体流程

1. 结构一个 HystrixCommand 或 HystrixObservableCommand 对象，用于封装申请，并在构造方法配置申请被执行须要的参数；
2. 执行命令，Hystrix 提供了 4 种执行命令的办法
3. 判断是否应用缓存响应申请，若启用了缓存，且缓存可用，间接应用缓存响应申请。Hystrix 反对申请缓存，但须要用户自定义启动；
4. 判断熔断器是否关上，如果关上，执行第 8 步；
5. 判断线程池 / 队列 / 信号量是否已满，已满则执行第 8 步；
6. 执行 HystrixObservableCommand.construct()或 HystrixCommand.run()，如果执行失败或者超时，执行第 8 步；否则，跳到第 9 步；
7. 统计熔断器监控指标；
8. 走 Fallback 备用逻辑
9. 返回申请响应

留神：第 5 步线程池 / 队列 / 信号量已满时，还会执行第 7 步逻辑，更新熔断器统计信息，而第 6 步无论胜利与否，都会更新熔断器统计信息。

hystrxi 设计理念

• 应用命令模式将所有对外部服务（或依赖关系）的调用包装在 HystrixCommand 或 HystrixObservableCommand 对象中，并将该对象放在独自的线程中执行；
• 每个依赖都保护着一个线程池（或信号量），线程池被耗尽则拒绝请求（而不是让申请排队）。
• 记录申请胜利，失败，超时和线程回绝。
• 服务谬误百分比超过了阈值，熔断器开关主动关上，一段时间内进行对该服务的所有申请。
• 申请失败，被回绝，超时或熔断时执行降级逻辑。
• 近实时地监控指标和配置的批改。

二，hystrix 容错

一，资源隔离

资源隔离次要指对线程的隔离。Hystrix 提供了两种线程隔离形式：线程池和信号量 ，默认为线程池。
应用线程池时，发送申请的线程和执行依赖服务的线程不是同一个；而应用信号量时，发送申请的线程和执行依赖服务的线程是同一个，都是发动申请的线程。

线程池和信号量都反对熔断和限流。
相比线程池，信号量不须要线程切换，如果是 tomcat 服务，那信号量应用的就是 tomcat 的线程而线程池则是 tomcat 线程创立的线程池，因而防止了不必要的开销。
然而信号量不反对异步，也不反对超时，也就是说当所申请的服务不可用时，信号量会管制超过限度的申请立刻返回，然而曾经持有信号量的线程只能期待服务响应或从超时中返回，即可能呈现长时间期待。线程池模式下，当超过指定工夫未响应的服务，Hystrix 会通过响应中断的形式告诉线程立刻完结并返回。

基于下面两者的特点，咱们能够晓得它们别离实用的场景：

• 信号量 申请并发大且耗时短(本服务的内存操作等)；不会拜访依赖内部的服务，因为信号量是不反对超时的，它解决不了 timeout 的问题
• 线程池 申请并发大且耗时长；因为线程池是反对超时的，所以拜访的服务是否依赖内部都行；如果利用恰好适宜异步执行那线程池会是一个不错的抉择。当然线程池也是须要保护的所以线程上下文切换也会有开销

二，熔断

熔断器里 6 个重要的参数：

1. circuitBreaker.enabled
   是否启用熔断器，默认是 TRUE。
2. circuitBreaker.forceOpen
   熔断器强制关上，始终保持关上状态，不关注熔断开关的理论状态。默认值 FLASE。
3. circuitBreaker.forceClosed
   熔断器强制敞开，始终保持敞开状态，不关注熔断开关的理论状态。默认值 FLASE。
4. circuitBreaker.errorThresholdPercentage
   错误率，默认值 50%，例如一段时间（10s）内有 100 个申请，其中有 54 个超时或者异样，那么这段时间内的错误率是 54%，大于了默认值 50%，这种状况下会触发熔断器关上。
5. circuitBreaker.requestVolumeThreshold
   默认值 20。含意是一段时间内至多有 20 个申请才进行 errorThresholdPercentage 计算。比方一段时间了有 19 个申请，且这些申请全副失败了，错误率是 100%，但熔断器不会关上，总申请数不满足 20。
6. circuitBreaker.sleepWindowInMilliseconds
   半开状态试探睡眠工夫，默认值 5000ms。如：当熔断器开启 5000ms 之后，会尝试放过来一部分流量进行试探，确定依赖服务是否复原。

断路开启，也就是由 close 转换到 open 状态（close -> open）。那么之后在 SleepWindowInMilliseconds 工夫内(默认值 5000ms)，所有通过该断路器的申请全副都会被断路，不调用后端服务，间接走 fallback 降级机制。

而在该参数工夫过后，断路器会变为 half-open 半开闭状态，尝试让一条申请通过断路器，看能不能失常调用。如果调用胜利了，那么就主动复原，断路器转为 close 状态。

三，降级

降级，通常指务高峰期，为了保障外围服务失常运行，须要停掉一些不太重要的业务，或者某些服务不可用时，执行备用逻辑从故障服务中疾速失败或疾速返回，以保障主体业务不受影响。Hystrix 提供的降级次要是为了容错，保障以后服务不受依赖服务故障的影响，从而进步服务的健壮性。要反对回退或降级解决，能够重写 HystrixCommand 的 getFallBack 办法或 HystrixObservableCommand 的 resumeWithFallback 办法。

Hystrix 在以下几种状况下会走降级逻辑：

• 执行 construct()或 run()抛出异样
• 熔断器关上导致命令短路
• 命令的线程池和队列或信号量的容量超额，命令被回绝
• 命令执行超时

降级回退形式有多种，这里列举两种：

• 疾速失败，疾速失败是最一般的命令执行办法，命令没有重写降级逻辑。如果命令执行产生任何类型的故障，它将间接抛出异样。
• 无声失败，指在降级办法中通过返回 null，空 Map，空 List 或其余相似的响应来实现。

咱们能够依据本人的业务须要开发降级计划，然而须要留神降落级逻辑是否会出异样的可能。

参考的文章：
深刻 Hystrix 断路器执行原理
深刻 Hystrix 线程池隔离与接口限流
Hystrix 原理与实战