使用Hystrix提高系统可用性(转)

转载自：http://www.cnblogs.com/shanyou/p/4752226.html

今天稍微复杂点的互联网应用，服务端基本都是分布式的，大量的服务支撑起整个系统，服务之间也难免有大量的依赖关系，依赖都是通过网络连接起来。

（图片来源：https://github.com/Netflix/Hystrix/wiki）

然而任何一个服务的可用性都不是 100% 的，网络亦是脆弱的。当我依赖的某个服务不可用的时候，我自身是否会被拖死？当网络不稳定的时候，我自身是否会被拖死？这些在单机环境下不太需要考虑的问题，在分布式环境下就不得不考虑了。假设我有5个依赖的服务，他们的可用性都是99.95%，即一年不可用时间约为4个多小时，那么是否意味着我的可用性最多就是 99.95% 的5次方，99.75%（近乎一天），再加上网络不稳定因素、依赖服务可能更多，可用性会更低。考虑到所依赖的服务必定会在某些时间不可用，考虑到网络必定会不稳定，我们应该怎么设计自身服务？即，怎么为出错设计？

Michael T. Nygard 在在精彩的《Release It!》一书中总结了很多提高系统可用性的模式，其中非常重要的两条是：

1. 使用超时
2. 使用断路器

第一条，通过网络调用外部依赖服务的时候，都必须应该设置超时。在健康的情况下，一般局域往的一次远程调用在几十毫秒内就返回了，但是当网络拥堵的时候，或者所依赖服务不可用的时候，这个时间可能是好多秒，或者压根就僵死了。通常情况下，一次远程调用对应了一个线程或者进程，如果响应太慢，或者僵死了，那一个进程/线程，就被拖死，短时间内得不到释放，而进程/线程都对应了系统资源，这就等于说我自身服务资源会被耗尽，导致自身服务不可用。假设我的服务依赖于很多服务，其中一个非核心的依赖如果不可用，而且没有超时机制，那么这个非核心依赖就能拖死我的服务，尽管理论上即使没有它我在大部分情况还能健康运转的。

断路器其实我们大家都不陌生（你会换保险丝么？），如果你家没有断路器，当电流过载，或者短路的时候，电路不断开，电线就会升温，造成火灾，烧掉房子。有了断路器之后，电流过载的时候，保险丝就会首先烧掉，断开电路，不至于引起更大的灾难（只不过这个时候你得换保险丝）。

当我们的服务访问某项依赖有大量超时的时候，再让新的请求去访问已经没有太大意义，那只会无谓的消耗现有资源。即使你已经设置超时1秒了，那明知依赖不可用的情况下再让更多的请求，比如100个，去访问这个依赖，也会导致100个线程1秒的资源浪费。这个时候，断路器就能帮助我们避免这种资源浪费，在自身服务和依赖之间放一个断路器，实时统计访问的状态，当访问超时或者失败达到某个阈值的时候（如50%请求超时，或者连续20次请失败），就打开断路器，那么后续的请求就直接返回失败，不至于浪费资源。断路器再根据一个时间间隔（如5分钟）尝试关闭断路器（或者更换保险丝），看依赖是否恢复服务了。

超时机制和断路器能够很好的保护我们的服务，不受依赖服务不可用的影响太大，具体可以参看文章《 使用熔断器设计模式保护软件》。然而具体实现这两个模式还是有一定的复杂度的，所幸 Netflix 开源的 Hystrix框架 帮我们大大简化了超时机制和断路器的实现，Hystrix：供分布式系统使用，提供延迟和容错功能，隔离远程系统、访问和第三方程序库的访问点，防止级联失败，保证复杂的分布系统在面临不可避免的失败时，仍能有其弹性。