Hystrix把服务调用统称为依赖调用, Hystrix通过命令模式封装依赖调用,每一个依赖调用封装在HystrixCommand中,每个命令在Hystrix的线程池中运行。另外可以对其配置分组名、线程组,使得不同的依赖可以分类在不同的线程组,隔离不同模块的依赖,也可根据负载情况,配置不同组的线程数。Hystrix还提供一种熔断器(CircuitBreaker)的机制,Hystrix可以通过设定的条件判断该封装的依赖调用是否可以正确调用,如果在一定时间内调用失败次数过多,则会熔断自身,使得相同的调用无法执行,待冷却之后重新再试。
构造HystrixCommand
命名HystrixCommandKey
HystrixCommand有自己的名字,比如可以是某远程服务名,如查询购物车、查询订单等,Hystrix使用单例模式存储HystrixCommand,熔断机制正式基于单实例上的调用情况统计实现。如果不设置这个名字,Hystrix会为其设置默认的名字:类名。
分组HystrixCommandGroupKey
GroupKey是每个命令最少配置的必选参数,因为下一个参数HystrixThreadPoolKey如果不指定的话,其会使用该参数值
线程池 HystrixThreadPoolKey
ThreadPoolKey顾名思义,是HystrixCommand运行所在的线程池,如果该参数不设置则使用GroupKey作为ThreadPoolKey,这种情况下往往是同一个业务模块的依赖调用在同一个线程池内,比如使用服务模块[user,order,product等]作为GroupKey,各个模块。如果同一业务内的服务之间还需要隔离的话,就可以设置该参数,比如order的订单和购物车可以通过设置不同的ThreadPoolKey再区分到不同线程池中,这在应对高并发时可以带来较好的效果,因为订单某些查询时比较慢的,如果和购物车放在同一个线程池回影响购物车的速率,同时也可以把下单接口单独隔离。
另外可以通过HystrixThreadPoolProperties设置线程池的属性,比如核心线程数大小、最大线程数、任务队列大小,和java的线程池一致,HystrixThreadPoolProperties本身也提供了一些默认值。
下面是简单的一个HystrixCommand的构造过程
//构造setter HystrixCommandGroupKey groupKey = HystrixCommandGroupKey.Factory.asKey(group); HystrixThreadPoolKey threadPoolKey = HystrixThreadPoolKey.Factory.asKey(group); HystrixCommandKey commandKey = HystrixCommandKey.Factory.asKey(service); HytrixBaseCommand.Setter setter = HytrixBaseCommand.Setter.withGroupKey(groupKey) .andCommandKey(commandKey) .andThreadPoolKey(threadPoolKey); //构造command HystrixCommand<String> command = new HystrixCommand<String>(setter) { protected String run() throws Exception { logger.info("##################### in hystrix thread"); Thread.sleep(time); if(isException) throw new RuntimeException("exception in run"); return service+ ":return"; } @Override protected String getFallback() { logger.info("##################### in request thread"); return service+":fallback"; } };
run()方法
实现run方法,执行具体的依赖调用。
getFallback()方法
如果run方法中发生异常,或者run方法运行时间过长(相当于超时),又或者线程池中任务队列已满,这时HystrixCommand会调用getFallback返回一个默认值,当然也可以在这进行特殊的出错处理,该函数是运行在web请求线程中。如果没有重写该方法,那run抛出的异常将被抛到web请求线程中。
如果某个依赖的run方法在短时间内发生异常或超时次数过多,此时Hystrix会发生熔断,该依赖新的HystrixCommand执行会直接调用getFallback返回,避免无效的调用浪费资源。当然在冷却一段时间后,新的依赖调用还是会通过run重试。
执行HystrixCommand
HystrixCommand的执行有以下四种方式
1.execute()
阻塞方式,内部使用queue().get()
2.queue()
非阻塞方式,返回future对象,可以再调用get来阻塞调用获取结果
3.observe()
热注册方式
4.toObservable()
冷注册方式,等注册时执行
前三种调用方式,最终都是依赖第四种方式.
Hystrix 另外还提供给我们一个监控功能,可以直接使用其开源项目进行配置,就能实时的观察我们的服务调用情况。
配置 Hystrix-dashboard
1.构建dashboard项目
$ git clone https://github.com/Netflix/Hystrix.git $ cd Hystrix/hystrix-dashboard $ ../gradlew jettyRun
打开路径: http://localhost:7979/hystrix-dashboard
2.配置服务状态上报 xml
<servlet> <display-name>HystrixMetricsStreamServlet</display-name> <servlet-name>HystrixMetricsStreamServlet</servlet-name> <servlet-class>com.netflix.hystrix.contrib.metrics.eventstream.HystrixMetricsStreamServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>HystrixMetricsStreamServlet</servlet-name> <url-pattern>/hystrix.stream</url-pattern> </servlet-mapping>
3.添加stream
在hystrix-dashboard中按照说明添加自己的http://hystrix-app:port/hystrix.stream,然后监视
4.如果是集群,通过turbine进行监视
Hystrix执行 流程图
简单的翻译下官网介绍,其中注意几点,excute,queue方法最终会调用toObservable方法。如果使用ObservableCommand,需要实现的方法分别为construct方法与resumeWithFallBack方法。
测试例子
@Component @RequestMapping("/cmd") public class CmdCtl { Logger logger = LoggerFactory.getLogger(CmdCtl.class); @RequestMapping("/do") @ResponseBody public String getOne(@RequestParam String method, @RequestParam(required = false,defaultValue = "0") Integer time, @RequestParam(required = false,defaultValue = "false") Boolean isException) { return dispatch(method,time,isException); } public String dispatch(final String service,final int time,final boolean isException) { String group = service.split("\\.")[0]; //构造setter HystrixCommandGroupKey groupKey = HystrixCommandGroupKey.Factory.asKey(group); HystrixThreadPoolKey threadPoolKey = HystrixThreadPoolKey.Factory.asKey(group); HystrixCommandKey commandKey = HystrixCommandKey.Factory.asKey(service); HytrixBaseCommand.Setter setter = HytrixBaseCommand.Setter.withGroupKey(groupKey) //分组名 .andCommandKey(commandKey) //依赖名 .andThreadPoolKey(threadPoolKey); //执行线程池名 //构造command HystrixCommand<String> command = new HystrixCommand<String>(setter) { protected String run() throws Exception { logger.info("##################### in hystrix thread"); if(time>0)//模拟长时间操作 Thread.sleep(time); if(isException) //模拟异常情况 throw new RuntimeException("exception in run"); return service+ ":return"; } @Override protected String getFallback() { logger.info("##################### in request thread"); return service+":fallback"; } }; //阻塞执行,获取结果 String rel=command.execute(); return rel; } }
测试结果
可以通过设置不同的请求查看调用结果,对于熔断机制,因为默认的熔断器是在短时间内进行判断,因此可以通过jmeter进行并发测试。
启动30个线程执行
测试中有三类请求:
one.p1 time:1000 isException:false
one.p2 time:1000 isException:true
two.a1 time:100 isException:false
可以发现one.p1和one.p2 服务依赖出错情况较多,one.p2主要是由于抛出异常错误率为100%,且熔断器circult为open状态,one.p1因为运行时间较长,也发生了熔断,错误也较多。但是tow模块的请求未受到任何影响。
对于熔断机制,和一些参数设置还需要进一步学习研究。