本文目录
1.微服务中的雪崩效应
在微服务架构中,⼀个应⽤可能会有多个微服务组成,微服务之间的数据交互通过 远程过程调⽤完成。这就带来⼀个问题,假设微服务A调⽤微服务B和微服务C,微 服务B和微服务C⼜调⽤其它的微服务,这就是所谓的“扇出”。如果扇出的链路上某 个微服务的调⽤响应时间过⻓或者不可⽤,对微服务A的调⽤就会占⽤越来越多的系 统资源,进⽽引起系统崩溃,所谓的“雪崩效应”。
1.2 雪崩效应解决方案
从可⽤性可靠性着想,为防⽌系统的整体缓慢甚⾄崩溃,采⽤的技术⼿段; 下⾯,我们介绍三种技术⼿段应对微服务中的雪崩效应,这三种⼿段都是从系统可 ⽤性、可靠性⻆度出发,尽量防⽌系统整体缓慢甚⾄瘫痪。
-
服务熔断
熔断机制是应对雪崩效应的⼀种微服务链路保护机制。我们在各种场景下都会接触 到熔断这两个字。⾼压电路中,如果某个地⽅的电压过⾼,熔断器就会熔断,对电 路进⾏保护。股票交易中,如果股票指数过⾼,也会采⽤熔断机制,暂停股票的交 易。同样,在微服务架构中,熔断机制也是起着类似的作⽤。当扇出链路的某个微 服务不可⽤或者响应时间太⻓时,熔断该节点微服务的调⽤,进⾏服务的降级,快 速返回错误的响应信息。当检测到该节点微服务调⽤响应正常后,恢复调⽤链路。
注意:
1)服务熔断重点在“断”,切断对下游服务的调⽤
2)服务熔断和服务降级往往是⼀起使⽤的,Hystrix就是这样
-
服务降级
通俗讲就是整体资源不够⽤了,先将⼀些不关紧的服务停掉(调⽤我的时候,给你 返回⼀个预留的值,也叫做兜底数据),待渡过难关⾼峰过去,再把那些服务打 开。
服务降级⼀般是从整体考虑,就是当某个服务熔断之后,服务器将不再被调⽤,此 刻客户端可以⾃⼰准备⼀个本地的fallback回调,返回⼀个缺省值,这样做,虽然服 务⽔平下降,但好⽍可⽤,⽐直接挂掉要强。
-
服务限流
服务降级是当服务出问题或者影响到核⼼流程的性能时,暂时将服务屏蔽掉,待⾼ 峰或者问题解决后再打开;但是有些场景并不能⽤服务降级来解决,⽐如秒杀业务 这样的核⼼功能,这个时候可以结合服务限流来限制这些场景的并发/请求量。限流措施也很多,⽐如:
- 限制总并发数(⽐如数据库连接池、线程池);
- 限制瞬时并发数(如nginx限制瞬时并发连接数);
- 限制时间窗⼝内的平均速率(如Guava的RateLimiter、nginx的limit_req模块, 限制每秒的平均速率);
- 限制远程接⼝调⽤速率、限制MQ的消费速率等。
2. Hystrix
2.1 Hystrix介绍
Hystrix是Netflix开源的⼀个 延迟和容错库,⽤于隔离访问远程系统、服务或者第三⽅库,防⽌级联失败,从⽽ 提升系统的可⽤性与容错性。Hystrix主要通过以下⼏点实现延迟和容错:
- 包裹请求:使⽤
@HystrixCommand
包裹对依赖的调⽤逻辑。 - 跳闸机制:当某服务的错误率超过⼀定的阈值时,
Hystrix
可以跳闸,停⽌请求 该服务⼀段时间。 - 资源隔离:
Hystrix
为每个依赖都维护了⼀个⼩型的线程池(舱壁模式)(或者信号 量)。如果该线程池已满, 发往该依赖的请求就被⽴即拒绝,⽽不是排队等 待,从⽽加速失败判定。 - 监控:Hystrix可以近乎实时地监控运⾏指标和配置的变化,例如成功、失败、 超时、以及被拒绝 的请求等
- 回退机制:当请求失败、超时、被拒绝,或当断路器打开时,执⾏回退逻辑。回 退逻辑由开发⼈员 ⾃⾏提供,例如返回⼀个缺省值。
- ⾃我修复:断路器打开⼀段时间后,会⾃动进⼊“半开”状态。
2.2 Hystrix现状
Hystrix已经停止更新,目前处于维护阶段。最后的版本是1.5.8
https://github.com/Netflix/Hystrix。
2.3 Hystrix快速开始
2.3.1 引⼊Hystrix依赖坐标
服务消费者⼯程中引⼊Hystrix依赖坐标
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
<version>2.2.9.RELEASE</version>
</dependency>
2.3.2启动类开启熔断器
服务消费者⼯程的启动类中添加熔断器开启注解
@SpringBootApplication
@EnableDiscoveryClient
@LoadBalancerClients(defaultConfiguration = {CustomLoadBalancerConfiguration.class})
@EnableHystrix //开启Hystrix
public class AutoDeliverApplication {
//----------------省略其他代码----------------
}
2.3.3 @HystrixCommand
定义服务降级处理⽅法
@HystrixCommand(
commandProperties = {
@HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds",value = "5000")
},
fallbackMethod = "myFallbackMethod"
)
@GetMapping("/testLoadBalanced")
public Integer testLoadBalanced(){
String url="http://demo-service-user/user/getPort";
Integer forObject = restTemplate.getForObject(url, Integer.class);
log.info("=============>>>调用的服务端:"+forObject);
return forObject;
}
/**
* 定义fallbackMethod方法
* @return
*/
public Integer myFallbackMethod(){
return -1;
}
属性说明:
-
commandProperties
熔断的⼀些细节属性配置@HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds",value = "5000")
方法调用超时时间,默认1000毫秒。execution.timeout.enabled:
是否开启超时,默认是true
commandProperties
默认配置在:com.netflix.hystrix.HystrixCommandProperties
类中 -
fallbackMethod = "myFallbackMethod"
方法调用超时后的回退方法。
2.4 Hystrix线程池隔离策略
2.4.1 Hystrix默认线程策略
Hystrix默认有一个大小为10线程池,为所有添加了@HystrixCommand
注解的方法提供线程,如果这些方法接收的请求超过10个,其他请求就得等待或者拒绝链接请求:
如果不进⾏任何设置,所有熔断⽅法使⽤⼀个Hystrix线程池(10个线程),那么这 样的话会导致问题,这个问题并不是链路微服务不可⽤导致的,⽽是我们的线 程机制导致的,如果⽅法A的请求把10个线程都⽤了,⽅法2请求处理的时候压根都 没法去访问B,因为没有线程可⽤,并不是B服务不可⽤。
2.4.2. 配置 Hystrix线程策略
为了避免问题服务请求过多导致正常服务⽆法访问,Hystrix 不是采⽤增加线程数, ⽽是单独的为每⼀个控制⽅法创建⼀个线程池的⽅式,这种模式叫做“舱壁模式",也 是线程隔离的⼿段。
@HystrixCommand(
commandProperties = {
@HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds",value = "5000"),
@HystrixProperty(name = "execution.timeout.enabled", value = "false")
},
fallbackMethod = "myFallbackMethod",
// 线程池标识,要保持唯⼀,不唯⼀的话就共⽤了
threadPoolKey = "testLoadBalanced",
threadPoolProperties = {
@HystrixProperty(name="coreSize",value = "10"),// 核心线程数,默认为10
@HystrixProperty(name="maxQueueSize",value="20") // 等待队列⻓度
}
)
@GetMapping("/testLoadBalanced")
public Integer testLoadBalanced(){
String url="http://yyq-service-resume/resume/getPort";
Integer forObject = restTemplate.getForObject(url, Integer.class);
log.info("=============>>>调用的服务端:"+forObject);
return forObject;
}
属性说明:
-
threadPoolKey = "testLoadBalanced",
线程池标识,要保持唯⼀,不唯⼀的话就共⽤了线程池 -
threadPoolProperties
线程池属性配置@HystrixProperty(name="coreSize",value = "10")
,// 核心线程数,默认为10@HystrixProperty(name="maxQueueSize",value="20")
// 等待队列⻓度,默认为-1,表示不限制队列长度
threadPoolProperties
默认配置在:com.netflix.hystrix.HystrixThreadPoolProperties
类
2.5 Hystrix熔断机制
- 当调⽤出现问题时,开启⼀个时间窗(10s)
- 在这个时间窗内,统计调⽤次数是否达到最⼩请求数?
- 2.1 如果没有达到,则重置统计信息,回到第1步
- 2.2 如果达到了,则统计失败的请求数占所有请求数的百分⽐,是否达到阈值
- 如果达到,则跳闸(不再请求对应服务)
- 如果没有达到,则重置统计信息,回到第1步
- 如果跳闸,则会开启⼀个活动窗⼝(默认5s),每隔5s,Hystrix会让⼀个请求 通过,到达那个问题服务,看 是否调⽤成功,如果成功,重置断路器回到第1步,如 果失败,回到第3步
熔断机制局部配置
以下配置的意思是: 8秒钟内,请求次数达到2个,并且失败率在50%以上,就熔断,熔断后休眠3秒,然后重试
@HystrixCommand(
commandProperties = {
//熔断活动窗口时长,默认为1分钟
@HystrixProperty(name =
"metrics.rollingStats.timeInMilliseconds",value = "8000"),
// 熔断触发最⼩请求次数,默认值是20
@HystrixProperty(name =
"circuitBreaker.requestVolumeThreshold",value = "2"),
// 触发熔断错误⽐例阈值,默认值50%
@HystrixProperty(name =
"circuitBreaker.errorThresholdPercentage",value = "50"),
//熔断后休眠多久,然后重试
@HystrixProperty(name =
"circuitBreaker.sleepWindowInMilliseconds",value = "3000")
},
//------------------省略其他代码------------------------
)
在配置文件中全局配置熔断机制:
#配置熔断策略:
hystrix:
command:
default:
circuitBreaker:
#强制打开熔断器,如果该属性设置为true,强制断路器进⼊打开状态,将会拒绝所有的请求。 默认false关闭的
forceOpen: false
# 触发熔断错误⽐例阈值,默认值50%
errorThresholdPercentage: 50
# 熔断后休眠时⻓,默认值5秒
sleepWindowInMilliseconds: 3000
# 熔断触发最⼩请求次数,默认值是20
requestVolumeThreshold: 2
execution:
isolation:
thread:
# 熔断超时设置,默认为1分钟
timeoutInMilliseconds: 2000
2.6 基于springboot的健康检查观察熔断状态
-
引入依赖
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency>
-
添加配置
# springboot中暴露健康检查等断点接口 management: endpoints: web: exposure: include: "*" # 暴露健康接口的细节 endpoint: health: show-details: always
访问地址:http://localhost:8090/actuator/health
hystrix正常⼯作状态
hystrix熔断状态
2.7 Hystrix Dashboard监控仪表盘
上一节,介绍了通过spring boot actuator
监控Hystrix状态,通过访问/actuator/health
接⼝可以 获取到监控的⽂字信息,但是不直观,所以Hystrix官⽅还提供了基于图形化的 DashBoard(仪表板)监控平 台。Hystrix仪表板可以显示每个断路器(被 @HystrixCommand注解的⽅法)的状态。
-
新建⼀个监控服务⼯程,导⼊依赖
<dependencies> <!--hystrix--> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-hystrix</artifactId> <version>2.2.9.RELEASE</version> </dependency> <!--hystrix 仪表盘--> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-hystrix-dashboard</artifactId> <version>2.2.9.RELEASE</version> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId> </dependency> </dependencies>
-
启动类添加@EnableHystrixDashboard激活仪表盘
@SpringBootApplication @EnableDiscoveryClient @EnableHystrixDashboard // 开启hystrix dashboard public class HystrixDashboardApplication { public static void main(String[] args) { SpringApplication.run(HystrixDashboardApplication.class,args); } }
-
application.yml
server: port: 9000 Spring: application: name: yyq-cloud-hystrix-dashboard eureka: client: serviceUrl: # eureka server的路径 # 把 eureka 集群中的所有 url 都填写了进来,也可以只写一台,因为各个 eureka server 可以同步注册表 defaultZone: http://127.0.0.1:8761/eureka/ instance: #使用ip注册,否则会使用主机名注册了(此处考虑到对老版本的兼容,新版本经过实验都是ip) prefer-ip-address: true #自定义实例显示格式,加上版本号,便于多版本管理,注意是ip-address,早期版本是ipAddress instance-id: ${spring.cloud.client.ip-address}:${spring.application.name}:${server.port}:@project.version@ hystrix: dashboard: proxy-stream-allow-list: "*"
-
在被监测的微服务中注册监控servlet
@Configuration public class HystrixDashboard { @Bean public ServletRegistrationBean getServlet(){ HystrixMetricsStreamServlet streamServlet = new HystrixMetricsStreamServlet(); ServletRegistrationBean registrationBean = new ServletRegistrationBean(streamServlet); registrationBean.setLoadOnStartup(1); registrationBean.addUrlMappings("/actuator/hystrix.stream"); registrationBean.setName("HystrixMetricsStreamServlet"); return registrationBean; } }
-
被监控微服务发布之后,可以访问 http://localhost:8090/actuator/hystrix.stream,但是得到的数据并不直观,可以结合仪表盘更友好的展示
-
访问仪表盘
http://localhost:9000/hystrix
输入监控的微服务地址,展示监控的详细数据,比如监控服务消费者http://localhost:8090/actuator/hystrix.stream
2.8 Hystrix Turbine聚合监控
之前,我们针对的是⼀个微服务实例的Hystrix数据查询分析,在微服务架构下,⼀ 个微服务的实例往往是多个(集群化)。
⽐如用户信息微服务 :
-
实例1(hystrix) ip1:port1/actuator/hystrix.stream
-
实例2(hystrix) ip2:port2/actuator/hystrix.stream
-
实例3(hystrix) ip3:port3/actuator/hystrix.stream
按照已有的⽅法,我们就可以结合dashboard仪表盘每次输⼊⼀个监控数据流url, 进去查看 ⼿⼯操作能否被⾃动功能替代?Hystrix Turbine聚合(聚合各个实例上的hystrix监 控数据)监控。