Spring-Cloud组件之断路器Hystrix
雪崩效应
我们先来看一下这个图,意思就是现在我们有很多微服务,并且我们是一条微服务调用链。然后这里我们的微服务H出意外了(服务器宕机、机房停电了、代码出bug、流量剧增、缓存穿透、数据库连接中断等等诸多原因,统称为意外),就导致整条调用链失效了,就是页面还一直在请求微服务A,然后A一直调用E,E又一直调用H,H这儿又出意外了,走不动了。然后就一直卡在这儿,卡呀卡呀,就发现整个服务的资源耗尽,从而导致了服务器崩溃了,这就是传说中的服务雪崩。
如何处理雪崩?
这个就没啥好说的了,程序bug那就改Bug咯,服务器宕机、机房停电了整个就要多准备多机房咯,流量剧增就要做好服务自动扩容和限流…其他就不一一解释了,总之出现问题都有对应的处理方式,但是我们为什么要先说到雪崩呢?因为我们今天要写的就是一个超级神奇的东西,可以让我们的服务拥有自我保护的能力,然后从容解决雪崩问题。接下来我们看看吧…
hystrix是什么?
Hystrix是一个用于处理分布式系统的延迟和容错的开源库,在分布式系统里,许多依赖不可避免的会调用失败,比如超时、异常等,Hystrix能够保证在一个依赖出问题的情况下,不会导致整体服务失败,避免级联故障,以提高分布式系统的弹性。
“断路器”本身是一种开关装置,当某个服务单元发生故障之后,通过断路器的故障监控(类似熔断保险丝),向调用方返回一个符合预期的、可处理的备选响应(FallBack),而不是长时间的等待或者抛出调用方无法处理的异常,这样就保证了服务调用方的线程不会被长时间、不必要地占用,从而避免了故障在分布式系统中的蔓延,乃至雪崩。
hystrix常用的功能
降级回退:
何为降级?就是我们的某一个微服务不可用了或则响应时间太长了,说白了就是那个微服务用不了了,不能将错误信息正常返回出来,然后就一直卡在那里动不了了,那我们就需要一个策略来解决这个问题,也就是我们需要自定义一个方法,如果出现这个问题了我们就直接去调用我们自定义的这个方法,达到快速返回请求结果,不让他一直卡在那里。
这里有一个问题,就是我们这个自定义方法是写在调用方还是服务提供方?其实仔细想想就能知道了,肯定是调用方,举一个例子,如果我们的自定义方法卸载服务提供方,但是这个服务提供方直接挂掉了,那怎么转到自定义方法呢?所以我们做降级是在这个服务调用方的。还是接着前面的项目来讲解,我们前面的项目是user调用power的,所以我们是在user这边做降级处理。
先引进maven依赖:user的pom.xml
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.0.2.RELEASE</version>
</parent>
<modelVersion>4.0.0</modelVersion>
<artifactId>user</artifactId>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-openfeign</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>fastjson</artifactId>
<version>1.2.17</version>
</dependency>
</dependencies>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>Finchley.SR2</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
</project>
接着就是启动类了:加上@EnableHystrix注解
@SpringBootApplication
@EnableEurekaClient
@EnableFeignClients
@EnableHystrix
@RibbonClients({
@RibbonClient(name = "SERVER-POWER",configuration = PowerRuleConfig.class),
@RibbonClient(name = "SERVER-ORDER",configuration = OrderRuleConfig.class),
})
public class UserApplication {
public static void main(String[] args) {
SpringApplication.run(UserApplication.class);
}
}
然后在service这边再添加两个接口,这里的接口地址你先这样写,后面我们在去改:
@FeignClient("SERVER-POWER")
public interface PowerServiceClinet {
@RequestMapping(value = "/getPower.do")
public Object power();
@RequestMapping(value = "/getErrorPower.do")
public Object errorPower();
@RequestMapping(value = "/getTimeOutPower.do")
public Object timeoutPower();
}
接着更改controller:
@RestController
public class UserController {
private final static String POWER_URL="http://SERVER-POWER";
private final static String ORDER_URL="http://SERVER-ORDER";
@Autowired
private RestTemplate restTemplate;
@Autowired
private OrderServiceClinet orderServiceClinet;
@Autowired
private PowerServiceClinet powerServiceClinet;
@RequestMapping("/getUser")
public Object getUser(){
Map<String,Object> map = new HashMap<>();
map.put("key","user");
return map;
}
@RequestMapping("/getPower")
public Object getPower(){
return restTemplate.getForObject(POWER_URL+"/getPower.do",Object.class);
}
@RequestMapping("/getOrder")
public Object getOrder(){
return restTemplate.getForObject(ORDER_URL+"/getOrder.do",Object.class);
}
@RequestMapping("/getFeignPower")
public Object getFeignPower(String name){
return powerServiceClinet.power();//返回异常
}
/**
* 降级
* @param name
* @return
*/
@RequestMapping("/getFeignErrorPower")
@HystrixCommand(fallbackMethod = "fallbackMethod")
public Object getFeignErrorPower(String name){
return powerServiceClinet.errorPower();//返回异常
}
/**
* 超时
* @param name
* @return
*/
@RequestMapping("/getFeignTimeoutPower")
@HystrixCommand(fallbackMethod = "fallbackMethod")
public Object getFeignTimeoutPower(String name){
return powerServiceClinet.timeoutPower();//超时
}
@RequestMapping("/getFeignOrder")
public Object getFeignOrder(){
return orderServiceClinet.order();
}
public String fallbackMethod(String name){
System.out.println(name);
return new Result().errorMsg("降级信息");
}
}
这里要看一下,我们写了一个fallbackMethod方法,并且新加了两个接口调用的方法,并且加了@HystrixCommand注解,然后还定义了fallbackMethod的值,大概意思呢就是声明这个方法需要做降级处理,然后如果timeoutPower和errorPower那边出现问题后(响应超时和抛出异常)然后就需要走我们自定义的fallbackMethod方法来达到快速返回的效果。
服务调用方就这样写完了,我们为了看到效果,所以我们去power那边故意弄一点毛病出来,毕竟是为了学习嘛,要看到效果才行,只有看到效果我们才知道为啥要这样做了,学这个是为了干啥。
接下来改一下power的controller:
@RestController
public class PowerController {
@RequestMapping("/getPower.do")
public Object getPower(String name){
Map<String,Object> map = new HashMap<>();
map.put("key","power");
return map;
}
@RequestMapping("/getErrorPower.do")
public Object getErrorPower(String name){
Map<String,Object> map = new HashMap<>();
map.put("key","power");
if(name == null)
throw new NullPointerException();
return map;
}
@RequestMapping("/getTimeOutPower.do")
public Object getTimeOutPower(String name) throws InterruptedException {
Map<String,Object> map = new HashMap<>();
map.put("key","power");
Thread.sleep(2000);
return map;
}
}
这里就是我们故意定一个错,和故意定一个超时的效果。
好了,我们启动一下eureka3000,power,power1,user。
我们访问 http://localhost:6001/getFeignErrorPower 和http://localhost:6001/getFeignTimeoutPower 都会返回下面的结果
这个就是降级的效果了,就是我们想要调用的微服务出现问题了,但是我们还是能够达到快速返回结果的效果,避免项目卡死。
这里你可能有疑问,为什么线程睡眠2s就会走这个降级,这是因为我们hystrix的默认配置导致的,这里可以多看看hystrix官网,里面拥有详细的配置参数,当然我也会把所有的配置都记录在博客最下方。
这里先解释一下这个2s就会降级:
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds,默认值为1000(单位ms)。就是这个原因导致我们休眠2s就会走降级回退了。这个在实际项目开发的时候,可以根据自己项目的接口正常响应时间来设置的。
熔断
什么是熔断呢?你们知道跳闸吗?就是我们家里用电的时候,因为电路故障了,为了防止出现大型事故,这里就会直接跳闸切断电源避免大型事故继续发生。在这里我们的熔断也是如此,当一个微服务多次调用出现问题时(默认配置文件是10s内20次失败),hystrix就会采取熔断机制,开启之后就会直接调用降级方法了。但是这里有一个问题,就是 我理解为半关状态,什么意思呢?就是hystrix启用熔断机制后,每过5s就会试探性的关闭熔断机制,然后如果再失败1次,就又开启熔断机制,如果成功后,这个熔断机制就继续关闭了。
这个用文字实在是不好解释,这样吧,写一个例子,然后大家自己多测试一下。
这里有两个配置文件:
hystrix.command.default.metrics.rollingStats.timeInMilliseconds 默认值10000(单位毫秒)这个就是上面的 10s
hystrix.command.default.circuitBreaker.requestVolumeThreshold 默认值为20。这里就是上面的 20次。
先来写一下代码吧:还是改user项目
application.yml 在最后面加上这个
hystrix:
command:
default:
circuitBreaker:
requestVolumeThreshold: 5 #10s失败5次就会开启熔断机制
UserController加一个方法:
/**
* 测试熔断机制
* @return
*/
@RequestMapping("/getErrorPower")
@HystrixCommand(fallbackMethod = "fallbackMethod")
public Object getErrorPower(String name){
System.out.println("调用方法");
return restTemplate.getForObject(POWER_URL+"/getErrorPower.do",Object.class);
}
然后运行项目吧,我们设置的是10s5次失败就会启用熔断机制。这个我就不详细说了,自己要去跑一把就知道了。
我们一直访问这个接口地址,然后控制台打印5次 "调用方法 " 后,后面就是5s打印一次了。意思就是,前面五次失败了然后hystrix启用了熔断机制,后面每隔5s会关闭一次熔断机制进行试探,如果还是失败,那么就继续开启熔断机制。
限流
限流,可以理解为限制某一个微服务的使用量吧。
hystrix是通过线程池的方式来管理微服务调用的。他默认是一个线程池(10线程池大小)来管理所有微服务,我们也可以自己给某个微服务开辟新的线程池。
先讲解第一种配置方式:
application.yml 在最后面加上这个,注意和熔断那里有一样的,所以只需要添加 execution后面的就可以了
hystrix:
command:
default:
circuitBreaker:
requestVolumeThreshold: 5 #10s失败5次就会开启熔断机制
execution:
isolation:
thread:
timeoutInMilliseconds: 30000 #默认值为1000(单位ms) 响应时间超过多少后就降级回退
UserController加一个方法:
/**
* 测试限流
* @return
* fallbackMethod 降级回退需要走的方法
* threadPoolKey 就是在线程池唯一标识
* threadPoolProperties 定义线程池
* coreSize 能同时执行的线程数
* maxQueueSize 队列个数
*/
@RequestMapping("/getTimeOutPower")
@HystrixCommand(fallbackMethod = "fallbackMethod",threadPoolKey = "power",
threadPoolProperties ={@HystrixProperty(name = "coreSize",value = "2")
,@HystrixProperty(name = "maxQueueSize",value = "1")})
public Object getTimeOutPower(String name){
System.out.println("调用方法");
return restTemplate.getForObject(POWER_URL+"/getTimeOutPower.do",Object.class);
}
这里参数的解释也在注释里面写了,稍微看一下。最终的效果就是能够同时运行两个线程,然后队列里面可以存放一个,也就是能同时运行两个线程然后一个在排队。
这里为了看到我们的效果,改一下PowerController 的getTimeOutPower方法 ,让其休眠20s
@RequestMapping("/getTimeOutPower.do")
public Object getTimeOutPower(String name) throws InterruptedException {
Map<String,Object> map = new HashMap<>();
map.put("key","power");
Thread.sleep(20000);
return map;
}
好了 启动一下,我们可以发现,当我们访问第四次http://localhost:6001/getTimeOutPower的时候,返回的就是
然后我们等20s请求如下:
证明又能有一个线程进去了。就是线程释放后又能进一个,超过后就会返回降级信息了。这个就是限流,限制微服务访问的线程数。
现在我们来试试第二种限流的玩法:
application.yml 在最后面加上这个,注意和前面一样的
hystrix:
command:
default:
circuitBreaker:
requestVolumeThreshold: 5 #10s失败5次就会开启熔断机制
execution:
isolation:
thread:
timeoutInMilliseconds: 30000 #默认值为1000(单位ms) 响应时间超过多少后就降级回退
threadpool:
power:
coreSize: 2 #最大线程数
maxQueueSize: 1 #最大对列数
然后吧UserController中getTimeOutPower改一下:
/**
* 测试限流
* @return
* fallbackMethod 降级回退需要走的方法
* threadPoolKey 就是在线程池唯一标识
* threadPoolProperties 定义线程池
* coreSize 能同时执行的线程数
* maxQueueSize 队列个数
*/
@RequestMapping("/getTimeOutPower")
@HystrixCommand(fallbackMethod = "fallbackMethod",threadPoolKey = "power")
public Object getTimeOutPower(String name){
System.out.println("调用方法");
return restTemplate.getForObject(POWER_URL+"/getTimeOutPower.do",Object.class);
}
这里注意一下,就是我们定义了线程池名字为order 所以在配置文件threadpool后面要写power,默认的写法是:hystrix.threadpool.default.coreSize 默认值为10 我们就是把这个default换成我们自定义的线程池名称就可以了。
然后启动一下,效果跟我们直接用注解的形式写是一样的。
这就是hystrix的限流。
feign整合hystrix:
首先改一下application.yml,在后面加上
feign:
hystrix:
enabled: true
然后新建一个PowerServiceFallback类实现PowerServiceClinet接口:
@Component //交给spring管理
public class PowerServiceFallback implements PowerServiceClinet {
@Override
public Object power() {
return new Result().errorMsg("测试降级");
}
@Override
public Object errorPower() {
return new Result().errorMsg("异常降级");
}
@Override
public Object timeoutPower() {
return new Result().errorMsg("超时降级");
}
}
再改一下UserController的getFeignErrorPower方法:
/**
* 降级
* @param name
* @return
*/
@RequestMapping("/getFeignErrorPower")
@HystrixCommand()
public Object getFeignErrorPower(String name){
return powerServiceClinet.errorPower();//返回异常
}
我们改一下power这边的powerController
@RequestMapping("/getErrorPower.do")
public Object getErrorPower(String name){
System.out.println("调用power方法 getErrorPower");
Map<String,Object> map = new HashMap<>();
map.put("key","power");
if(name == null)
throw new NullPointerException();
return map;
}
这样就差不多可以了。我们来访问一下。配置文件还是前面的,就是10s5次全失败就会熔断,这里有点不一样,所以要注意下。
启动一下,访问http://localhost:6001/getFeignErrorPower
返回结果如下:
但是要注意一下控制台打印,就是打印五次"调用power方法 getErrorPower"后就会出现五秒在打印一次了。这就证明我们成功熔断了。
还有一点,就是我们可能还需要拿到实际的异常,那我们就可以这样来做:
在user项目中新建一个PowerServiceClientFallBackFactory类 实现FallbackFactory接口
@Component
public class PowerServiceClientFallBackFactory implements FallbackFactory<PowerServiceClinet> {
@Override
public PowerServiceClinet create(Throwable throwable) {
return new PowerServiceClinet() {
@Override
public Object power() {
return null;
}
@Override
public Object errorPower() {
String message = throwable.getMessage();
System.out.println("我们收到的异常如下:"+message);
return new Result().errorMsg("feign降级");
}
@Override
public Object timeoutPower() {
return null;
}
};
}
}
在改一下 PowerServiceClinet接口:
@FeignClient(value = "SERVER-POWER",fallbackFactory = PowerServiceClientFallBackFactory.class)
public interface PowerServiceClinet {
@RequestMapping(value = "/getPower.do")
public Object power();
@RequestMapping(value = "/getErrorPower.do")
public Object errorPower();
@RequestMapping(value = "/getTimeOutPower.do")
public Object timeoutPower();
}
我们在启动一下,就可以看到控制台打印了:
是吧,我们就能拿到实际的错误信息了。然后就可以做相应的处理了。
hystrix的一些基本配置:
Execution相关的属性的配置:
hystrix.command.default.execution.isolation.strategy 隔离策略,默认是Thread, 可选Thread| Semaphor
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds 命令执行超时时 间,默认1000ms
hystrix.command.default.execution.timeout.enabled 执行是否启用超时,默认启用true
hystrix.command.default.execution.isolation.thread.interruptOnTimeout 发生超时是是否中断, 默认true
hystrix.command.default.execution.isolation.semaphore.maxConcurrentRequests 最大并发请求 数,默认10,该参数当使用ExecutionIsolationStrategy.SEMAPHORE策略时才有效。如果达到最大并发请求 数,请求会被拒绝。理论上选择semaphore size的原则和选择thread size一致,但选用semaphore时每次执行 的单元要比较小且执行速度快(ms级别),否则的话应该用thread。 semaphore应该占整个容器(tomcat)的线程池的一小部分。 Fallback相关的属性 这些参数可以应用于Hystrix的THREAD和SEMAPHORE策略
hystrix.command.default.fallback.isolation.semaphore.maxConcurrentRequests 如果并发数达到 该设置值,请求会被拒绝和抛出异常并且fallback不会被调用。默认10
hystrix.command.default.fallback.enabled 当执行失败或者请求被拒绝,是否会尝试调用
hystrixCommand.getFallback() 。默认true
Circuit Breaker相关的属性的配置:
hystrix.command.default.circuitBreaker.enabled 用来跟踪circuit的健康性,如果未达标则让request短路。默认true
hystrix.command.default.circuitBreaker.requestVolumeThreshold 一个rolling window内最小的请 求数。如果设为20,那么当一个rolling window的时间内(比如说1个rolling window是10秒)收到19个请求, 即使19个请求都失败,也不会触发circuit break。默认20
hystrix.command.default.circuitBreaker.sleepWindowInMilliseconds 触发短路的时间值,当该值设 为5000时,则当触发circuit break后的5000毫秒内都会拒绝request,也就是5000毫秒后才会关闭circuit。 默认5000
hystrix.command.default.circuitBreaker.errorThresholdPercentage错误比率阀值,如果错误率>=该 值,circuit会被打开,并短路所有请求触发fallback。默认50
hystrix.command.default.circuitBreaker.forceOpen 强制打开熔断器,如果打开这个开关,那么拒绝所 有request,默认false
hystrix.command.default.circuitBreaker.forceClosed 强制关闭熔断器 如果这个开关打开,circuit将 一直关闭且忽略circuitBreaker.errorThresholdPercentage
Metrics相关的属性的配置:
hystrix.command.default.metrics.rollingStats.timeInMilliseconds 设置统计的时间窗口值的,毫秒 值,circuit break 的打开会根据1个rolling window的统计来计算。若rolling window被设为10000毫秒, 则rolling window会被分成n个buckets,每个bucket包含success,failure,timeout,rejection的次数 的统计信息。默认10000
hystrix.command.default.metrics.rollingStats.numBuckets 设置一个rolling window被划分的数 量,若numBuckets=10,rolling window=10000,那么一个bucket的时间即1秒。必须符合rolling window % numberBuckets == 0。默认10
hystrix.command.default.metrics.rollingPercentile.enabled 执行时是否enable指标的计算和跟踪, 默认true
hystrix.command.default.metrics.rollingPercentile.timeInMilliseconds 设置rolling percentile window的时间,默认60000
hystrix.command.default.metrics.rollingPercentile.numBuckets 设置rolling percentile window的numberBuckets。逻辑同上。默认6
hystrix.command.default.metrics.rollingPercentile.bucketSize 如果bucket size=100,window =10s,若这10s里有500次执行,只有最后100次执行会被统计到bucket里去。增加该值会增加内存开销以及排序 的开销。默认100
hystrix.command.default.metrics.healthSnapshot.intervalInMilliseconds 记录health 快照(用 来统计成功和错误绿)的间隔,默认500ms
Request Context 相关参数的配置:
hystrix.command.default.requestCache.enabled 默认true,需要重载getCacheKey(),返回null时不 缓存
hystrix.command.default.requestLog.enabled 记录日志到HystrixRequestLog,默认true
Collapser Properties 相关参数的配置:
hystrix.collapser.default.maxRequestsInBatch 单次批处理的最大请求数,达到该数量触发批处理,默认 Integer.MAX_VALU
hystrix.collapser.default.timerDelayInMilliseconds 触发批处理的延迟,也可以为创建批处理的时间 +该值,默认10
hystrix.collapser.default.requestCache.enabled 是否对HystrixCollapser.execute() and HystrixCollapser.queue()的cache,默认true
ThreadPool 相关参数的配置:
线程数默认值10适用于大部分情况(有时可以设置得更小),如果需要设置得更大,那有个基本得公式可以 follow: requests per second at peak when healthy × 99th percentile latency in seconds + some breathing room 每秒最大支撑的请求数 (99%平均响应时间 + 缓存值) 比如:每秒能处理1000个请求,99%的请求响应时间是60ms,那么公式是: 1000 (0.060+0.012)
基本得原则时保持线程池尽可能小,他主要是为了释放压力,防止资源被阻塞。 当一切都是正常的时候,线程池一般仅会有1到2个线程激活来提供服务
hystrix.threadpool.default.coreSize 并发执行的最大线程数,默认10
hystrix.threadpool.default.maxQueueSize BlockingQueue的最大队列数,当设为-1,会使用
SynchronousQueue,值为正时使用LinkedBlcokingQueue。该设置只会在初始化时有效,之后不能修改threadpool的queue size,除非reinitialising thread executor。默认-1。
hystrix.threadpool.default.queueSizeRejectionThreshold 即使maxQueueSize没有达到,达到 queueSizeRejectionThreshold该值后,请求也会被拒绝。因为maxQueueSize不能被动态修改,这个参数将允 许我们动态设置该值。if maxQueueSize == ¬1,该字段将不起作用 hystrix.threadpool.default.keepAliveTimeMinutes 如果corePoolSize和maxPoolSize设成一样(默认 实现)该设置无效。如果通过plugin(https://github.com/Netflix/Hystrix/wiki/Plugins)使用自定义 实现,该设置才有用,默认1.
hystrix.threadpool.default.metrics.rollingStats.timeInMilliseconds 线程池统计指标的时间,默 认10000
hystrix.threadpool.default.metrics.rollingStats.numBuckets 将rolling window划分为n个 buckets,默认10
这些都是从官网搞下来的参数配置,对于hystrix,我感觉还是要自己多去测试,像这些配置参数,都得一个一个的试才知道具体是干啥的,这些配置参数我感觉不需要背的吧,只要我们知道在哪里能够看到如何配置的就行。
好吧,今天算是写完了,这一篇文章感觉有点差劲,因为这个hystrix很多东西不知道该怎么写出来,所以抱歉啦。