Hystrix的中文含义是豪猪, 因其背上长满了刺,而拥有自我保护能力. Netflix的Hystrix是一个帮助解决分布式系统交互时超时处理和容错的类库, 它同样拥有保护系统的能力。Hystrix的设计原则包括:
资源隔离、熔断器、命令模式。Hystrix采用资源隔离的方式来防止雪崩效应,资源隔离的方式又分为线程池隔离和信号量隔离两种方式。如下图所示,假设商品详情服务依赖三个服务,每个服务建立单独的线程池,假设商品评论服务出现问题,响应很慢,有很多线程处于等待状态,那么最多也就消耗20个线程,而不会因为商品评论服务的原因,出现雪崩效应,导致线程耗尽,所有服务都不可用的情况。
信号量隔离指通过设置信号量来控制并发请求数量。信号量隔离适用于请求并发量大,并且耗时短(请求耗时短可能是计算量小,或读缓存),采用信号量隔离策略,因为这类服务的返回通常会非常的快,不会占用容器线程太长时间,而且也减少了线程切换的一些开销,提高了缓存服务的效率。线程隔离和信号量隔离的区别以及涉及的一些配置项如下所示:
上面介绍了资源隔离,接着来看看Hystrix的熔断器设计原则,下图是Hystrix工作流程图。
- 构建Hystrix的Command对象, 调用执行方法,同步调用是.execute(),异步调用是.queue().
- Hystrix检查当前服务的熔断器开关是否开启, 若开启, 则执行降级服务getFallback方法.
- 若熔断器开关关闭, 则Hystrix检查当前服务的线程池是否能接收新的请求, 若超过线程池已满, 则执行降级服务getFallback方法.
- 若线程池接受请求, 则Hystrix开始执行服务调用具体逻辑run方法.
- 若服务执行失败, 则执行降级服务getFallback方法, 并将执行结果上报Metrics,更新服务健康状况.
- 若服务执行超时, 则执行降级服务getFallback方法, 并将执行结果上报Metrics,更新服务健康状况.
- 若服务执行成功, 返回正常结果.
- 若服务降级方法getFallback执行成功, 则返回降级结果.
- 若服务降级方法getFallback执行失败, 则抛出异常.
上面介绍了Hystrix的断路器设计原则,接着再来看看命令模式设计原则。Hystrix使用命令模式(继承HystrixCommand类)来包裹具体的服务调用逻辑(run方法), 并在命令模式中添加了服务调用失败后的降级逻辑(getFallback).同时我们在Command的构造方法中可以定义当前服务线程池和熔断器的相关参数。伪代码如下所示:
public class Service1HystrixCommand extends HystrixCommand<Response> {
private Service1 service;
private Request request;
public Service1HystrixCommand(Service1 service, Request request){
supper(
Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("ServiceGroup"))
.andCommandKey(HystrixCommandKey.Factory.asKey("servcie1query"))
.andThreadPoolKey(HystrixThreadPoolKey.Factory.asKey("service1ThreadPool"))
.andThreadPoolPropertiesDefaults(HystrixThreadPoolProperties.Setter()
.withCoreSize(20))//服务线程池数量
.andCommandPropertiesDefaults(HystrixCommandProperties.Setter()
.withCircuitBreakerErrorThresholdPercentage(60)//熔断器关闭到打开阈值
.withCircuitBreakerSleepWindowInMilliseconds(3000)//熔断器打开到关闭的时间窗长度
))
this.service = service;
this.request = request;
);
}
@Override
protected Response run(){
return service1.call(request);
}
@Override
protected Response getFallback(){
return Response.dummy();
}
}
命令模式中涉及一些基本术语需要了解,第一:HystrixCommand中run方法,run方法里面编写具体的服务调用逻辑。第二:Fail Fast,如果调用失败,直接在run方法中抛出异常。第三:Fail Silent,getFallback()方法中返回一些空对象,例如如下所示:
return null;
return new Option<T>();
return Collections.emptyList();
return Collection.emptyMap();
第四:Static Fallback,getFallback()方法中返回默认值,例如返回true,default_object等。第五:Fallback via network,在失败的情况下再发起一次remote请求,不过这次请求的是一个缓存比如redis。由于是又发起一起远程调用,所以会重新封装一次Command,这个时候要注意,执行fallback的线程一定要跟主线程区分开,也就是重新命名一个ThreadPoolKey,过程如下所示:
上面是对Hystrix概念的介绍,接下来就看看实际例子,Demo地址来自官网。
以HelloWorld为例,construct方法进行了一些初始化的内容,例如设置groupKey等,run()方法中是返回一个简单的string,在调用时如果是同步,则用new Commandxxx().execute(),异步方式则用new Commandxxx().queue().另外还支持observe()方式。HystrixCommand:此命令本质上是一个阻塞命令,但如果与observe()一起使用,则提供一个可观察的外观。HystrixObservableCommand:此命令应用于非阻塞调用模式。此命令的调用方将订阅run()方法返回的observate。不同之处在于,hystrixcommand默认支持阻塞范式,但也通过门面提供可观察的非阻塞行为,而hystrixobservatablecommand是专门为非阻塞设置实现的。具体例子可以在这里查看。
除了基础的HelloWorld例子,还有FailsFast,FailSilent,FallbackViaNetwork等例子,具体代码如下所示:
除了上面的基础例子,Hystrix官网还提供了一个完整的Demo例子,接下来看看这个Demo例子。这个Demo例子主要模拟了从获取用户账户信息到最终完成支持的过程。
先看看程序入口这个类,这里类里面封装了模拟交易的方法以及收集metrics的方法,模拟交易的方法里面就调用了上面绿色框的四个Command。
看第一个获取用户账户信息的Command,run方法里面主要就是模拟了正常情况,以及一定概率的失败情况和超时情况。GetPaymentInfoCommand和GetOrderCommand封装的run()方法逻辑基本相同,CreditCardCommand中封装了getway对象,getway对象的submit方法也是模拟一定概率的失败和超时情况。
接下来运行上面介绍了demo程序,并通过Hystrix-dashboard查看相关数据。为了在dashboard上查看上面demo的运行结果,需要进入四个步骤
步骤一:clone下面的代码,hystrix-dashboard缺失一个gradle-wrapper.jar
文件,可以将Hystrix中的wrapper
文件夹复制并覆盖hystrix-dashboard下的wrapper
文件夹。
https://github.com/Netflix/Hystrix.git
https://github.com/Netflix-Skunkworks/hystrix-dashboard
步骤二:启动dashboard和example-webapp
cd hystrix-examples-webapp
../gradlew appRun
cd hystrix-dashboard
./gradlew appRun
步骤三:浏览器上访问example-webapp,添加hystrix.stream到dashboard上
步骤四:用curl命令不停的访问example-webapp应用程序
while true;
do curl "http://localhost:8989/hystrix-examples-webapp/";
done
运行后查看dashboard上监听到的数据,信息如下所示:
Dashboard上涉及到的关键数据含义如下所示:
修改Demo代码的四个Command的run方法中,失败的占比,再次对比查看dashboard上的信息,可以明显看到超时错误占比上升以及异常错误占比上升。
以上就是对Hystrix工作过程的理解,总结Hystrix的特点如下所示:
-
Hystrix 是基于单机应用的熔断限流框架
-
根据熔断器的滑动窗口判断当前请求是否可以执行
-
线程竞争实现“半关闭”状态,拿一个请求试试是否可以关闭熔断器
-
线程池隔离将请求丢到线程池中运行,限流依靠线程池拒绝策略
-
信号量隔离在当前线程中运行,限流依靠并发请求数
-
当信号量竞争失败/线程池队列满,就进入限流模式,执行 Fallback
-
当熔断器开启,就熔断请求,执行 Fallback