分布式系统延迟和容错框架Hystrix

矫情吗；* 2022-06-02 00:56 136阅读 0赞

**简介**

在大中型分布式[系统][Link 1]中，通常系统很多依赖(HTTP，Hession，Netty，Dubbo等)，在高并发访问下，这些依赖的稳定性与否对系统的影响非常大，但是依赖有很多不可控问题：

如网络连接缓慢，资源繁忙，暂时不可用，服务脱机等。

在正常情况下：

当依赖服务 I 繁忙，其他依赖正常时：

当依赖 I 阻塞时，大多数服务器的 线程 池就出现阻塞(BLOCK)，影响整个线上服务的稳定性：

在复杂的分布式 架构 的应用程序有很多的依赖，都会不可避免地在某些时候失败。高并发的依赖失败时如果没有隔离措施，当前应用服务就有被拖垮的风险。

Hystrix，旨在通过控制那些访问远程系统、服务和第三方库的节点，从而对延迟和故障提供更强大的容错能力。

Hystrix源于Netflix API团队在2011年启动的弹性工程工作，而目前它在Netflix每天处理着数百亿的隔离线程以及数千亿的隔离信号调用。Hystrix是基于Apache License 2.0协议的开源的程序库，目前托管在GitHub上。

Hystrix能够做什么

1)Hystrix使用命令模式HystrixCommand(Command)包装依赖调用逻辑，每个命令在单独线程中/信号 授权 下执行，每个command只能执行一次。

2)提供熔断器[组件][Link 2],可以自动运行或手动调用,停止当前依赖一段时间(10秒)，熔断器默认 错误 率阈值为50%,超过将自动运行。

3)可配置依赖调用 超时 时间,超时时间一般设为比99.5%平均时间略高即可.当调用超时时，直接返回或执行fallback逻辑。

4)为每个依赖提供一个小的线程池(或信号)，如果线程池已满调用将被立即拒绝，默认不采用排队.加速失败判定时间。

5)依赖调用结果分:成功，失败(抛出 异常 )，超时，线程拒绝，短路。 请求失败(异常，拒绝，超时，短路)时执行fallback(降级)逻辑。

隔离策略

1、线程隔离

把执行依赖代码的线程与请求线程(如:jetty线程)分离，请求线程可以自由控制离开的时间(异步过程)。通过线程池大小可以控制并发量，当线程池饱和时可以提前拒绝服务,防止依赖问题扩散。

线上建议线程池不要设置过大，否则大量堵塞线程有可能会拖慢服务器。

优点：

\[1\]：使用线程可以完全隔离第三方代码,请求线程可以快速放回。

\[2\]：当一个失败的依赖再次变成可用时，线程池将清理，并立即恢复可用，而不是一个长时间的恢复。

\[3\]：可以完全模拟异步调用，方便异步[编程][Link 3]。

缺点：

\[1\]：线程池的主要缺点是它增加了CPU调度和上下文切换。

\[2\]：对使用ThreadLocal等依赖线程状态的代码增加复杂性，需要手动传递和清理线程状态。

Note： Netflix公司内部认为线程隔离开销足够小，不会造成重大的成本或性能的影响。Netflix 内部API 每天100亿的HystrixCommand依赖请求使用线程隔，每个应用大约40多个线程池，每个线程池大约5-20个线程。

2、信号量隔离

信号隔离也可以用于限制并发访问，防止阻塞扩散， 与线程隔离最大不同在于执行依赖代码的线程依然是请求线程(该线程需要通过信号申请)，如果客户端是可信的且可以快速返回，可以使用信号隔离替换线程隔离，降低开销。

信号量的大小可以动态调整, 线程池大小不可以。

优点：

\[1\]：使用信号量没有额外的CPU线程上下文切换开销，比线程隔离开销要小得多。

\[2\]：可以对请求限流。

缺点：

\[1\]：不能对依赖的请求调用进行熔断。

3、如何选择

默认并且推荐的隔离方式是线程隔离，通过单独线程执行的命令可以提供一层网络超时提供不了的额外的保护。只有当请求调用量很大导致使用线程隔离开销太大时才使用信号量隔离(一般是非网络请求调用)。

使用Fallback提供降级策略

当执行HystrixCommand的run方法时，如果发生任何错误抛出异常时：

不提供Fallback：HystrixRuntimeException: \* failed and no fallback available.。

提供Fallback ：直接走Fallback逻辑。

Note：Fallback逻辑中最好不要有能导致异常或错误的逻辑，尽量提供静态返回内容。

熔断器

1、熔断请求判断机制

使用无锁循环队列计数，每个熔断器默认维护10个bucket，每1秒一个bucket，每个blucket记录请求的成功、失败、超时、拒绝的状态，默认错误超过50%且10秒内超过20个请求进行中断拦截。

2、熔断恢复

对于被熔断的请求，每隔5s允许一个请求通过，若请求都是健康的，则对请求健康恢复。

3、熔断器的三种状态

OPEN、HALF-OPEN、CLOSED

The precise way that the circuit opening and closing occurs is as follows:

Assuming the volume across a circuit meets a certain threshold (HystrixCommandProperties.circuitBreakerRequestVolumeThreshold())...

And assuming that the error percentage exceeds the threshold error percentage (HystrixCommandProperties.circuitBreakerErrorThresholdPercentage())...

Then the circuit-breaker transitions from CLOSED to OPEN.

While it is open, it short-circuits all requests made against that circuit-breaker.

After some amount of time (HystrixCommandProperties.circuitBreakerSleepWindowInMilliseconds()), the next single request is let through (this is the HALF-OPEN state). If the request fails, the circuit-breaker returns to the OPEN state for the duration of the sleep window. If the request succeeds, the circuit-breaker transitions to CLOSED and the logic in 1. takes over again.

4、熔断器作用范围

以commandKey来区分，需要控制粒度。

配置

1、统计滚动的时间窗口 default 10000 ten seconds

withMetricsRollingStatisticalWindowInMilliseconds(10000)

2、滚动时间窗口 bucket 数量 default

withMetricsRollingStatisticalWindowBuckets(10)

3、采样时间间隔 default 500

withMetricsHealthSnapshotIntervalInMilliseconds(1)

4、熔断器在整个统计时间内是否开启的阀值，默认20。也就是10秒钟内至少请求20次，熔断器才发挥起作用

withCircuitBreakerRequestVolumeThreshold(20)

5、默认:50。当出错率超过50%后熔断器启动.