Hystrix使用详解

原文参考：http://hot66hot.iteye.com/blog/2155036

一:为什么需要Hystrix?

在大中型分布式系统中，通常系统很多依赖(HTTP,hession,Netty,Dubbo等)，如下图:

在高并发访问下,这些依赖的稳定性与否对系统的影响非常大,但是依赖有很多不可控问题:如网络连接缓慢，资源繁忙，暂时不可用，服务脱机等.

如下图：QPS为50的依赖 I 出现不可用，但是其他依赖仍然可用.

当依赖I 阻塞时,大多数服务器的线程池就出现阻塞(BLOCK),影响整个线上服务的稳定性.如下图:

在复杂的分布式架构的应用程序有很多的依赖，都会不可避免地在某些时候失败。高并发的依赖失败时如果没有隔离措施，当前应用服务就有被拖垮的风险。

1. 例如:一个依赖30个SOA服务的系统,每个服务99.99%可用。
2. 99.99%的30次方 ≈ 99.7%
3. 0.3% 意味着一亿次请求 会有 3,000,00次失败
4. 换算成时间大约每月有2个小时服务不稳定.
5. 随着服务依赖数量的变多，服务不稳定的概率会成指数性提高.

解决问题方案:对依赖做隔离,Hystrix就是处理依赖隔离的框架,同时也是可以帮我们做依赖服务的治理和监控.

Netflix 公司开发并成功使用Hystrix,使用规模如下:

1. The Netflix API processes 10+ billion HystrixCommand executions per day using thread isolation.
2. Each API instance has 40+ thread-pools with 5-20 threads in each (most are set to 10).

二:Hystrix如何解决依赖隔离

1:Hystrix使用命令模式HystrixCommand(Command)包装依赖调用逻辑，每个命令在单独线程中/信号授权下执行。

2:可配置依赖调用超时时间,超时时间一般设为比99.5%平均时间略高即可.当调用超时时，直接返回或执行fallback逻辑。

3:为每个依赖提供一个小的线程池（或信号），如果线程池已满调用将被立即拒绝，默认不采用排队.加速失败判定时间。

4:依赖调用结果分:成功，失败（抛出异常），超时，线程拒绝，短路。 请求失败(异常，拒绝，超时，短路)时执行fallback(降级)逻辑。

5:提供熔断器组件,可以自动运行或手动调用,停止当前依赖一段时间(10秒)，熔断器默认错误率阈值为50%,超过将自动运行。

6:提供近实时依赖的统计和监控

Hystrix依赖的隔离架构,如下图:

三:如何使用Hystrix

1:使用maven引入Hystrix依赖

 <!-- 依赖版本 -->
 <hystrix.version>1.3.16</hystrix.version>
 <hystrix-metrics-event-stream.version>1.1.2</hystrix-metrics-event-stream.version> 

 <dependency>
      <groupId>com.netflix.hystrix</groupId>
      <artifactId>hystrix-core</artifactId>
      <version>${hystrix.version}</version>
  </dependency>
      <dependency>
      <groupId>com.netflix.hystrix</groupId>
      <artifactId>hystrix-metrics-event-stream</artifactId>
      <version>${hystrix-metrics-event-stream.version}</version>
  </dependency>
 <!-- 仓库地址 -->
 <repository>
      <id>nexus</id>
      <name>local private nexus</name>
      <url>http://maven.oschina.net/content/groups/public/</url>
      <releases>
           <enabled>true</enabled>
      </releases>
      <snapshots>
           <enabled>false</enabled>
      </snapshots>
 </repository>

2:使用命令模式封装依赖逻辑

 public class HelloWorldCommand extends HystrixCommand<String> {
     private final String name;
     public HelloWorldCommand(String name) {
         //最少配置:指定命令组名(CommandGroup)
         super(HystrixCommandGroupKey.Factory.asKey("ExampleGroup"));
         this.name = name;
     }
     @Override
     protected String run() {
         // 依赖逻辑封装在run()方法中
         return "Hello " + name +" thread:" + Thread.currentThread().getName();
     }
     //调用实例
     public static void main(String[] args) throws Exception{
         //每个Command对象只能调用一次,不可以重复调用,
         //重复调用对应异常信息:This instance can only be executed once. Please instantiate a new instance.
         HelloWorldCommand helloWorldCommand = new HelloWorldCommand("Synchronous-hystrix");
         //使用execute()同步调用代码,效果等同于:helloWorldCommand.queue().get();
         String result = helloWorldCommand.execute();
         System.out.println("result=" + result);

         helloWorldCommand = new HelloWorldCommand("Asynchronous-hystrix");
         //异步调用,可自由控制获取结果时机,
         Future<String> future = helloWorldCommand.queue();
         //get操作不能超过command定义的超时时间,默认:1秒
         result = future.get(100, TimeUnit.MILLISECONDS);
         System.out.println("result=" + result);
         System.out.println("mainThread=" + Thread.currentThread().getName());
     }

 }
     //运行结果: run()方法在不同的线程下执行
     // result=Hello Synchronous-hystrix thread:hystrix-HelloWorldGroup-1
     // result=Hello Asynchronous-hystrix thread:hystrix-HelloWorldGroup-2
     // mainThread=main

note:异步调用使用 command.queue()get(timeout, TimeUnit.MILLISECONDS);同步调用使用command.execute() 等同于 command.queue().get();

3:注册异步事件回调执行

 //注册观察者事件拦截
 Observable<String> fs = new HelloWorldCommand("World").observe();
 //注册结果回调事件
 fs.subscribe(new Action1<String>() {
     @Override
     public void call(String result) {
          //执行结果处理,result 为HelloWorldCommand返回的结果
         //用户对结果做二次处理.
     }
 });
 //注册完整执行生命周期事件
 fs.subscribe(new Observer<String>() {
             @Override
             public void onCompleted() {
                 // onNext/onError完成之后最后回调
                 System.out.println("execute onCompleted");
             }
             @Override
             public void onError(Throwable e) {
                 // 当产生异常时回调
                 System.out.println("onError " + e.getMessage());
                 e.printStackTrace();
             }
             @Override
             public void onNext(String v) {
                 // 获取结果后回调
                 System.out.println("onNext: " + v);
             }
         });
 /* 运行结果
 call execute result=Hello observe-hystrix thread:hystrix-HelloWorldGroup-3
 onNext: Hello observe-hystrix thread:hystrix-HelloWorldGroup-3
 execute onCompleted
 */

4:使用Fallback() 提供降级策略

NOTE: 除了HystrixBadRequestException异常之外，所有从run()方法抛出的异常都算作失败，并触发降级getFallback()和断路器逻辑。

HystrixBadRequestException用在非法参数或非系统故障异常等不应触发回退逻辑的场景。

5:依赖命名:CommandKey

 public HelloWorldCommand(String name) {
         super(Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("ExampleGroup"))
                 /* HystrixCommandKey工厂定义依赖名称 */
                 .andCommandKey(HystrixCommandKey.Factory.asKey("HelloWorld")));
         this.name = name;
     }

NOTE: 每个CommandKey代表一个依赖抽象,相同的依赖要使用相同的CommandKey名称。依赖隔离的根本就是对相同CommandKey的依赖做隔离.

6:依赖分组:CommandGroup

命令分组用于对依赖操作分组,便于统计,汇总等.

NOTE: CommandGroup是每个命令最少配置的必选参数，在不指定ThreadPoolKey的情况下，字面值用于对不同依赖的线程池/信号区分.

7:线程池/信号:ThreadPoolKey

最然在业务上都是相同的组，但是需要在资源上做隔离时，可以使用HystrixThreadPoolKey区分.

8:请求缓存 Request-Cache

NOTE:请求缓存可以让(CommandKey/CommandGroup)相同的情况下,直接共享结果，降低依赖调用次数，在高并发和CacheKey碰撞率高场景下可以提升性能.

Servlet容器中，可以直接实用Filter机制Hystrix请求上下文

9:信号量隔离:SEMAPHORE

隔离本地代码或可快速返回远程调用(如memcached,redis)可以直接使用信号量隔离,降低线程隔离开销.

10:fallback降级逻辑命令嵌套

适用场景:用于fallback逻辑涉及网络访问的情况,如缓存访问。

NOTE:依赖调用和降级调用使用不同的线程池做隔离，防止上层线程池跑满，影响二级降级逻辑调用.

11:显示调用fallback逻辑,用于特殊业务处理

NOTE:显示调用降级适用于特殊需求的场景,fallback用于业务处理，fallback不再承担降级职责，建议慎重使用，会造成监控统计换乱等问题.

12:命令调用合并:HystrixCollapser

命令调用合并允许多个请求合并到一个线程/信号下批量执行。

执行流程图如下:

NOTE:使用场景:HystrixCollapser用于对多个相同业务的请求合并到一个线程甚至可以合并到一个连接中执行，降低线程交互次和IO数,但必须保证他们属于同一依赖.

四:监控平台搭建Hystrix-dashboard

1:监控dashboard介绍

dashboard面板可以对依赖关键指标提供实时监控,如下图:

2:实例暴露command统计数据

Hystrix使用Servlet对当前JVM下所有command调用情况作数据流输出

配置如下:

3:集群模式监控统计搭建

1)使用Turbine组件做集群数据汇总

结构图如下;

2)内嵌jetty提供Servlet容器,暴露HystrixMetrics

3)Turbine搭建和配置

a:配置Turbine Servlet收集器

b:编写config.properties配置集群实例

c:使用Dashboard配置连接Turbine

如下图 :

五:Hystrix配置与分析

1:Hystrix 配置

1):Command 配置

Command配置源码在HystrixCommandProperties,构造Command时通过Setter进行配置

具体配置解释和默认值如下

 //使用命令调用隔离方式,默认:采用线程隔离,ExecutionIsolationStrategy.THREAD
 private final HystrixProperty<ExecutionIsolationStrategy> executionIsolationStrategy;
 //使用线程隔离时，调用超时时间，默认:1秒
 private final HystrixProperty<Integer> executionIsolationThreadTimeoutInMilliseconds;
 //线程池的key,用于决定命令在哪个线程池执行
 private final HystrixProperty<String> executionIsolationThreadPoolKeyOverride;
 //使用信号量隔离时，命令调用最大的并发数,默认:10
 private final HystrixProperty<Integer> executionIsolationSemaphoreMaxConcurrentRequests;
 //使用信号量隔离时，命令fallback(降级)调用最大的并发数,默认:10
 private final HystrixProperty<Integer> fallbackIsolationSemaphoreMaxConcurrentRequests;
 //是否开启fallback降级策略 默认:true
 private final HystrixProperty<Boolean> fallbackEnabled;
 // 使用线程隔离时，是否对命令执行超时的线程调用中断（Thread.interrupt()）操作.默认:true
 private final HystrixProperty<Boolean> executionIsolationThreadInterruptOnTimeout;
 // 统计滚动的时间窗口,默认:5000毫秒circuitBreakerSleepWindowInMilliseconds
 private final HystrixProperty<Integer> metricsRollingStatisticalWindowInMilliseconds;
 // 统计窗口的Buckets的数量,默认:10个,每秒一个Buckets统计
 private final HystrixProperty<Integer> metricsRollingStatisticalWindowBuckets; // number of buckets in the statisticalWindow
 //是否开启监控统计功能,默认:true
 private final HystrixProperty<Boolean> metricsRollingPercentileEnabled;
 // 是否开启请求日志,默认:true
 private final HystrixProperty<Boolean> requestLogEnabled;
 //是否开启请求缓存,默认:true
 private final HystrixProperty<Boolean> requestCacheEnabled; // Whether request caching is enabled.

Circuit Breaker配置源码在HystrixCommandProperties,构造Command时通过Setter进行配置,每种依赖使用一个Circuit Breaker

 // 熔断器在整个统计时间内是否开启的阀值，默认20秒。也就是10秒钟内至少请求20次，熔断器才发挥起作用
 private final HystrixProperty<Integer> circuitBreakerRequestVolumeThreshold;
 //熔断器默认工作时间,默认:5秒.熔断器中断请求5秒后会进入半打开状态,放部分流量过去重试
 private final HystrixProperty<Integer> circuitBreakerSleepWindowInMilliseconds;
 //是否启用熔断器,默认true. 启动
 private final HystrixProperty<Boolean> circuitBreakerEnabled;
 //默认:50%。当出错率超过50%后熔断器启动.
 private final HystrixProperty<Integer> circuitBreakerErrorThresholdPercentage;
 //是否强制开启熔断器阻断所有请求,默认:false,不开启
 private final HystrixProperty<Boolean> circuitBreakerForceOpen;
 //是否允许熔断器忽略错误,默认false, 不开启
 private final HystrixProperty<Boolean> circuitBreakerForceClosed; 

3):命令合并(Collapser)配置

Command配置源码在HystrixCollapserProperties,构造Collapser时通过Setter进行配置

 //请求合并是允许的最大请求数,默认: Integer.MAX_VALUE
 private final HystrixProperty<Integer> maxRequestsInBatch;
 //批处理过程中每个命令延迟的时间,默认:10毫秒
 private final HystrixProperty<Integer> timerDelayInMilliseconds;
 //批处理过程中是否开启请求缓存,默认:开启
 private final HystrixProperty<Boolean> requestCacheEnabled;

4):线程池(ThreadPool)配置

 /**
 配置线程池大小,默认值10个.
 建议值:请求高峰时99.5%的平均响应时间 + 向上预留一些即可
 */
 HystrixThreadPoolProperties.Setter().withCoreSize(int value)
 /**
 配置线程值等待队列长度,默认值:-1
 建议值:-1表示不等待直接拒绝,测试表明线程池使用直接决绝策略+ 合适大小的非回缩线程池效率最高.所以不建议修改此值。
 当使用非回缩线程池时，queueSizeRejectionThreshold,keepAliveTimeMinutes 参数无效
 */
 HystrixThreadPoolProperties.Setter().withMaxQueueSize(int value) 

2:Hystrix关键组件分析

1):Hystrix流程结构解析

流程说明:

1:每次调用创建一个新的HystrixCommand,把依赖调用封装在run()方法中.

2:执行execute()/queue做同步或异步调用.

3:判断熔断器(circuit-breaker)是否打开,如果打开跳到步骤8,进行降级策略,如果关闭进入步骤.

4:判断线程池/队列/信号量是否跑满，如果跑满进入降级步骤8,否则继续后续步骤.

5:调用HystrixCommand的run方法.运行依赖逻辑

5a:依赖逻辑调用超时,进入步骤8.

6:判断逻辑是否调用成功

6a:返回成功调用结果

6b:调用出错，进入步骤8.

7:计算熔断器状态,所有的运行状态(成功, 失败, 拒绝,超时)上报给熔断器，用于统计从而判断熔断器状态.

8:getFallback()降级逻辑.

以下四种情况将触发getFallback调用：

(1):run()方法抛出非HystrixBadRequestException异常。

(2):run()方法调用超时

(3):熔断器开启拦截调用

(4):线程池/队列/信号量是否跑满

8a:没有实现getFallback的Command将直接抛出异常

8b:fallback降级逻辑调用成功直接返回

8c:降级逻辑调用失败抛出异常

9:返回执行成功结果

2):熔断器:Circuit Breaker

Circuit Breaker 流程架构和统计

每个熔断器默认维护10个bucket,每秒一个bucket,每个blucket记录成功,失败,超时,拒绝的状态，

默认错误超过50%且10秒内超过20个请求进行中断拦截.

3)隔离(Isolation)分析

Hystrix隔离方式采用线程/信号的方式,通过隔离限制依赖的并发量和阻塞扩散.

(1):线程隔离

把执行依赖代码的线程与请求线程(如:jetty线程)分离，请求线程可以自由控制离开的时间(异步过程)。

通过线程池大小可以控制并发量，当线程池饱和时可以提前拒绝服务,防止依赖问题扩散。

线上建议线程池不要设置过大，否则大量堵塞线程有可能会拖慢服务器。

(2):线程隔离的优缺点

线程隔离的优点:

[1]:使用线程可以完全隔离第三方代码,请求线程可以快速放回。

[2]:当一个失败的依赖再次变成可用时，线程池将清理，并立即恢复可用，而不是一个长时间的恢复。

[3]:可以完全模拟异步调用，方便异步编程。

线程隔离的缺点:

[1]:线程池的主要缺点是它增加了cpu，因为每个命令的执行涉及到排队(默认使用SynchronousQueue避免排队)，调度和上下文切换。

[2]:对使用ThreadLocal等依赖线程状态的代码增加复杂性，需要手动传递和清理线程状态。

NOTE: Netflix公司内部认为线程隔离开销足够小，不会造成重大的成本或性能的影响。

Netflix 内部API 每天100亿的HystrixCommand依赖请求使用线程隔，每个应用大约40多个线程池，每个线程池大约5-20个线程。

(3):信号隔离

信号隔离也可以用于限制并发访问，防止阻塞扩散, 与线程隔离最大不同在于执行依赖代码的线程依然是请求线程（该线程需要通过信号申请）,

如果客户端是可信的且可以快速返回，可以使用信号隔离替换线程隔离,降低开销.

线程隔离与信号隔离区别如下图:

解析图片出自官网wiki , 更多内容请见官网: https://github.com/Netflix/Hystrix