Hystrix熔断器
一种容错机制,处理出现错误时,自动熔断
1 、微服务中的雪崩效应
当山坡积雪内部的内聚力抗拒不了它所受到的重力拉引时,便向下滑动,引起大量雪体崩塌,人们把这种自然现象称作雪崩。
微服务中,一个请求可能需要多个微服务接口才能实现,会形成复杂的调用链路。
服务雪崩效应:是一种因“服务提供者的不可用”(原因)导致“服务调用者不可用”(结果),并将不可用逐渐放大的现象。
扇入:代表着该微服务被调用的次数,扇入大,说明该模块复用性好
扇出:该微服务调用其他微服务的个数,扇出大,说明业务逻辑复杂
扇入大是一个好事,扇出大不一定是好事
在微服务架构中,一个应用可能会有多个微服务组成,微服务之间的数据交互通过远程过程调用完成。这就带来一个问题,假设微服务A调用微服务B和微服务C,微服务B和微服务C又调用其它的微服务,这就是所谓的“扇出”。如果扇出的链路上某个微服务的调用响应时间过长或者不可用,对微服务A的调用就会占用越来越多的系统资源,进而引起系统崩溃,所谓的“雪崩效应”。
如图中所示,最下游商品微服务响应时间过长,大量请求阻塞,大量线程不会释放,会导致服务器资源耗尽,最终导致上游服务甚至整个系统瘫痪。
形成原因:
服务雪崩的过程可以分为三个阶段:
1. 服务提供者不可用
2. 重试加大请求流量
3. 服务调用者不可用
服务雪崩的每个阶段都可能由不同的原因造成:
2 、雪崩效应解决方案
从可用性可靠性着想,为防止系统的整体缓慢甚至崩溃,采用的技术手段;
下面,我们介绍三种技术手段应对微服务中的雪崩效应,这三种手段都是从系统可用性、可靠性角度出发,尽量防止系统整体缓慢甚至瘫痪。
服务熔断
熔断机制是应对雪崩效应的一种微服务链路保护机制。我们在各种场景下都会接触到熔断这两个字。高压电路中,如果某个地方的电压过高,熔断器就会熔断,对电路进行保护。股票交易中,如果股票指数过高,也会采用熔断机制,暂停股票的交易。同样,在微服务架构中,熔断机制也是起着类似的作用。当扇出链路的某个微服务不可用或者响应时间太长时,熔断该节点微服务的调用,进行服务的降级,快速返回错误的响应信息。当检测到该节点微服务调用响应正常后,恢复调用链路。
注意:
1)服务熔断重点在“断”,切断对下游服务的调用
2)服务熔断和服务降级往往是一起使用的,Hystrix就是这样。
服务降级
通俗讲就是整体资源不够用了,先将一些不关紧的服务停掉(调用我的时候,给你返回一个预留的·值,也叫做兜底数据),待渡过难关高峰过去,再把那些服务打开。
服务降级一般是从整体考虑,就是当某个服务熔断之后,服务器将不再被调用,此刻客户端可以自己准备一个本地的fallback回调,返回一个缺省值,这样做,虽然服务水平下降,但好歹可用,比直接挂掉要强。
服务限流
服务降级是当服务出问题或者影响到核心流程的性能时,暂时将服务屏蔽掉,待高峰或者问题解决后再打开;但是有些场景并不能用服务降级来解决,比如秒杀业务这样的核心功能,这个时候可以结合服务限流来限制这些场景的并发/请求量限流措施也很多,
比如:
- 限制总并发数(比如数据库连接池、线程池)
- 限制瞬时并发数(如nginx限制瞬时并发连接数)
限制时间窗口内的平均速率(如Guava的RateLimiter、nginx的limit_req模块,限制每秒的平均速率) - 限制远程接口调用速率、限制MQ的消费速率等
3、Hsytrix的简介
[来自官网]Hystrix(豪猪),宣言“defend your application”是由Netflix开源的一个延迟和容错库,用于隔离访问远程系统、服务或者第三方库,防止级联失败,从而提升系统的可用性与容错性。Hystrix主要通过以下几点实现延迟和容错。
包裹请求:使用HystrixCommand包裹对依赖的调用逻辑。 页面静态化微服务方法(@HystrixCommand 添加Hystrix控制)
跳闸机制:当某服务的错误率超过一定的阈值时,Hystrix可以跳闸,停止请求该服务一段时间。
资源隔离:Hystrix为每个依赖都维护了一个小型的线程池(舱壁模式)。如果该线程池已满, 发往该依赖的请求就被立即拒绝,而不是排队等待,从而加速失败判定。
监控:Hystrix可以近乎实时地监控运行指标和配置的变化,例如成功、失败、超时、以及被拒绝的请求等。
回退机制:当请求失败、超时、被拒绝,或当断路器打开时,执行回退逻辑。回退逻辑由开发人员自行提供,例如返回一个缺省值。
自我修复:断路器打开一段时间后,会自动进入“半开”状态(探测服务是否可用,如还是不可用,再次退回打开状态)。
4、Hystrix应用
4.1.熔断处理
目的:商品微服务长时间没有响应,服务消费者—>页面静态化微服务快速失败给用户提示
(1)引入依赖:服务消费者工程(静态化微服务)中引入Hystrix依赖坐标(也可以添加在父工程中)
<!--熔断器Hystrix-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency
(2)开启熔断:服务消费者工程(静态化微服务)的启动类中添加熔断器开启注解@EnableCircuitBreaker
@SpringBootApplication
//@EnableEurekaClient //表示以Eureka Client的身份在Eureka Server 中注册,
@EnableDiscoveryClient //表示可以向注册中心注册服务,不止在Eureka环境
//启用熔断器
@EnableCircuitBreaker
public class PageApplication {
public static void main(String[] args) {
SpringApplication.run(PageApplication.class, args);
}
// 诸如RestTemplate ,封装好的HttpClient
@Bean
@LoadBalanced //Ribbon负载均衡
public RestTemplate restTemplate() {
return new RestTemplate();
}
}
(3)商品微服务模拟超时操作,设置服务休眠时间为5秒
@RestController
@RequestMapping("/serve")
public class ServicePortInfo {
@Value("${server.port}")
private String serverPort;
@RequestMapping("/query")
public String findServerPort(){
//模拟超时
try {
Thread.sleep(5000);
} catch (InterruptedException e) {
e.printStackTrace();
}
return serverPort;
}
}
@RestController
@RequestMapping("/serve")
public class ServicePortInfo9001 {
@Value("${server.port}")
private String serverPort;
@RequestMapping("/query")
public String findServerPort(){
//模拟超时
try {
Thread.sleep(5000);
} catch (InterruptedException e) {
e.printStackTrace();
}
return serverPort;
}
}
(4)定义服务降级处理方法:业务方法上使用@HystrixCommand的fallbackMethod属性关联到服务降级处理方法,
设置超时时间为2秒,服务休眠时间为5秒,观察消费者调用服务时会不会出现熔断
threadPoolKey = “getProductServicePort2”,
//当前维护线程池的名字,默认所有的方法维护一个线程池,实际开发中每个方法维护一个线程池
//每一个属性对应一个threadPoolProperties
threadPoolProperties = {
@HystrixProperty(name = “coreSize”, value = “1”),//并发线程数,设置为1表示当有多个请求的时候,只支持一个连接,其余的进行等待
@HystrixProperty(name = “maxQueueSize”, value = “20”),//默认线程队列值为-1,即表示不开启
},
/**
* 模拟服务超时,哪个方法需要用到熔断就把HystrixCommand注解加在哪个方法上面
*
* 针对熔断服务,Hystrix会默认维护一个线程池,默认支持十个连接
* @return
*/
@HystrixCommand(
threadPoolKey = "getProductServicePort2", //当前维护线程池的名字,默认所有的方法维护一个线程池,实际开发中每个方法维护一个线程池
//每一个属性对应一个threadPoolProperties
threadPoolProperties = {
@HystrixProperty(name = "coreSize", value = "1"),//并发线程数,设置为1表示当有多个请求的时候,只支持一个连接,其余的进行等待
@HystrixProperty(name = "maxQueueSize", value = "20"),//默认线程队列值为-1,即表示不开启
},
//超时时间设置
commandProperties = {
@HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds",value = "2000")//设置超时时间为2000秒,超过休眠时间因此会出现熔断
}
)
@RequestMapping("/loadProductServicePort")
public String getProductServicePort2() {
ServiceInstance instance = discoveryClient.getInstances("lagou-service-product").get(0);
String host = instance.getHost();
int port = instance.getPort();
String url = "http://lagou-service-product/serve/query";
String serverPort = restTemplate.getForObject(url, String.class);
return serverPort;
}
超时异常
4.2降级处理
配置@HystrixCommand注解,定义降级处理方法
首先配置超时时间,在设置回退方法,就是出现熔断进行回退的方法
/**
* 服务降级,通常是在服务进行熔断之后进行一些自定义的处理
*
* @return
*/
@HystrixCommand(
//超时时间设置
commandProperties = {
@HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds",value = "2000")//超时时间为2000秒,超过休眠时间因此会出现熔断
},
//设置回退的方法
fallbackMethod = "getProductServerPortFailBack"
)
@RequestMapping("/loadProductServicePort3")
public String getProductServicePort3() {
ServiceInstance instance = discoveryClient.getInstances("lagou-service-product").get(0);
String host = instance.getHost();
int port = instance.getPort();
String url = "http://lagou-service-product/serve/query";
String serverPort = restTemplate.getForObject(url, String.class);
return serverPort;
}
//定义回退方法,当出现熔断的时候就采取补救措施,支持这个方法
//该方法要和原方法参数列表,返回值类型保持一致
public String getProductServerPortFailBack() {
return "-1";
}
未出现超时异常,返回-1,说明回退方法已经执行,服务降级生效
5、Hystrix舱壁模式
即:线程池隔离策略
如果不进行任何设置,所有熔断方法使用一个Hystrix线程池(10个线程),那么这样的话会导致问题,
这个问题并不是扇出链路微服务不可用导致的,而是我们的线程机制导致的,如果方法A的请求把10个
线程都用了,方法2请求处理的时候压根都没法去访问B,因为没有线程可用,并不是B服务不可用。
为了避免问题服务请求过多导致正常服务无法访问,Hystrix 不是采用增加线程数,而是单独的为每一个控制方法创建一个线程池的方式,这种模式叫做“舱壁模式",也是线程隔离的手段。
只要在@HystrixCommand中定义了threadPoolKey,就意味着开启了舱壁模式,自己会维护一个线程池,且threadPoolKey是该线程池的唯一标识,如果threadPoolKey与其他相同,说明两个方法共同维护一个线程池。
6、Hystrix工作流程与高级应用
1)当调用出现问题时,开启一个时间窗(10s)
2)在这个时间窗内,统计调用次数是否达到最小请求数?
如果没有达到,则重置统计信息,回到第1步
如果达到了,则统计失败的请求数占所有请求数的百分比,是否达到阈值?
如果达到,则跳闸(不再请求对应服务)
如果没有达到,则重置统计信息,回到第1步
3)如果跳闸,则会开启一个活动窗口(默认5s),每隔5s,Hystrix会让一个请求通过,到达那个问题服
务,看是否调用成功,如果成功,重置断路器回到第1步,如果失败,回到第3步
@HystrixCommand(
//超时时间设置
commandProperties = {
@HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds",value = "2000"),//超时时间为2000秒,超过休眠时间因此会出现熔断
/**
* 8秒钟内,请求次数达到2个,并且失败率在50%以上,就跳闸
* 跳闸后活动窗口设置为3s
*/
//统计窗口时间的设置
@HystrixProperty(name =
"metrics.rollingStats.timeInMilliseconds",value = "8000"),
//统计窗口内的最小请求数
@HystrixProperty(name =
"circuitBreaker.requestVolumeThreshold",value = "2"),
//统计窗口内错误请求阈值的设置 50%
@HystrixProperty(name =
"circuitBreaker.errorThresholdPercentage",value = "50"),
//自我修复的活动窗口时间
@HystrixProperty(name =
"circuitBreaker.sleepWindowInMilliseconds",value = "3000")
},
//设置回退的方法
fallbackMethod = "getProductServerPortFailBack"
)
@RequestMapping("/loadProductServicePort3")
public String getProductServicePort3() {
ServiceInstance instance = discoveryClient.getInstances("lagou-service-product").get(0);
String host = instance.getHost();
int port = instance.getPort();
String url = "http://lagou-service-product/serve/query";
String serverPort = restTemplate.getForObject(url, String.class);
return serverPort;
}
也可以在yml配置文件中配置
# 配置熔断策略:
hystrix:
command:
default:
circuitBreaker:
# 强制打开熔断器,如果该属性设置为true,强制断路器进入打开状态,将会拒绝所有的请求。
默认false关闭的
forceOpen: false
# 触发熔断错误比例阈值,默认值50%
errorThresholdPercentage: 50
# 熔断后休眠时长,默认值5秒
sleepWindowInMilliseconds: 3000
# 熔断触发最小请求次数,默认值是20
requestVolumeThreshold: 2
execution:
isolation:
thread:
# 熔断超时设置,默认为1秒
timeoutInMilliseconds: 2000
基于springboot的健康检查观察跳闸状态(自动投递微服务暴露健康检查细节)
# springboot中暴露健康检查等断点接口
management:
endpoints:
web:
exposure:
include: "*"
# 暴露健康接口的细节
endpoint:
health:
show-details: always
访问健康检查接口:http://localhost:9100/actuator/health
Hystrix 线程池队列配置案例:
有一次在生产环境,突然出现了很多笔还款单被挂起,后来排查原因,发现是内部系统调用时出现了Hystrix调用异常。在开发过程中,因为核心线程数设置的比较大,没有出现这种异常。放到了测试环境,偶尔有出现这种情况。
后来调整maxQueueSize属性,确实有所改善。可没想到在生产环境跑了一段时间后却又出现这种情况,此时我第一想法就是去查看maxQueueSize属性,可是maxQueueSize属性是设置值了。
当时就比较纳闷了,为什么maxQueueSize属性不起作用,后来通过查看官方文档发现Hystrix还有一个queueSizeRejectionThreshold属性,这个属性是控制队列最大阈值的,而Hystrix默认只配置了5个,因此就算我们把maxQueueSize的值设置再大,也是不起作用的。两个属性必须同时配置
hystrix:
threadpool:
default:
coreSize: 10 #并发执行的最大线程数,默认10
maxQueueSize: 1000 #BlockingQueue的最大队列数,默认值-1
queueSizeRejectionThreshold: 800 #即使maxQueueSize没有达到,达到queueSizeRejectionThreshold该值后,请求也会被拒绝,默认值5
coreSize尽量与电脑CPU数量保持一致,这样性能最强