一、高并发带来的问题
在微服务架构中,我们将业务拆分成一个个的服务,服务与服务之间可以相互调用,但是由于网络原因或者自身的原因,服务并不能保证服务的100%可用,如果单个服务出现问题,调用这个服务就会出现网络延迟,此时若有大量的网络涌入,会形成任务堆积,最终导致服务瘫痪。
1. 编写java代码
@Slf4j
@RestController
@RequestMapping("/order")
public class OrderController {
@Autowired
private IFeignProductService feignProductService;
@RequestMapping("/findByParameter")
public String findByParameter(String name,Double price){
log.info("服务消费者日志:name={},price={}",name,price);
return feignProductService.findByParameter(name,price);
}
}
2. 修改配置文件中tomcat的并发数
1秒钟20个请求,最大连接数10,最大等待数10,最大线程数2,相当于一个线程1s能处理5个请求(2个处理10个请求)
server:
port: 8091
tomcat:
max-threads: 2 #最大线程数
max-connections: 10 #最大连接数
accept-count: 10 #最大线程等待数
3. 使用JMeter进行压力测试
下载地址 https://jmeter.apache.org/
- 修改配置,启动软件
进入bin目录,修改jmeter.properties文件中的语言支持为language=zh_CN
,然后点击jmeter.bat,启动软件
- 添加线程组
- 配置线程并发数
- 添加结果树、汇总报告
- 添加HTTP取样
-
配置取样,并启动测试
-
结果
二、服务雪崩效应
1. 雪崩效应
在分布式系统中,由于网络原因或自身的原因,服务一般无法保证 100% 可用,如果一个服务出现了问题,调用这个服务就会出现线程阻塞的情况,此时若有大量的请求涌入,就会出现多条线程阻塞等
待,进而导致服务瘫痪
由于服务与服务之间的依赖性,故障会传播,会对整个微服务系统造成灾难性的严重后果,这就是
服务故障的 “雪崩效应”
雪崩发生的原因多种多样,有不合理的容量设计,或者是高并发下某一个方法响应变慢,亦或是某台机器的资源耗尽。我们无法完全杜绝雪崩源头的发生,只有做好足够的容错,保证在一个服务发生问 题,不会影响到其它服务的正常运行,也就是"雪落而不雪崩"
2. 常见容错方案
要防止雪崩的扩散,我们就要做好服务的容错,容错说白了就是保护自己不被猪队友拖垮的一些措施, 下面介绍常见的服务容错思路和组件。
常见的容错思路有隔离、超时、限流、熔断、降级这几种,下面分别介绍一下
-
隔离
它是指将系统按照一定的原则划分为若干个服务模块,各个模块之间相对独立,无强依赖,当有故障发生时,能将问题和影响隔离在某个模块内部,而不扩散风险,不波及其它模块,不影响整体的系统服务,常见的隔离方式有:线程池隔离和信号量隔离
-
超时
在上游服务调用下游服务的时候,设置一个最大响应时间,如果超过这个时间,下游未作出反应,就断开请求,释放掉线程。
-
限流
限流就是限制系统的输入和输出流量已达到保护系统的目的,为了保证系统的稳固运行,一旦达到的需要限制的阈值,就需要限制流量并采取少量措施以完成限制流量的目的
-
熔断
在互联网系统中,当下游服务因访问压力过大而响应变慢或失败,上游服务为了保护系统整
体的可用性,可以暂时切断对下游服务的调用,这种牺牲局部,保全整体的措施就叫做熔断 服务熔断一般有三种状态:
-
熔断关闭状态(Closed)
服务没有故障时,熔断器所处状态,对调用方的调用不做任何限制
-
熔断开启状态(Open)
后续对该服务接口的调用不在经过网络,直接执行本地的fallback方法
-
半熔断状态(Half-Open)
尝试恢复服务调用,允许有限的流量调用该服务,并监控调用成功率,如果成功率到达预期,则说明服务已经恢复,进入熔断关闭状态;如果成功率依然很低,则重新进入熔断关闭状态
-
-
降级
降级其实就是为服务提供一个托底方案,一旦服务无法正常调用,就使用托底方案
3. 常见的容错插件
-
Hystrix
Hystrix是由Netflix开源的一个延迟和容错库,用于隔离访问远程系统、服务或者第三方库,防止级联失败,从而提升系统的可用性与容错性
-
Resilience4J
Resilicence4J一款非常轻量、简单,并且文档非常清晰、丰富的熔断工具,这也是Hystrix官方推荐的替代产品,不仅如此,Resilicence4j还原生支持Spring Boot 1.x/2.x,而且监控也支持和prometheus等多款主流产品进行整合
-
Sentinel
Sentinel 是阿里巴巴开源的一款断路器实现,本身在阿里内部已经被大规模采用,非常稳定
Sentinel | Hystrix | |
---|---|---|
隔离策略 | 信号量隔离 | 线程池隔离/信号量隔离 |
熔断降级策略 | 基于响应时间或失败比率 | 基于失败比率 |
实时指标实现 | 滑动窗口 | 滑动窗口(基于 RxJava) |
规则配置 | 支持多种数据源 | 支持多种数据源 |
扩展性 | 多个扩展点 | 插件的形式 |
基于注解的支持 | 即将支持 | 支持 |
限流 | 基于 QPS,支持基于调用关系的限流 | 不支持 |
流量整形 | 支持慢启动、匀速器模式 | 不支持 |
系统负载保护 | 支持 | 不支持 |
控制台 | 开箱即用,可配置规则、查看秒级监控、机器发现等 | 不完善 |
常见框架的适配 | Servlet、Spring Cloud、Dubbo、gRPC 等 | Servlet、Spring Cloud Netflix |
三、Sentinel-入门
1. 什么是Sentinel
Sentinel(分布式系统的流量防卫兵)是阿里开源的一套用于服务容错的综合性解决方案,他以流量为切入点,从流量控制、降级熔断、系统负载保护等多个维度来保护服务的稳定性
Sentinel具有以下特征
-
丰富的应用场景:
Sentinel承接了阿里巴巴近 10 年的双十一大促流量的核心场景, 例如秒杀(即突发流量控制在系统容量可以承受的范围)、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等
-
完备的实时监控:
Sentinel 提供了实时的监控功能,通过控制台可以看到接入应用的单台机器秒
级数据, 甚至 500 台以下规模的集群的汇总运行情况 -
广泛的开源生态:
Sentinel 提供开箱即用的与其它开源框架/库的整合模块, 例如与 Spring
Cloud、Dubbo、gRPC 的整合,只需要引入相应的依赖并进行简单的配置即可快速地接入
Sentinel -
完善的 SPI 扩展点:
Sentinel 提供简单易用、完善的 SPI 扩展接口,您可以通过实现扩展接口来快
速地定制逻辑。例如定制规则管理、适配动态数据源等
Sentinel 分为两个部分:
- 核心库(Java 客户端)不依赖任何框架/库,能够运行于所有 Java 运行时环境,同时对 Dubbo /Spring Cloud 等框架也有较好的支持
- 制台(Dashboard)基于 Spring Boot 开发,打包后可以直接运行,不需要额外的 Tomcat 等应用容器
2. 微服务集成Sentinel
在订单模块添加依赖
<!--sentinel-->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>
网关Gateway集成Sentinel还需要添加下面的依赖
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-alibaba-sentinel-gateway</artifactId>
</dependency>
3. 安装Sentinel控制台
3.1. 简介
Sentinel提供一个轻量级的控制台,他提供机器发现、单机资源实时监控以及规则管理等功能
3.2. 安装流程
-
下载jar包 https://github.com/alibaba/Sentinel/releases
-
启动cmd命令行
# 直接使用jar命令启动项目(控制台本身是一个SpringBoot项目) java -Dserver.port=8080 -Dcsp.sentinel.dashboard.server=localhost:8080 -Dproject.name=sentinel-dashboard -jar sentinel-dashboard-1.7.0.jar #参考1 java -jar sentinel-dashboard-1.8.1.jar --server.port=8080 #参考2 java -Dserver.port=8080 -Dcsp.sentinel.dashboard.server=localhost:8080 -Dproject.name=sentinel-dashboard -jar sentinel-dashboard-1.8.1.jar
-
修改配置文件,加入控制台配置
spring: cloud: sentinel: transport: port: 9999 #跟控制台交流的端口,随意指定一个未使用的端口即可 dashboard: localhost:8080 # 指定控制台服务的地址
-
通过浏览器访问 http://localhost:8080 进入控制台(用户默认密码是 sentinel\sentinel)
补充:了解控制台的使用原理
Sentinel的控制台其实就是一个SpringBoot编写的程序。我们需要将我们的微服务程序注册到控制台上,即在微服务中指定控制台的地址, 并且还要开启一个跟控制台传递数据的端口, 控制台也可以通过此端口调用微服务中的监控程序获取微服务的各种信息
3.3. 实现一个接口的限流
-
启动需要监控的服务,进行一次访问
-
访问后,会在Sentinel的控制台中监控到
-
点击簇点链路,可以查看到刚刚的接口,在右边可以对接口进行流控、熔断、热点、授权操作
4. Sentinel-概念和功能
4.1. 基本概念
-
资源
资源就是Sentinel要保护的东西
资源是 Sentinel 的关键概念,它可以是 Java 应用程序中的任何内容,可以是一个服务,也可以是一个方法,甚至可以是一段代码 -
规则
规则就是用来定义如何进行保护资源的作用在资源之上, 定义以什么样的方式保护资源,主要包括流量控制规则、熔断降级规则以及系统
保护规则
4.2. 重要功能
Sentinel的主要功能就是容错,主要体现为下面这三个:
-
流量控制
流量控制在网络传输中是一个常用的概念,它用于调整网络包的数据。任意时间到来的请求往往是随机不可控的,而系统的处理能力是有限的。我们需要根据系统的处理能力对流量进行控制,Sentinel 作为一个调配器,可以根据需要把随机的请求调整成合适的形状
-
熔断降级
当检测到调用链路中某个资源出现不稳定的表现,例如请求响应时间长或异常比例升高的时候,则对这个资源的调用进行限制,让请求快速失败,避免影响到其它的资源而导致级联故障
Sentinel 对这个问题采取了两种手段:
-
通过并发线程数进行限制
Sentinel 通过限制资源并发线程的数量,来减少不稳定资源对其它资源的影响,当某个资源出现不稳定的情况下,例如响应时间变长,对资源的直接影响就是会造成线程数的逐步堆积,当线程数在特定资源上堆积到一定的数量之后,对该资源的新请求就会被拒绝,堆积的线程完成任务后才开始继续接收请求
-
通过响应时间对资源进行降级
除了对并发线程数进行控制以外,Sentinel 还可以通过响应时间来快速降级不稳定的资源,当依赖的资源出现响应时间过长后,所有对该资源的访问都会被直接拒绝,直到过了指定的时间窗口之后才重新恢复
Sentinel 和 Hystrix 的区别
两者的原则是一致的, 都是当一个资源出现问题时, 让其快速失败, 不要波及到其它服务
但是在限制的手段上, 确采取了完全不一样的方法:
Hystrix 采用的是线程池隔离的方式, 优点是做到了资源之间的隔离, 缺点是增加了线程切换的成本
Sentinel 采用的是通过并发线程的数量和响应时间来对资源做限制
-
-
系统负载保护
Sentinel 同时提供系统维度的自适应保护能力,当系统负载较高的时候,如果还持续让请求进入可能会导致系统崩溃,无法响应,在集群环境下,会把本应这台机器承载的流量转发到其它的机器上去,如果这个时候其它的机器也处在一个边缘状态的时候,Sentinel 提供了对应的保护机制,让系统的入口流量和系统的负载达到一个平衡,保证系统在能力范围之内处理最多的请求
总之一句话: 我们需要做的事情,就是在Sentinel的资源上配置各种各样的规则,来实现各种容错的功
能。
4.3. Sentinel规则
4.3.1. 流控规则
流量控制,其原理是监控应用流量的QPS(每秒查询率) 或并发线程数等指标,当达到指定的阈值时,对流量进行控制,以避免被瞬时的流量高峰冲垮,从而保障应用的高可用性
-
找到监控的接口,点击右边的流控
-
新增界面
- 资源名:唯一名称,默认是请求路径,可自定义
- 针对来源:指定对哪个微服务进行限流,默认指default,意思是不区分来源,全部限制
- 阈值类型/单机阈值:
- QPS(每秒请求数量): 当调用该接口的QPS达到阈值的时候,进行限流
- 线程数:当调用该接口的线程数达到阈值的时候,进行限流
- 是否集群:暂不需要集群
- 流控方式
- 直接(默认):接口达到限流条件时,开始限流
- 关联:当关联的资源达到限流条件时,开启限流(适合做让步)
- 链路:当从某个接口过来的资源达到限流条件时,开始限流
流控模式演示:
-
直接流控模式
直接流控模式是最简单模式,当指定接口达到限流条件后开始限流
被限流会显示Blocked by Sentinel (flow limiting)
-
关联流控模式
关联流控模式指的是,当指定接口关联的接口达到限流条件后,开启对指定接口的限流
-
Controller代码
@GetMapping("/message1") public String message1() { String message = "message1"; System.out.println("message = " + message); return message; } @GetMapping("/message2") public String message2() { String message = "message2"; System.out.println("message = " + message); return message; }
-
配置限流规则,将流控模式设为关联,关联资源为 /messge2,注意QPS一定要大于3
-
通过JMeter进行压力测试
-
在压力测试过程中,访问 http://localhost:8091/message1
-
结果
-
-
链路流控模式
链路流控模式指的是,当从某个接口过来的资源达到限流条件时,开启限流,它的功能有点类似于针对来源配置项,区别在于:针对来源是针对上级微服务,
而链路流控是针对上级接口
,也就是说它的粒度更细-
编写一个Service,在里面添加一个方法message
@Service public class OrderServiceImpl2 { @SentinelResource(value = "message", blockHandler = "failBlockHandler") public Map message() { Map map = new HashMap(); map.put("code","200"); map.put("msg","正常响应成功"); return map; } public Map failBlockHandler(BlockException be) { Map map = new HashMap(); map.put("code","-1"); map.put("msg","接口被限流了..."); return map; } }
-
Controller
@RestController @Slf4j public class OrderController5 { @Autowired private OrderServiceImpl2 orderService; // 主要讲解 sentinel 中的 链路流控模式 @RequestMapping("/message3") public Map message3() { return orderService.message(); } @RequestMapping("/message4") public Map message4() { return orderService.message(); } }
-
禁止收敛URl的接口 context
从1.6.3版本开始,Sentinel Web filter默认收敛所有的URL的入口context,因此链路限流不生效
1.7.0版本开始(对应的SCA 2.1.1.RELEASE),官方在CommonFilter引入了WEB_CONTEXT_UNIFY参数,用于控制是否收敛context,将其配置为false,即可根据不同的URL进行链路限流
SCA 2.1.1RELEASE之后的版本,可以通过配置
spring.cloud.sentinel.web-context-unify: false
即可关闭收敛 -
在message3中添加流控
-
测试message3,快速点击超过阈值时,会出现以下返回结果
-
4.3.2. 降级规则
降级规则就是设置当满足什么条件的时候,对服务进行降级。Sentinel提供了三个衡量条件:
-
平均响应时间:
当资源平均值响应时间超过阈值(以ms为单位)之后,资源进入准降级状态
@RequestMapping("/message5") public String message5() { try { TimeUnit