使用Hystrix提高系统可用性
今天稍微复杂点的互联网应用，服务端基本都是分布式的，大量的服务支撑起整个系统，服务之间也难免有大量的依赖关系，依赖都是通过网络连接起来。
（图片来源：https://github.com/Netflix/Hystrix/wiki）
然而任何一个服务的可用性都不是 100% 的，网络亦是脆弱的。当我依赖的某个服务不可用的时候，我自身是否会被拖死？当网络不稳定的时候，我自身是否会被拖死？这些在单机环境下不太需要考虑的问 题，在分布式环境下就不得不考虑了。假设我有5个依赖的服务，他们的可用性都是99.95%，即一年不可用时间约为4个多小时，那么是否意味着我的可用性 最多就是 99.95% 的5次方，99.75%（近乎一天），再加上网络不稳定因素、依赖服务可能更多，可用性会更低。考虑到所依赖的服务必定会在某些时间不可用，考虑到网络必 定会不稳定，我们应该怎么设计自身服务？即，怎么为出错设计？
Michael T. Nygard 在在精彩的 《Release It!》 一书中总结了很多提高系统可用性的模式，其中非常重要的两条是：
- 使用超时
- 使用断路器
第一条，通过网络调用外部依赖服务的时候，都必须应该设置超时。在健康的情况下，一般局域往的一次远程调用在几十毫秒内就返回了，但是当网络拥堵 的时候，或者所依赖服务不可用的时候，这个时间可能是好多秒，或者压根就僵死了。通常情况下，一次远程调用对应了一个线程或者进程，如果响应太慢，或者僵 死了，那一个进程/线程，就被拖死，短时间内得不到释放，而进程/线程都对应了系统资源，这就等于说我自身服务资源会被耗尽，导致自身服务不可用。假设我 的服务依赖于很多服务，其中一个非核心的依赖如果不可用，而且没有超时机制，那么这个非核心依赖就能拖死我的服务，尽管理论上即使没有它我在大部分情况还 能健康运转的。
断路器其实我们大家都不陌生（你会换保险丝么？），如果你家没有断路器，当电流过载，或者短路的时候，电路不断开，电线就会升温，造成火灾，烧掉房子。有了断路器之后，电流过载的时候，保险丝就会首先烧掉，断开电路，不至于引起更大的灾难（只不过这个时候你得换保险丝）。
当我们的服务访问某项依赖有大量超时的时候，再让新的请求去访问已经没有太大意义，那只会无谓的消耗现有资源。即使你已经设置超时1秒了，那明知 依赖不可用的情况下再让更多的请求，比如100个，去访问这个依赖，也会导致100个线程1秒的资源浪费。这个时候，断路器就能帮助我们避免这种资源浪 费，在自身服务和依赖之间放一个断路器，实时统计访问的状态，当访问超时或者失败达到某个阈值的时候（如50%请求超时，或者连续20次请失败），就打开 断路器，那么后续的请求就直接返回失败，不至于浪费资源。断路器再根据一个时间间隔（如5分钟）尝试关闭断路器（或者更换保险丝），看依赖是否恢复服务 了。
超时机制和断路器能够很好的保护我们的服务，不受依赖服务不可用的影响太大，具体可以参看文章《 使用熔断器设计模式保护软件 》 。然而具体实现这两个模式还是有一定的复杂度的，所幸 Netflix 开源的 Hystrix框架 帮我们大大简化了超时机制和断路器的实现 ， Hystrix ：供分布式系统使用，提供延迟和容错功能，隔离远程系统、访问和第三方程序库的访问点，防止级联失败，保证复杂的分布系统在面临不可避免的失败时，仍能有其弹性。 在Codeplex上有一个.NET的移植版本 https://hystrixnet.codeplex.com/ 。
使用Hystrix，需要通过Command封装对远程依赖的调用：
public class GetCurrentTimeCommand : HystrixCommand < long >
{
private static long currentTimeCache;
public GetCurrentTimeCommand()
: base ( HystrixCommandSetter .WithGroupKey( "TimeGroup" )
.AndCommandKey( "GetCurrentTime" )
.AndCommandPropertiesDefaults( new HystrixCommandPropertiesSetter ().WithExecutionIsolationThreadTimeout( TimeSpan .FromSeconds(1.0)).WithExecutionIsolationThreadInterruptOnTimeout( true )))
{
}
protected override long Run()
{
using ( WebClient wc = new WebClient ())
{
string content = wc.DownloadString( "http://tycho.usno.navy.mil/cgi-bin/time.pl" );
XDocument document = XDocument .Parse(content);
currentTimeCache = long .Parse(document.Element( "usno" ).Element( "t" ).Value);
return currentTimeCache;
}
}
protected override long GetFallback()
{
return currentTimeCache;
}
}
然后在需要的时候调用这个 Command ：
GetCurrentTimeCommand command = new GetCurrentTimeCommand ();
long currentTime = command.Execute();
上述是同步调用，当然如果业务逻辑允许且更追求性能，或许可以选择异步调用：
该例中，不论 WebClient . DownloadString () 自身有没有超时机制（可能你会发现很多远程调用接口自身并没有给你提供超时机制），用 HystrixCommand 封装过后，超时是强制的，默认超时时间是1秒，当然你可以根据需要自己在构造函数中调节 Command 的超时时间，例如说2秒：
HystrixCommandSetter.WithGroupKey("TimeGroup")
.AndCommandKey("GetCurrentTime")
.AndCommandPropertiesDefaults(new HystrixCommandPropertiesSetter().WithExecutionIsolationThreadTimeout(TimeSpan.FromSeconds(2.0)).WithExecutionIsolationThreadInterruptOnTimeout(true))
当Hystrix执行命令超时后，Hystrix 执行命令超时或者失败之后，是会尝试去调用一个 fallback 的，这个 fallback 即一个备用方案，要为 HystrixCommand 提供 fallback，只要重写 protected virtual R GetFallback()方法即可。
一般情况下，Hystrix 会为 Command 分配专门的线程池，池中的线程数量是固定的，这也是一个保护机制，假设你依赖很多个服务，你不希望对其中一个服务的调用消耗过多的线程以致于其他服务都没 线程调用了。默认这个线程池的大小是10，即并发执行的命令最多只能有是个了，超过这个数量的调用就得排队，如果队伍太长了（默认超过 5），Hystrix就立刻走 fallback 或者抛异常。
根据你的具体需要，你可能会想要调整某个Command的线程池大小，例如你对某个依赖的调用平均响应时间为200ms，而峰值的QPS是200，那么这个并发至少就是 0.2 x 200 = 40 ( Little's Law )，考虑到一定的宽松度，这个线程池的大小设置为60可能比较合适：
public GetCurrentTimeCommand()
: base(HystrixCommandSetter.WithGroupKey("TimeGroup")
.AndCommandKey("GetCurrentTime")
.AndCommandPropertiesDefaults(new HystrixCommandPropertiesSetter().WithExecutionIsolationThreadTimeout(TimeSpan.FromSeconds(1.0)).WithExecutionIsolationThreadInterruptOnTimeout(true))
.AndThreadPoolPropertiesDefaults(new HystrixThreadPoolPropertiesSetter().WithCoreSize(60) // size of thread pool
.WithKeepAliveTime(TimeSpan.FromMinutes(1.0)) // minutes to keep a thread alive (though in practice this doesn't get used as by default we set a fixed size)
.WithMaxQueueSize(100) // size of queue (but we never allow it to grow this big ... this can't be dynamically changed so we use 'queueSizeRejectionThreshold' to artificially limit and reject)
.WithQueueSizeRejectionThreshold(10) // number of items in queue at which point we reject (this can be dyamically changed)
.WithMetricsRollingStatisticalWindow(10000) // milliseconds for rolling number
.WithMetricsRollingStatisticalWindowBuckets(10)))
{
}
说了这么多，还没提到Hystrix的断路器，其实对于使用者来说，断路器机制默认是启用的，但是编程接口默认几乎不需要关心这个，机制和前面讲 的也差不多，Hystrix会统计命令调用，看其中失败的比例，默认当超过50%失败后，开启断路器，那之后一段时间的命令调用直接返回失败（或者走 fallback），5秒之后，Hystrix再尝试关闭断路器，看看请求是否能正常响应。下面的几行Hystrix源码展示了它如何统计失败率的：
public HealthCounts GetHealthCounts()
{
// we put an interval between snapshots so high-volume commands don't
// spend too much unnecessary time calculating metrics in very small time periods
long lastTime = this.lastHealthCountsSnapshot;
long currentTime = ActualTime.CurrentTimeInMillis;
if (currentTime - lastTime >= this.properties.MetricsHealthSnapshotInterval.Get().TotalMilliseconds || this.healthCountsSnapshot == null)
{
if (Interlocked.CompareExchange(ref this.lastHealthCountsSnapshot, currentTime, lastTime) == lastTime)
{
// our thread won setting the snapshot time so we will proceed with generating a new snapshot
// losing threads will continue using the old snapshot
long success = counter.GetRollingSum(HystrixRollingNumberEvent.Success);
long failure = counter.GetRollingSum(HystrixRollingNumberEvent.Failure); // fallbacks occur on this
long timeout = counter.GetRollingSum(HystrixRollingNumberEvent.Timeout); // fallbacks occur on this
long threadPoolRejected = counter.GetRollingSum(HystrixRollingNumberEvent.ThreadPoolRejected); // fallbacks occur on this
long semaphoreRejected = counter.GetRollingSum(HystrixRollingNumberEvent.SemaphoreRejected); // fallbacks occur on this
long shortCircuited = counter.GetRollingSum(HystrixRollingNumberEvent.ShortCircuited); // fallbacks occur on this
long totalCount = failure + success + timeout + threadPoolRejected + shortCircuited + semaphoreRejected;
long errorCount = failure + timeout + threadPoolRejected + shortCircuited + semaphoreRejected;
healthCountsSnapshot = new HealthCounts(totalCount, errorCount); }
}
return healthCountsSnapshot;
}
其中 failure 表示命令本身发生错误、 success 自然不必说， timeout 是超时、 threadPoolRejected 表示当线程池满后拒绝的命令调用、 shortCircuited 表示断路器打开后拒绝的命令调用， semaphoreRejected 使用信号量机制（而不是线程池）拒绝的命令调用。