微服务容灾组件：Hystrix 的实现思路

在分布式系统下，微服务之间不可避免地会发生相互调用，但是没有一个系统能够保证自身运行的绝对正确性，微服务在调用过程中，很可能会面临被依赖服务失效的问题，这些问题的发生有诸多情况，有可能是因为微服务之间的网络通信出现较大的延迟、又或者是被依赖的微服务抛出了调用异常、还有可能是因为被依赖的微服务负载过大无法及时响应请求等等原因。本系列文章将会介绍 Hystrix 的相关使用与原理。

结合我们的一系列介绍，我们可以简单理解一下 Hystrix 的实现思路：

• 它将所有的远程调用的逻辑封装到HystrixCommand或者HystrixObservableCommand对象中，这些远程调用将会在独立的线程中执行(资源隔离)，这里使用了设计模式中的命令模式；
• Hystrix对访问耗时超过设置的阀值的请求采用自动超时的策略。该策略对所有的Command都有效(如果资源隔离的方式为信号量，该特性将失效)，超时的阀值可以通过Command配置进行自定义；
• 为每一个服务提供者维护一个线程池(或者信号量)，当线程池被占满时，对于该服务提供者的请求将会直接被拒绝(快速失败)而不是排队等待，减少系统的资源等待；
• 请求服务提供者划分出成功、失效、超时、线程池被占满等四种可能出现的情况；
• 断路器机制将在请求服务提供者失败次数超过一定阀值后手动或者自动的切断服务一段时间；
• 当请求服务提供者出现服务拒绝、超时、短路(多个服务提供者依次顺序请求，前面的服务提供者请求失败，后面的请求将不会发出)等情况时，执行其fallback方法，服务降级；
• 提供接近实时的监控和配置变更服务。

使用Hystrix来包装远程调用后发生调用流程如下图所示：

简单的流程执行如下：

1. 构建HystrixCommand或者HystrixObservableCommand对象；
2. 执行命令；
3. 是否有Response缓存；
4. 是否断路器打开；
5. 是否线程池或者队列或者信号量被消耗完；
6. HystrixObservableCommand.construct() or HystrixCommand.run()；
7. 计算链路的健康情况；
8. 获取fallback逻辑；
9. 返回成功的Response；

下面的文章，我们通过源码来逐步理解这些过程。