Hystrix使用的正确姿势
Posted 码农飞哥
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Hystrix使用的正确姿势相关的知识,希望对你有一定的参考价值。
前言
这一篇我们将重点介绍一下用Hystrix来做限流器以及服务隔离器。
工作流程
首先让我们看看官方文档上的工作流程图。
英文版的流程图看不懂,没关系,咱们还有中文版的工作流程图。
流程说明
每次调用创建一个新的HystrixCommand,把依赖调用封装在run()方法中。
执行execute()/queue()做同步或者异步调用
当前调用是否已被缓存,是的话则直接返回结果,否则进入步骤4。
判断熔断器(circuit-breaker)是否打开,如果打开跳到步骤8,进行降级策略,如果关闭进入步骤5。
判断线程池/队列/信号量是否跑满,如果跑满进入降级步骤8,否则继续后续步骤6。
调用HystrixCommand的run方法,运行依赖逻辑
6.1. 调用是否出现异常,否:继续,是:进入步骤8
6.2. 调用是否超时,否:返回调用结果,是进入步骤8。搜集5、6步骤所有的运行状态(成功,失败,拒绝,超时)上报给熔断器,用于判断统计从而判断熔断器状态。
getFallback()降级逻辑,四种触发getFallback调用情况,返回执行成功结果。
两种资源隔离模式
说完了Hystrix的工作机制之后,接下来,我们来看下Hystrix的两种资源隔离模式。
线程池隔离模式
使用一个线程池用来存储当前的请求,线程池对请求作处理,设置任务返回处理超时时间,堆积的请求堆积入线程池队列,这种方式需要为每个依赖的服务申请线程池,有一定的资源消耗,好处是可以应对突发流量。
信号量(Semaphore)隔离模式
使用一个原子计数器(或信号量)来记录当前有多少个线程正在运行,请求来先判断计数器的数值,若超过设置的最大线程个数则丢弃该类型的新请求,若不超过则执行计数操作请求,则计数器+1,请求返回计数器-1,无法处理突发流量。
下图展示了线程池隔离模式和信号量隔离模式的比较。
接下来就让我们来看看Hystrix的基本配置。Hystrix支持的配置有很多,主要就是Command相关的配置,熔断器相关的配置, 线程池相关的配置。很多配置都有默认值,我们可以合理的使用其默认值。
Hystrix的基本配置
HystrixCommand支持如下的配置:
GroupKey: 该命令属于哪一个组,可以帮助我们更好的组织命令。
CommandKey: 该命令的名称
ThreadPoolKey: 该命令所属线程池的名称,同样配置的命令会共享同一线程池,若不配置,会默认使用GroupKey作为线程池名称。
CommandProperties: 该命令的一些设置,包括断路器的配置,隔离策略,降级设置以及一些监控指标等。
ThreadPoolProerties:关于线程池的配置,包括线程池大小,排队队列的大小等。
Command配置
Command配置源码在HystrixCommandProperties,构造Command是通过Setter进行配置。
配置项 | 配置说明 | 默认值 |
---|---|---|
execution.isolation.strategy | 使用命令调用隔离方式 | 采用线程池隔离 ExecutionIsolationStrategy.THREAD |
execution.isolation.thread.timeoutInMilliseconds | 使用线程隔离时,调用超时时间 | 1秒 |
execution.timeout.enabled | 超时开关 | true |
execution.isolation.thread.interruptOnTimeout | 使用线程池隔离时,是否对命令执行超时 | true |
execution.isolation.semaphore.maxConcurrentRequests | 使用信号量隔离时,命令调用最大的并发数 | 10 |
fallback.isolation.semaphore.maxConcurrentRequests | 使用信号量隔离时,命令fallback(降级)调用最大的并发数 | 10 |
metrics.rollingStats.timeInMilliseconds | 统计滚动的时间窗口 | 5000 |
metrics.rollingStats.numBuckets | 统计窗口的Buckets的数量 | 10 |
metrics.rollingPercentile.enabled | 否开启监控统计功能 | true |
熔断器(Circuit Breaker)配置
Circuit Breaker配置源码在HystrixCommandProperties,构造Command时通过Setter进行配置,每种依赖使用一个CircuitBreaker
配置项 | 配置说明 | 默认值 |
---|---|---|
circuitBreaker.enabled | 是否启用熔断器 | true |
circuitBreaker.requestVolumeThreshold | 熔断器在整个统计时间内是否开启的阀值 | 默认20秒。也就是10秒钟内至少请求20次,熔断器才发挥起作用 |
circuitBreaker.sleepWindowInMilliseconds | 熔断器默认工作时间 | 5秒.熔断器中断请求5秒后会进入半打开状态,放部分流量过去重试 |
circuitBreaker.errorThresholdPercentage | 当出错率超过50%后熔断器启动 | 50% |
circuitBreaker.forceOpen | 是否强制开启熔断器阻断所有请求 | false |
circuitBreaker.forceClosed | 是否允许熔断器忽略错误 | false |
ThreadPool的配置
ThreadPool配置源码在HystrixThreadPoolProperties,构造ThreadPool是通过Setter方法进行配置的,具体配置解释和默认值如下:
配置项 | 配置说明 | 默认值 |
---|---|---|
coreSize | 核心线程数,请求高峰时99.5%的平均响应时间 + 向上预留一些即可 | 10 |
maximumSize | 最大线程数 | 10 |
keepAliveTimeMinutes | 线程的有效时长 | 1分钟 |
maxQueueSize | 配置线程池等待队列长度,默认值:-1,-1表示不等待直接拒绝,测试表明线程池使用直接拒绝测试+合适大小的非回缩线程池效率最高,所以不建议修改此值,当使用非回缩线程池时,queueSizeRejectionThreshold,keepAliveTimeMinutes 参数无效 | -1 |
小试牛刀
引入依赖
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
<version>2.0.0.RELEASE</version>
</dependency>
配置HystrixConfig
@Configuration
public class HystrixConfig {
@Bean
public HystrixCommandAspect hystrixCommandAspect() {
return new HystrixCommandAspect();
}
}
定义接口HystrixCommand
@Service
public class HelloService {
@HystrixCommand(
fallbackMethod = "helloError",
commandProperties = {
@HystrixProperty(name = "execution.isolation.strategy", value = "THREAD"),
@HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "1000"),
@HystrixProperty(name = "circuitBreaker.enabled", value = "true"),
@HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "2")
},
threadPoolProperties = {
@HystrixProperty(name = "coreSize", value = "5"),
@HystrixProperty(name = "maximumSize", value = "5"),
@HystrixProperty(name = "maxQueueSize", value = "10")
}
)
public String sayHello(String name) {
try {
Thread.sleep(5000);
return "Hello" + name + "!";
} catch (InterruptedException e) {
e.printStackTrace();
}
return null;
}
public String helloError(String name) {
return "服务器繁忙,请稍后访问!";
}
}
调用
@RestController
public class HelloController {
@Autowired
private HelloService helloService;
@GetMapping("/hystrixTest.do")
public String hystrixTest() {
return helloService.sayHello("项伟");
}
}
测试结果
总结
本文主要首先介绍了Hystrix的工作流程,然后介绍了Hystrix的两种隔离策略,主要是线程池的隔离策略以及信号量的隔离策略,默认的话是线程池的隔离策略,该策略可以应对突发流量。接着就是介绍了Hystrix的基本配置,其配置主要是通过@HystrixCommand
注解来配置的。配置按照功能划分有Command的配置,熔断器(circuitBreaker)的配置以及线程池(threadPool)的配置。最后就是通过一个简单的demo来实际使用Hystrix。
参考
微服务容错限流Hystrix入门
hystrix基本配置项(2)
以上是关于Hystrix使用的正确姿势的主要内容,如果未能解决你的问题,请参考以下文章