简介

在分布式环境下，服务之间有大量的依赖，单个依赖故障时的容灾是个很重要的话题。

相似的话题包括：SOA柔性架构、分布式系统高可用、高可用系统故障处理。

个人理解主要解决三个方面的问题：

这里介绍下Hystrix，以介绍一些主要的思想、核心的设计思路为主，具体的使用请阅读文档5遍，深入的也可以分析代码。

几个公式

99.99^30 = 99.7% uptime

如果一个服务依赖30个子服务，子服务都是4个9的可用性，那么该服务可用性为2个9.

0.3% of 1 billion requests = 3,000,000 failures

从请求数量上讲，一亿次请求中如果有0.3%的失败，失败次数是300万。

2+ hours downtime/month even if all dependencies have excellent uptime.

从时间上讲，上述服务相当于每个月有2个小时的不可用时间。

构建HystrixCommand 或者HystrixObservableCommand 对象。前者是用来处理依赖返回单个结果的情况，后者是用来返回Observable 。
执行处理动作。主要有四种方式：execute()是阻塞的方式返回单个依赖处理的结果；queue()，返回依赖调用结果的Future对象；observe()和observe()返回多个（或者一个）响应结果的Observable。本质上所有请求都是Observable的实现，只不过execute是queue().get()，而queue()是toObservable().toBlocking().toFuture()。
判断请求是否缓存。如果请求缓存开启，命中请求缓存的会直接返回Observable 中的数据。
判断是否熔断。每个请求执行时，会判断熔断是否生效，如果熔断失效，则直接走到第8步，返回fallback，否则执行第5步。
判断是否资源（线程池、队列、信号量）满了。如果资源已经占满，则不会执行请求，直接走到第8步的fallback。
请求执行。执行真正封装的外部依赖指令，发生超时会执行fallback；如果未发生异常并成功返回结果，则进行相应日志和上报。
熔断计算。Hystrix维护的熔断计数器进行统计和更新。如果满足熔断条件会进行熔断一段时间，并进行健康检查。
执行fallback。综上所述，执行短路的条件包括：运行时异常、熔断开启和线程池资源被占满。
返回成功结果。基于不同的调用方式，返回结果。

如何部署Hystrix到生成环境并调优：

Hystrix配置

如上图所示：

假设应用平均响应时间40ms，99%响应时间200ms，99.5%响应时间300ms。峰值QPS 30。

线程池数量 = 最大QPS x 99响应时间 + 一定余量。这里是30*0.2 + 余量4 = 10。
线程池Queue大小：5-10
连接超时100ms，读超时250ms，重试一次。该设置远高于平均响应时间，但仍然丢掉了1%的网络抖动问题。给了一次平均响应时间去另外的机器重试。（前提要求是99.5%以上响应时间的请求没有逻辑上的原因）。
线程超时时间 = 客户端超时时间 + 一次重试的平均响应时间。这里是250 + 40 约等 300。如果网络调用超过了350ms，加上重试的一次共700ms，则会导致线程池占满、开始拒绝请求。