使用Hystrix提高系统可用性

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

（图片来源：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框架 帮我们大大简化了超时机制和断路器的实现。

先上POM依赖：

  com.netflix.hystrix
  hystrix-core
  1.3.13

使用Hystrix，需要通过Command封装对远程依赖的调用：

public class CommandHelloWorld extends HystrixCommand {    

    public CommandHelloWorld() {
        super(HystrixCommandGroupKey.Factory.asKey("ExampleGroup"));        
    }

    @Override
    protected String run() {
        return dependencyService.call(); //this call may timeout or block
    }
}

然后在需要的时候调用这个Command：

String s = new CommandHelloWorld().execute();

上述是同步调用，当然如果业务逻辑允许且更追求性能，或许可以选择异步调用：

Observable observable = new CommandHelloWorld().observe();
observable.subscribe(new Observer() {
    @Override
    public void onCompleted() {
        // do nothing
    }

    @Override
    public void onError(Throwable e) {
         e.printStackTrace();
    }

    @Override
    public void onNext(String v) {
        // do nothing
    }
});

该例中，不论 dependencyService.call() 自身有没有超时机制（可能你会发现很多远程调用接口自身并没有给你提供超时机制），用 HystrixCommand 封装过后，超时是强制的，默认超时时间是1秒，当然你可以根据需要自己在构造函数中调节 Command 的超时时间，例如说2秒：

super(Setter
    .withGroupKey(HystrixCommandGroupKey.Factory.asKey("ExampleGroup"))
    .andCommandPropertiesDefaults(HystrixCommandProperties.Setter().withExecutionIsolationThreadTimeoutInMilliseconds(2000))
  );

当Hystrix执行命令超时后，它会抛出如下的异常：

com.netflix.hystrix.exception.HystrixRuntimeException: MyCommand timed-out and no fallback available.
	at com.netflix.hystrix.HystrixCommand.getFallbackOrThrowException(HystrixCommand.java:1644)
	at com.netflix.hystrix.HystrixCommand.access$1900(HystrixCommand.java:98)
	at com.netflix.hystrix.HystrixCommand$TimeoutObservable$1$1.run(HystrixCommand.java:1019)
	at com.netflix.hystrix.strategy.concurrency.HystrixContextRunnable$1.call(HystrixContextRunnable.java:41)
	at com.netflix.hystrix.strategy.concurrency.HystrixContextRunnable$1.call(HystrixContextRunnable.java:37)
	at com.netflix.hystrix.strategy.concurrency.HystrixContextRunnable.run(HystrixContextRunnable.java:57)
	at com.netflix.hystrix.HystrixCommand$TimeoutObservable$1$2.tick(HystrixCommand.java:1043)
	at com.netflix.hystrix.util.HystrixTimer$1.run(HystrixTimer.java:101)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
	...
Caused by: java.util.concurrent.TimeoutException
	... 15 more

注意异常信息中包含“MyCommand timed-out and no fallback available.”，也就是说 Hystrix 执行命令超时或者失败之后，是会尝试去调用一个 fallback 的，这个 fallback 即一个备用方案，要为 HystrixCommand 提供 fallback，只要重写 protected String getFallback() 方法即可。

一般情况下，Hystrix 会为 Command 分配专门的线程池，池中的线程数量是固定的，这也是一个保护机制，假设你依赖很多个服务，你不希望对其中一个服务的调用消耗过多的线程以致于其他服务都没线程调用了。默认这个线程池的大小是10，即并发执行的命令最多只能有是个了，超过这个数量的调用就得排队，如果队伍太长了（默认超过5），Hystrix就立刻走 fallback 或者抛异常。

根据你的具体需要，你可能会想要调整某个Command的线程池大小，例如你对某个依赖的调用平均响应时间为200ms，而峰值的QPS是200，那么这个并发至少就是 0.2 x 200 = 40 ( Little’s Law)，考虑到一定的宽松度，这个线程池的大小设置为60可能比较合适：

super(Setter
    .withGroupKey(HystrixCommandGroupKey.Factory.asKey("ExampleGroup"))
    .andThreadPoolPropertiesDefaults(HystrixThreadPoolProperties.Setter().withCoreSize(60))
  );

说了这么多，还没提到Hystrix的断路器，其实对于使用者来说，断路器机制默认是启用的，但是编程接口默认几乎不需要关心这个，机制和前面讲的也差不多，Hystrix会统计命令调用，看其中失败的比例，默认当超过50%失败后，开启断路器，那之后一段时间的命令调用直接返回失败（或者走fallback），5秒之后，Hystrix再尝试关闭断路器，看看请求是否能正常响应。下面的几行Hystrix源码展示了它如何统计失败率的：

long totalCount = failure + success + timeout + threadPoolRejected + shortCircuited + semaphoreRejected;
  long errorCount = failure + timeout + threadPoolRejected + shortCircuited + semaphoreRejected;
  int errorPercentage = 0;

  if (totalCount > 0) {
      errorPercentage = (int) ((double) errorCount / totalCount * 100);
  }

其中 failure 表示命令本身发生错误、success 自然不必说，timeout 是超时、threadPoolRejected 表示当线程池满后拒绝的命令调用、shortCircuited 表示断路器打开后拒绝的命令调用，semaphoreRejected 使用信号量机制（而不是线程池）拒绝的命令调用。

本文并不打算完整地介绍 Hystrix，这里只是介绍了为什么要用 Hystrix 以及使用它需要关心的一些基本核心概念，Hystrix 是 Netflix 的核心中间件，在保证他们系统可用性上起到了非常核心的作用，它还有更多的功能都在文档完整地介绍了： https://github.com/Netflix/Hystrix/wiki，其中最重要的而且本文没有介绍的，可能就是监控功能了，当系统足够复杂，相互依赖错综发杂的时候，快速定位到故障点，是运维非常关心的问题。