目前对于一些非核心操作,如增减库存后保存操作日志 发送异步消息时(具体业务流程),一旦出现MQ服务异常时,会导致接口响应超时,因此可以考虑对非核心操作引入服务降级、服务隔离。
官方文档 [https://github.com/Netflix/Hystrix/wiki]
hystrix是netflix开源的一个容灾框架,解决当外部依赖故障时拖垮业务系统、甚至引起雪崩的问题。
在大中型分布式系统中,通常系统很多依赖(HTTP,hession,Netty,Dubbo等),在高并发访问下,这些依赖的稳定性与否对系统的影响非常大,但是依赖有很多不可控问题:如网络连接缓慢,资源繁忙,暂时不可用,服务脱机等。
当依赖阻塞时,大多数服务器的线程池就出现阻塞(BLOCK),影响整个线上服务的稳定性,在复杂的分布式架构的应用程序有很多的依赖,都会不可避免地在某些时候失败。高并发的依赖失败时如果没有隔离措施,当前应用服务就有被拖垮的风险。
例如:一个依赖30个SOA服务的系统,每个服务99.99%可用。 99.99%的30次方 ≈ 99.7% 0.3% 意味着一亿次请求 会有 3,000,00次失败 换算成时间大约每月有2个小时服务不稳定. 随着服务依赖数量的变多,服务不稳定的概率会成指数性提高.
解决问题方案:对依赖做隔离。
想要知道如何使用,必须先明白其核心设计理念,Hystrix基于命令模式
Command是在Receiver和Invoker之间添加的中间层,Command实现了对Receiver的封装 那么Hystrix的应用场景如何与上图对应呢?
API既可以是Invoker又可以是reciever,通过继承Hystrix核心类HystrixCommand来封装这些API(例如,远程接口调用,数据库查询之类可能会产生延时的操作)。就可以为API提供弹性保护了。
1: Hystrix使用命令模式HystrixCommand(Command)包装依赖调用逻辑,每个命令在单独线程中/信号授权下执行。 2: 可配置依赖调用超时时间,超时时间一般设为比99.5%平均时间略高即可.当调用超时时,直接返回或执行fallback逻辑。 3: 为每个依赖提供一个小的线程池(或信号),如果线程池已满调用将被立即拒绝,默认不采用排队.加速失败判定时间。 4: 依赖调用结果分:成功,失败(抛出异常),超时,线程拒绝,短路。 请求失败(异常,拒绝,超时,短路)时执行fallback(降级)逻辑。 5: 提供熔断器组件,可以自动运行或手动调用,停止当前依赖一段时间(10秒),熔断器默认错误率阈值为50%,超过将自动运行。 6: 提供近实时依赖的统计和监控
流程说明:
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:返回执行成功结果
每个熔断器默认维护10个bucket,每秒一个bucket,每个bucket记录成功,失败,超时,拒绝的状态
默认错误超过50%且10秒内超过20个请求进行中断拦截.
Hystrix隔离方式采用线程/信号的方式,通过隔离限制依赖的并发量和阻塞扩散.
把执行依赖代码的线程与请求线程(如:jetty线程)分离,请求线程可以自由控制离开的时间(异步过程)。
通过线程池大小可以控制并发量,当线程池饱和时可以提前拒绝服务,防止依赖问题扩散。
线上建议线程池不要设置过大,否则大量堵塞线程有可能会拖慢服务器。
线程隔离的优点: [1]:使用线程可以完全隔离第三方代码,请求线程可以快速放回。 [2]:当一个失败的依赖再次变成可用时,线程池将清理,并立即恢复可用,而不是一个长时间的恢复。 [3]:可以完全模拟异步调用,方便异步编程。
线程隔离的缺点: [1]:线程池的主要缺点是它增加了cpu,因为每个命令的执行涉及到排队(默认使用SynchronousQueue避免排队),调度和上下文切换。 [2]:对使用ThreadLocal等依赖线程状态的代码增加复杂性,需要手动传递和清理线程状态。
NOTE: Netflix公司内部认为线程隔离开销足够小,不会造成重大的成本或性能的影响。 Netflix 内部API 每天100亿的HystrixCommand依赖请求使用线程隔,每个应用大约40多个线程池,每个线程池大约5-20个线程。
线程隔离与信号隔离区别如下图:
本文会重点介绍基于服务化项目(thrift服务化项目)的接入方式。
关于版本问题:由于不同版本Compile Dependencies不同,在使用过程中可以针对具体情况修改版本,具体依赖关系http://mvnrepository.com/artifact/com.netflix.hystrix/hystrix-javanica
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
|
<hystrix-version>``1.4``.``22``</hystrix-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-version}</version>
</dependency>
<dependency>
<groupId>com.netflix.hystrix</groupId>
<artifactId>hystrix-javanica</artifactId>
<version>${hystrix-version}</version>
</dependency>
<dependency>
<groupId>com.netflix.hystrix</groupId>
<artifactId>hystrix-servo-metrics-publisher</artifactId>
<version>${hystrix-version}</version>
</dependency>
<dependency>
<groupId>com.meituan.service.us</groupId>
<artifactId>hystrix-collector</artifactId>
<version>``1.0``-SNAPSHOT</version>
</dependency>
|
application-context.xml文件中
|
1
2
3
4
|
<aop:aspectj-autoproxy/>
<bean id=``"hystrixAspect"
class``=``"com.netflix.hystrix.contrib.javanica.aop.aspectj.HystrixCommandAspect"``></bean>
<context:component-scan base-``package``=``"com.***.***"``/>
<context:annotation-config/>
|
注意:
1)hystrixAspect的这两行配置一定要和下面的context:component-scan放在同一个文件 2)Hystrix依赖的一些jar需要解决冲突问题,例如guava为15.0版本
需要注册plugin,直接从plugin中获取统计数据
新增初始化Bean
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
import
com.meituan.service.us.collector.notifier.CustomEventNotifier;
import
com.netflix.hystrix.contrib.servopublisher.HystrixServoMetricsPublisher;
import
com.netflix.hystrix.strategy.HystrixPlugins;
import
org.slf4j.Logger;
import
org.slf4j.LoggerFactory;
import
org.springframework.beans.factory.InitializingBean;
/**
* Created by gaoguangchao on 16/7/1.
*/
public
class
HystrixMetricsInitializingBean {
private
static
final
Logger LOGGER = LoggerFactory.getLogger(HystrixMetricsInitializingBean.``class``);
public
void
init()
throws
Exception {
LOGGER.info(``"HystrixMetrics starting..."``);
HystrixPlugins.getInstance().registerEventNotifier(CustomEventNotifier.getInstance());
HystrixPlugins.getInstance().registerMetricsPublisher(HystrixServoMetricsPublisher.getInstance());
}
}
|
application-context.xml文件中
|
1
|
<bean id=``"hystrixMetricsInitializingBean"
class``=``"com.***.HystrixMetricsInitializingBean"
init-method=``"init"``/>
|
本文使用同步执行方式,因此注解及方法实现都为同步方式,如果有异步执行、反应执行的需求,可以参考:官方注解说明[https://github.com/Netflix/Hystrix/tree/master/hystrix-contrib/hystrix-javanica]
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
@HystrixCommand``(groupKey =
"productStockOpLog"``, commandKey =
"addProductStockOpLog"``, fallbackMethod =
"addProductStockOpLogFallback"``,
commandProperties = {
@HystrixProperty``(name =
"execution.isolation.thread.timeoutInMilliseconds"``, value =
"400"``),``//指定多久超时,单位毫秒。超时进fallback
@HystrixProperty``(name =
"circuitBreaker.requestVolumeThreshold"``, value =
"10"``),``//判断熔断的最少请求数,默认是10;只有在一个统计窗口内处理的请求数量达到这个阈值,才会进行熔断与否的判断
@HystrixProperty``(name =
"circuitBreaker.errorThresholdPercentage"``, value =
"10"``),``//判断熔断的阈值,默认值50,表示在一个统计窗口内有50%的请求处理失败,会触发熔断
}
)
public
void
addProductStockOpLog(Long sku_id, Object old_value, Object new_value)
throws
Exception {
if
(new_value !=
null
&& !new_value.equals(old_value)) {
doAddOpLog(``null``,
null``, sku_id,
null``, ProductOpType.PRODUCT_STOCK, old_value !=
null
? String.valueOf(old_value) :
null``, String.valueOf(new_value),
0``,
"C端"``,
null``);
}
}
public
void
addProductStockOpLogFallback(Long sku_id, Object old_value, Object new_value)
throws
Exception {
LOGGER.warn(``"发送商品库存变更消息失败,进入Fallback,skuId:{},oldValue:{},newValue:{}"``, sku_id, old_value, new_value);
}
|
示例:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
@HystrixCommand``(groupKey=``"UserGroup"``, commandKey =
"GetUserByIdCommand"``,
commandProperties = {
@HystrixProperty``(name =
"execution.isolation.thread.timeoutInMilliseconds"``, value =
"100"``),``//指定多久超时,单位毫秒。超时进fallback
@HystrixProperty``(name =
"circuitBreaker.requestVolumeThreshold"``, value =
"10"``),``//判断熔断的最少请求数,默认是10;只有在一个统计窗口内处理的请求数量达到这个阈值,才会进行熔断与否的判断
@HystrixProperty``(name =
"circuitBreaker.errorThresholdPercentage"``, value =
"10"``),``//判断熔断的阈值,默认值50,表示在一个统计窗口内有50%的请求处理失败,会触发熔断
},
threadPoolProperties = {
@HystrixProperty``(name =
"coreSize"``, value =
"30"``),
@HystrixProperty``(name =
"maxQueueSize"``, value =
"101"``),
@HystrixProperty``(name =
"keepAliveTimeMinutes"``, value =
"2"``),
@HystrixProperty``(name =
"queueSizeRejectionThreshold"``, value =
"15"``),
@HystrixProperty``(name =
"metrics.rollingStats.numBuckets"``, value =
"12"``),
@HystrixProperty``(name =
"metrics.rollingStats.timeInMilliseconds"``, value =
"1440"``)
})
|
说明: hystrix函数必须为public,fallback函数可以为private。两者需要返回值和参数相同 详情。
hystrix函数需要放在一个service中,并且,在类本身的其他函数中调用hystrix函数,是无法达到监控的目的的。