文章目录
- 一、Sentinel熔断与限流
- 二、控制台安装
- 1、Sentinel控制台安装
- 三、规则讲解
- 1、实时监控
- 2、流控规则
- 2.1 流控模式——直接
- 2.2 流控模式——关联
- 2.3 流控效果——Warm Up
- 2.4 流控效果——排队等待
- 3、降级规则
- 3.1 RT
- 3.2 异常比例
- 3.3 异常数
- 4、热点规则
- 5、系统规则
- 6、@SentinelResource
- 四、规则持久化
一、Sentinel熔断与限流
A powerful flow control component enabling reliability, resilience and monitoring for microservices. (面向云原生微服务的高可用流控防护组件)
类比Spring Cloud Nexfix的Hystrix组件,用于服务的熔断降级。
官网
随着微服务的流行,服务和服务之间的稳定性变得越来越重要。Sentinel 以流量为切入点,从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。
Sentinel 具有以下特征:
- 丰富的应用场景:Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景,例如秒杀(即突发流量控制在系统容量可以承受的范围)、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。
- 完备的实时监控:Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机器秒级数据,甚至 500 台以下规模的集群的汇总运行情况。
- 广泛的开源生态:Sentinel 提供开箱即用的与其它开源框架/库的整合模块,例如与 Spring Cloud、Dubbo、gRPC 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入 Sentinel。
- 完善的 SPI 扩展点:Sentinel 提供简单易用、完善的 SPI 扩展接口。您可以通过实现扩展接口来快速地定制逻辑。例如定制规则管理、适配动态数据源等。
Sentinel 的主要特性:
Sentinel 的开源生态:
Sentinel 分为两个部分:
- 核心库(Java 客户端)不依赖任何框架/库,能够运行于所有 Java 运行时环境,同时对 Dubbo / Spring Cloud 等框架也有较好的支持。
- 控制台(Dashboard)基于 Spring Boot 开发,打包后可以直接运行,不需要额外的 Tomcat 等应用容器。
二、控制台安装
1、Sentinel控制台安装
由于是一个jar包,我们直接可以直接使用java -jar命令来运行这个jar包。当然前提是你的8080端口没有被占用,Sentinel默认端口也是8080。
访问测试:
账号和密码均是sentinel
三、规则讲解
规则讲解可以简单理解为Sentinel控制台的使用讲解。下面的小节也将按照控制台面板的顺序依次往下进行讲解
1、实时监控
1、 新建一个端口为8401的项目
2、添加maven依赖
3、修改配置文件
1、配置端口号
2、配置项目名字
3、配置将注册到那个位置的注册中心
4、配置被哪个端口的进行限流监控(8080将会监控8401)
4、添加controller层接口类
5、访问测试
1、启动sentinel服务
2、启动被监控程序
3、访问对应接口
4、观察Sentinel控制台变化
分别访问接口:http://localhost:8401/testA和http://localhost:8401/testB
我们可以发现Sentinel控制台已经能够成功监控我们的访问结果,此时即表示测试成功
2、流控规则
流量控制(flow control),其原理是监控应用流量的 QPS 或并发线程数等指标,当达到指定的阈值时对流量进行控制,以避免被瞬时的流量高峰冲垮,从而保障应用的高可用性。
流量控制规则面板
1、资源名:唯一名称,默认请求路径
2、针对来源:Sentinel可以针对调用者进行限流,填写微服务名,默认default(不区分来源)
3、阈值类型/单机阈值:
- QPS(每秒钟的请求数量):当调用该api的QPS达到阈值的时候,进行限流。
- 线程数:当调用该api的线程数达到阈值的时候,进行限流
4、是否集群:不需要集群
5、流控模式:
- 直接: api达到限流条件时,直接限流
- 关联:当关联的资源达到阈值时,就限流自己
- 链路:只记录指定链路上的流量((指定资源从入口资源进来的流量,如果达到阈值,就进行限流)【api级别的针对来源】
6、流控效果:
- 快速失败:直接失败,抛异常
- Warm Up:根据codeFactor (冷加载因子,默认3)的值,从阈值/codeFactor,经过预热时长,才达到设置的QPS阈值
- 排队等待:方式会严格控制请求通过的间隔时间,也即是让请求以均匀的速度通过,对应的是漏桶算法
2.1 流控模式——直接
QPS的阈值限之就是限制每秒的访问次数,当每秒钟访问的次数超过设定的阈值就会返回对应的被限流提示。线程数表示,单次处理的线程数量。
即前者理解为让你排队进入房间,后者理解为排队进行服务,任何的拥挤 现象都会返回流量被限制提示。
QPS直接
1、新增流量控制
2、设置对应的控制规则
这里设置为QPS,每秒1次,超过数量则快速失败
资源名:唯一名称,默认请求路径
3、访问接口测试
当我们访问的频率超过设定的阈值(1)就会触发设定的流控规则
线程数直接
1、修改我们的接口方法
让一个线程的处理时间边长,这样模拟处理服务的时间。如果在一个线程处理服务的时候其他线程进来了,那么就可以理解为拥挤,这样就会返回对应的错误信息。
2、修改对应的控制规则
3、访问接口测试
一个线程还没有处理完,另一个线程进来了,就会触设定的流控规则
2.2 流控模式——关联
流控模式关联
当关联的资源达到阈值时,就限流自己
A关联B,当B达到阈值时,限流A
1、新增对应的控制规则
阈值设置为1
2、使用Postman模拟人的快速访问
3、保存对应的测试路径,并设置对应的访问次数及时间间隔(访问20次,0.3秒一次)
4、测试访问接口/testA
由于大量的访问/testB接口,设定的规则QPS为1,超过了阈值,所以访问test A接口被限制
2.3 流控效果——Warm Up
默认coldFactor为3,即请求QPS从(threshold / 3)开始,经多少预热时长才逐渐升至设定的QPS阈值。
1、设置流控规则
以上图为例,设置阈值为10,预热时长为5秒。
系统初始化的阈值为10/3约等于3,即阈值刚开始为3;然后过了5秒后阈值才慢慢升高恢复到10
2、访问对应的接口
在预热刚开始,访问的速度超过阈值(这里约等于3),则会返回限流提示。5秒钟的预热完成之后,只要访问的速度超过阈值(10)才会返回对应的限流提示。
如:秒杀系统在开启的瞬间,会有很多流量上来,很有可能把系统打死,预热方式就是把为了保护系统,可慢慢的把流量放进来,慢慢的把阈值增长到设置的阈值。
2.4 流控效果——排队等待
1、设置对应的限流规则
2、修改接口方法,打印访问时间
3、使用postman模拟快速访问测试(0.3秒一个,一共10个)
4、查看测试结果
尽管我们在postman中设置的规则是0.3秒访问一次,但是由于我们定义了流控效果,并且对应的效果是排队等待,故所有的访问都会执行,并且根据QPS的设定速度访问,一秒一个
3、降级规则
除了流量控制以外,对调用链路中不稳定的资源进行熔断降级也是保障高可用的重要措施之一。一个服务常常会调用别的模块,可能是另外的一个远程服务、数据库,或者第三方 API 等。例如,支付的时候,可能需要远程调用银联提供的 API;查询某个商品的价格,可能需要进行数据库查询。然而,这个被依赖服务的稳定性是不能保证的。如果依赖的服务出现了不稳定的情况,请求的响应时间变长,那么调用服务的方法的响应时间也会变长,线程会产生堆积,最终可能耗尽业务自身的线程池,服务本身也变得不可用。
Sentinel 提供以下几种熔断策略:
- 慢调用比例 (SLOW_REQUEST_RATIO):选择以慢调用比例作为阈值,需要设置允许的慢调用 RT(即最大的响应时间),请求的响应时间大于该值则统计为慢调用。当单位统计时长(statIntervalMs)内请求数目大于设置的最小请求数目,并且慢调用的比例大于阈值,则接下来的熔断时长内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态(HALF-OPEN 状态),若接下来的一个请求响应时间小于设置的慢调用 RT 则结束熔断,若大于设置的慢调用 RT 则会再次被熔断。
- 异常比例 (ERROR_RATIO):当单位统计时长(statIntervalMs)内请求数目大于设置的最小请求数目,并且异常的比例大于阈值,则接下来的熔断时长内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态(HALF-OPEN 状态),若接下来的一个请求成功完成(没有错误)则结束熔断,否则会再次被熔断。异常比率的阈值范围是 [0.0, 1.0],代表 0% - 100%。
- 异常数 (ERROR_COUNT):当单位统计时长内的异常数目超过阈值之后会自动进行熔断。经过熔断时长后熔断器会进入探测恢复状态(HALF-OPEN 状态),若接下来的一个请求成功完成(没有错误)则结束熔断,否则会再次被熔断。
3.1 RT
1、新增方法
2、配置规则
永远一秒钟打进来10个线程(大于5个)调用testD(可以使用JMeter工具模拟),我们希望200毫秒处理完本次任务,如果超过200毫秒还没处理完,在未来1秒钟的时间窗口内,断路器打开(保险丝跳闸)微服务不可用,返回指定的降级信息
3.2 异常比例
1、修改方法
2、配置规则
访问的80%要正确,否则就会有一秒钟的不可用
按照上述配置以后,单独访问一次,必然会报错(代码存在10/0),访问接口,返回异常错误信息。在高并发的场景下(使用JMeter模拟),直接高并发发送请求,多次调用达到了我们的配置条件(请求资源数每秒到达5个及以上),断路器开启(保险丝跳闸),微服务不可用,此时则不再返回异常错误信息,而是返回对应的降级提示信息。
3.3 异常数
1、新增方法
2、配置规则
3、访问测试
访问接口,根据设置的规则,访问5次以后返回指定的降级提示信息
前几次会返回异常信息
4、热点规则
1、新增方法
配置限流规则和我们SentinelResource注解上的value一致
blockHandler = "deal_testHotKey"表示当触发热点的限流规则时,会跳转的方法,如果不配置该项则会返回到系统默认的限流界面
2、配置限流规则
资源名和上面@SentinelResource注解的value值对应,只能使用QPS模式,该配置表示访问接口的第一个参数,如果在1秒钟内单机访问的次数超过一次,那么就会触发限流规则
3、访问测试
1秒1次的访问,会返回正确的指定的结果
超过这个阈值,就会触发我们的自定义的限流规则
只要路径中带有第一个参数就算符合热点Key的限流规则,如http://localhost:8401/testHotKey?p1=3&p2=3
高级配置
类似于VIP配置项
当我们的参数值为5时,允许QPS阈值为10,其他情况下为阈值1
此时访问对应的路径时,第一个参数值为5时,并发量可以提高
参数类型只支持8大基本数据类型+String字符串类型
5、系统规则
系统保护规则是从应用级别的入口流量进行控制,从单台机器的 load、CPU 使用率、平均 RT、入口 QPS 和并发线程数等几个维度监控应用指标,让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。
系统保护规则是应用整体维度的,而不是资源维度的,并且仅对入口流量生效。入口流量指的是进入应用的流量(EntryType.IN),比如 Web 服务或 Dubbo 服务端接收的请求,都属于入口流量。
系统规则支持以下的模式:
- Load 自适应(仅对 Linux/Unix-like 机器生效):系统的 load1 作为启发指标,进行自适应系统保护。当系统 load1 超过设定的启发值,且系统当前的并发线程数超过估算的系统容量时才会触发系统保护(BBR 阶段)。系统容量由系统的 maxQps * minRt估算得出。设定参考值一般是 CPU cores * 2.5。
- CPU usage(1.5.0+ 版本):当系统 CPU 使用率超过阈值即触发系统保护(取值范围 0.0-1.0),比较灵敏。
- 平均 RT:当单台机器上所有入口流量的平均 RT 达到阈值即触发系统保护,单位是毫秒。
- 并发线程数:当单台机器上所有入口流量的并发线程数达到阈值即触发系统保护。
- 入口 QPS:当单台机器上所有入口流量的 QPS 达到阈值即触发系统保护。
该配置表示,项目外部的整体QPS达到阈值1以后,就会返回指定规则的信息
6、@SentinelResource
从HystrixCommand到@SentinelResource
官方文档地址
常规情况下流控规则的资源名为我们接口的映射路径名
我们还可以使用@SentinelResource注解的value值来配置(前面热点Key的限流章节已经演示)
只要我们使用了@SentinelResource注解,就可以根据配置的限流规则进行跳转(自定义方法或者是使用默认的跳转路径)
针对我们配置的限流方法blockHandler的思考
1、系统默认的,没有体现我们自己的业务要求。
2、依照现有条件,我们自定义的处理方法又和业务代码耦合在一块,不直观。
3、每个业务方法都添加一个兜底的,那代码膨胀加剧。
4、全局统—的处理方法没有体现。
限流配置
前文演示过在同一个类中定义限流方法,此处我们使用一个单独的类配置限流方法
1、新建异常返回类
2、配置对应的限流规则
3、接口访问测试
当访问接口的次数超过阈值,就会根据@SentinelResource注解配置的方法进行返回,使用一个类单独配置可以完成解耦
服务熔断
还是借助@SentinelResource注解
1、新建访问接口
2、添加服务熔断方法
3、接口访问测试
当我们的id等于2时,就会抛出我们的空指针异常,由于我们配置了熔断功能,所以我们会跳转到我们自定义的异常返回方法中
服务降级和服务熔断同时配置
当我们同时指定了降级和熔断方法,降级方法的提示是要优于熔断方法出现。
@SentinelResource(value = “fallBackTest”, blockHandler = “deal_testHotKey”, fallback = “fallBackHandler”)
其实这并不难理解,当访问的QPS达到了阈值,且同时方法发生异常,触发服务熔断,前者可以抽象的理解为在整体项目的最外层安装了一个流量监控器,当访问的次数达到了监控的阈值,接下来的访问直接就被隔断在了项目之外,既然如此那又何来的抛出异常,触发服务熔断一说?
熔断框架对比
Sentinel | Hystrix | resilience4j | |
隔离策略 | 信号量隔离(并发线程数限流) | 线程池隔离/信号量隔离 | 信号量隔离 |
熔断降级策略 | 基于响应时间、异常比例、异常数 | 基于异常比例 | 基于异常比率、响应时间 |
实时统计实现 | 滑动窗口 | 滑动窗口(基于RxJava) | Ring Bit Buffer |
动态规则配置 | 支持多种数据源 | 支持多种数据源 | 有限支持 |
扩展性 | 多个扩展点 | 插件的形式 | 接口的形式 |
基于注解的支持 | 支持 | 支持 | 支持 |
限流 | 基于QPS,支持基于调用关系的限流 | 有限的支持 | Rate Limiter |
四、规则持久化
1、引入依赖
2、编写配置文件
3、nacos客户端新建服务
配置内容可以理解为我们前面控制台中的流控规则配置,我们直接通过json字符串配置一个流控规则
Data Id为我们在配置文件中的新增的dataId选项
- resource:资源名称
- limitApp:应用来源
- grade:阈值类型,0表示线程数,1表示QPS
- count:单机阈值
- strategy:流控模式,0表示直接,1表示关联,2表示链路
- controlBehavior:流控效果,0表示快速失败,1表示Wram Up,2表示排队等待
- clusterMode:是否集群
4、新建流控规则
5、访问对应的接口,观察流控是否生效
6、重启项目,观察流控规则是否持久化
当然,重启项目之前添加的流控规则依然存在,即规则持久化配置成功