目录
一、Sentinel介绍
1、什么是Sentinel
2、Sentinel好处
3、Sentinel下载和安装
二、搭建Sentinel项目
1、创建项目cloudalibaba-sentinel-service8401
三、Sentinel流控规则
1、流控规则基本介绍
2、新增流控
2.1、QPS直接失败案例
2.2、线程数直接失败案例
3、流控规则
3.1、关联
3.2、链路
4、流控效果
4.1、预热
4.2、排队等待
1、分布式系统的流量防卫兵:随着微服务的流行,服务和服务之间的稳定性变得越来越重要。Sentinel 是面向分布式、多语言异构化服务架构的流量治理组件,主要以流量为切入点,从流量路由、流量控制、流量整形、熔断降级、系统自适应过载保护、热点流量防护等多个维度来帮助开发者保障微服务的稳定性。
2、特点
丰富的应用场景:Sentinel在阿里巴巴得到了广泛应用,近10年来几乎覆盖了双11(11.11)购物节的所有核心场景,如需要限制突发流量以满足系统容量的“秒杀”、消息削峰填谷、下游服务不可靠的断路、集群流量控制等。
实时监控:Sentinel还提供实时监控能力。您可以实时查看单机的运行时信息,以及节点少于500个的集群的聚合运行时信息。
广泛的开源生态系统:Sentinel提供了与常用框架和库的开箱即用集成,如Spring Cloud、gRPC、Apache Dubbo和Quarkus。只需将适配器依赖项添加到服务中,就可以轻松使用Sentinel。
Polyglot支持:Sentinel为Java、Go、C++和Rust提供了本机支持。
各种SPI扩展:Sentinel提供易于使用的SPI扩展接口,允许您快速自定义逻辑,例如,自定义规则管理、调整数据源等。
Sentinel官网网站
spring-cloud-alibaba文档
分布式系统面临的问题:复杂的体系结构中的应用程序有数十个依赖关系,每个依赖关系在某些时候将不可避免的失败,比如如下的例子中,当我们调用A、E、F、J、K这几个服务的时候如果其中一个服务出现问题会造成什么问题?其实就会出现整体系统效率全部下降,而且严重就会出现服务雪崩的问题!
服务雪崩:
多个微服务之间调用的时候,假设A调用B和C,B和C又调用其他的微服务,这就是所谓的扇出。如果扇出的某个链路上某个微服务调用的响应时间过长或者不可用,微服务A的调用就用占用越来越多的系统资源,从而引起系统崩溃,这也就是服务雪崩。其实就是服务的高可用遭到了破坏。
对于高流量的应用来说,单一的后端依赖可能会导致服务器上的所有资源都在几秒钟内饱和。同时还有可能造成这些应用程序导致服务之间的延迟增加,备份列队,线程和其他的系统资源紧张,导致整个系统发生更多的级联故障。这些都表示需要对故障和延迟进行隔离和管理,以便单个依赖关系失败,不能取消整个应用程序或系统,所以通常发生了一个模块的某个实例失败后,这时候这个模块依然还会接受流量,然后这个有问题的模块还调用其他的模块,这样就会发生级联故障,或者叫做雪崩。
要解决这种问题的出现我们就需要用到服务降级,而Sentinel就可以保证在一个依赖出现问题的情况下,不会导致整体服务失败,避免级联故障,提高分布式系统的弹性。
Sentinel的熔断降级通过断路器实现:
断路器:它本身是一种开关装置,当某个服务单元发生故障之后,通过断路器的故障监控(类似于熔断保险丝),向调用方返回一个符合预期的、可处理的备选响应(FallBack),而不是长时间的等待或者抛出调用方法无法出的异常,这样就保证了服务调用方的不会被长时间、不必要的占用,从而避免了故障在分布式系统中蔓延(类似于病毒传染),从而避免了故障在系统中蔓延,乃至崩溃。
好处体现:
对比与其他的产品而言,比如说Hystrix,他不需要我们自己手动搭建监控平台,而且它有一套类似于Nacos的Web界面,可以让我们进行更加细粒度的配置流控、速率、服务熔断、服务降级等。
目前主流编程都是约定>配置>代码,虽然我们的配置都可以写在代码中,但是我们还是要大面积的学习配置和注解的方式,尽量少些代码,这也是Sentinel的理念和初衷。
Sentinel 分为两个部分
核心库(Java客户端)不依赖任何框架/库,只需要Java运行时环境,同时对Dubbo/SpringCloud 等框架也有较好的支持。
控制台(Dashboard)基于 SpringBoot开发,打包后可以直接运行,不需要额外的Tomcat等应用容器。
Sentinel下载地址
启动步骤
前提:jdk1.8环境和8080端口不能被占用
启动命令:java -jar sentinel-dashboard-x.x.x.jar
访问地址:localhost:8080
输入默认账号密码:sentinel/sentinel
Microsoft Windows [版本 10.0.19041.208]
(c) 2020 Microsoft Corporation. 保留所有权利。
G:\我的天地\开发工具>java -jar sentinel-dashboard-1.8.6.jar
INFO: Sentinel log output type is: file
INFO: Sentinel log charset is: utf-8
INFO: Sentinel log base directory is: C:\Users\Administrator\logs\csp\
INFO: Sentinel log name use pid is: false
INFO: Sentinel log level is: INFO
. ____ _ __ _ _
/\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
\\/ ___)| |_)| | | | | || (_| | ) ) ) )
' |____| .__|_| |_|_| |_\__, | / / / /
=========|_|==============|___/=/_/_/_/
:: Spring Boot :: (v2.5.12)
2023-06-03 21:11:16.289 INFO 20992 --- [ main] c.a.c.s.dashboard.DashboardApplication : Starting DashboardApplication using Java 1.8.0_202 on MS-RAOUGCUMKMLO with PID 20992 (G:\我的天地\开发工具\sentinel-dashboard-1.8.6.jar started by Administrator in G:\我的天地\开发工具)
2023-06-03 21:11:16.299 INFO 20992 --- [ main] c.a.c.s.dashboard.DashboardApplication : No active profile set, falling back to 1 default profile: "default"
2023-06-03 21:11:18.620 INFO 20992 --- [ main] o.s.b.w.embedded.tomcat.TomcatWebServer : Tomcat initialized with port(s): 8080 (http)
2023-06-03 21:11:18.630 INFO 20992 --- [ main] o.apache.catalina.core.StandardService : Starting service [Tomcat]
2023-06-03 21:11:18.630 INFO 20992 --- [ main] org.apache.catalina.core.StandardEngine : Starting Servlet engine: [Apache Tomcat/9.0.60]
2023-06-03 21:11:18.780 INFO 20992 --- [ main] o.a.c.c.C.[Tomcat].[localhost].[/] : Initializing Spring embedded WebApplicationContext
2023-06-03 21:11:18.780 INFO 20992 --- [ main] w.s.c.ServletWebServerApplicationContext : Root WebApplicationContext: initialization completed in 2411 ms
2023-06-03 21:11:18.880 INFO 20992 --- [ main] c.a.c.s.dashboard.config.WebConfig : Sentinel servlet CommonFilter registered
2023-06-03 21:11:20.764 INFO 20992 --- [ main] o.s.b.w.embedded.tomcat.TomcatWebServer : Tomcat started on port(s): 8080 (http) with context path ''
2023-06-03 21:11:20.784 INFO 20992 --- [ main] c.a.c.s.dashboard.DashboardApplication : Started DashboardApplication in 5.032 seconds (JVM running for 5.699)
2023-06-03 21:11:42.877 INFO 20992 --- [nio-8080-exec-1] o.a.c.c.C.[Tomcat].[localhost].[/] : Initializing Spring DispatcherServlet 'dispatcherServlet'
2023-06-03 21:11:42.878 INFO 20992 --- [nio-8080-exec-1] o.s.web.servlet.DispatcherServlet : Initializing Servlet 'dispatcherServlet'
2023-06-03 21:11:42.881 INFO 20992 --- [nio-8080-exec-1] o.s.web.servlet.DispatcherServlet : Completed initialization in 2 ms
到这里为止,我们的Sentinel安装成功。
Sentinel初始化工程:
1. 启动Nacos8848成功
2. 创建新的Module:cloudalibaba-sentinel-service8401
3. 启动Sentinel8080
4. 启动微服务8401
5. 启动8401微服务后查看Sentinel控制台
Sentinel的官方文档网址
pom
com.alibaba.cloud
spring-cloud-starter-alibaba-nacos-discovery
com.alibaba.cloud
spring-cloud-starter-alibaba-sentinel
配置yaml文件,目的是让当前8401注册进Nacos,然后被Sentinel8080进行监控
server:
port: 8401
spring:
application:
name: cloudalibaba-sentinel-service
cloud:
nacos:
discovery:
server-addr: localhost:8848
sentinel:
transport:
# 配置Sentinel dashboard地址
dashboard: localhost:8080
# 默认8719端口,键入被占用会自动从8719+1,直到找到未被占用的端口
port: 8719
management:
endpoints:
web:
exposure:
include: '*'
编写FlowLimitController
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;
@RestController
public class FlowLimitController {
@GetMapping("/testA")
public String testA(){
return "-----testA";
}
@GetMapping("/testB")
public String testB(){
return "-----testB";
}
}
测试
当以上的这些配置配置好以后,我们就可以进行测试了,那我们的测试方式就是,首先保证Nacos和Sentinel都是启动状态,然后再来启动项目,按照我们的理解这个时候,就应该在Sentinel的dashboard上能体现出它监控的服务,但是此时并没有,原因是因为Sentinel本身采用的是懒加载机制,所以我们需要首先访问服务对应的接口,Sentinel才能工作。
http://localhost:8401/testA
http://localhost:8401/testB
访问之后我们来查看Sentinel的dashboard--实时监控
那么这个时候我们频繁快速的访问testA或者testB那么我们再来查看实时监控的时候,就会出现波动,体现此时Sentinel正在监控这我们的8401这个服务
名词解释
资源名:唯一名称,默认请求路径
针对来源:Sentinel可以针对调用者进行限流,填写微服务名,默认default(不区分来源)
阈值类型/单机阈值:
QPS(每秒钟的请求数量):当调用该API的QPS达到阈值的时候,进行限流
线程数:当调用该API的线程数量达到阈值的时候,进行限流
是否集群:当前不需要集群
流控模式:
直接:API达到限流条件时,直接限流
关联:当关联的资源达到阈值时,就限流自己
链路:只记录指定链路上的流量(指定资源从入口资源进来的流量,如果达到阈值,就进行限流)(API级别的针对来源)
流控效果:
快速失败:直接失败,抛异常
Wam Up:根据codeFactor(冷加载因子,默认3)的值,从阈值/codeFacotor,经过预热时长,才达到设置的QPS阈值
排队等待:匀速排队,让请求以匀速的速度通过,阈值类型必须设置为QPS,否则无效
添加有两种方式,可以直接在流控规则选项中添加,也可以在簇点链路中添加,一般会采取第二种方式
现在我们给"/testA"添加流控。--点击[新增]
这里的意思就是我们现在单机阈值设定为1,代表的是当前这个接口只能被1秒访问一次,超过这个阈值,就会被Sentinel阻塞,现在默认为直接失败,也就是会在前台有一个体现
http://localhost:8401/testA
并发线程数规则:需要让一个线程再进来办理的时候需要0.8秒,但是这个时候后面的线程也在疯狂的访问,所以后面的线程就不会生效。
修改代码
@RestController
public class FlowLimitController {
@GetMapping("/testA")
public String testA(){
//暂停0.8秒
try {
TimeUnit.MILLISECONDS.sleep(800);
} catch (InterruptedException e) {
e.printStackTrace();
}
return "-----testA";
}
@GetMapping("/testB")
public String testB(){
return "-----testB";
}
}
这个时候我们重启项目,然后重新通过访问testA接口,通过两个网页(线程)来快速访问,这个时候我们来看效果,这里要注意,要重新添加流控规则。
如下--点击新增
http://localhost:8401/testA
注意:这个时候虽然效果一致,但是是两种完全不同的规则,一种是QPS,一种是并发线程,这点大家一定要分清!
官方解释:当关联的资源达到阈值时,就限流自己。
通俗解释来说,比如那我们的程序,现在有testA接口和testB接口,当A关联的资源B达到阈值后,就限流自己,也就是B到达阈值,限流A本身。就好像我家孩子在外面打架,我来处理一样。换到程序里面来说比如一个电商系统中,支付系统达到阈值,就限流下订单系统。
具体演示
当关联资源/testB的qps阈值超时1时,就限流/testA的Rest访问地址,当关联资源到阈值后限制配置好的资源名,首先我们先把FlowLimitController接口恢复原样
@RestController
public class FlowLimitController {
@GetMapping("/testA")
public String testA(){
return "-----testA";
}
@GetMapping("/testB")
public String testB(){
return "-----testB";
}
}
给testA添加流控规则
为了演示效果,所以这里我们需要借助一个工具Postman,来模仿并发密集访问/testB,先来测试访问testB接口
这个时候我们需要多次密集访问TestB接口,所以我们需要添加配置,具体操作如下:
把数值修改为:
- Iterations:为20
- Delay:300
意思就是20个线程每间隔0.3秒访问一次,然后跑起来.
注意:postman中的请求地址要点击左上方的Save。保存。
这个时候我们来访问testA接口的效果
链路流控模式指的是,当从某个接口过来的资源达到限流条件时,开启限流,它的功能有点类似于针对来源配置项,区别在于:针对来源是针对上级微服务,而链路流控是针对上级接口,也就是说它的粒度更细。
比如在一个微服务中,两个接口都调用了同一个Service中的方法,并且该方法用SentinelResource(用于定义资源)注解标注了,然后对该注解标注的资源(方法)进行配置,则可以选择链路模式。
具体演示
首先我们编写一个Service
//service.TestService
@Service
public class TestService {
// 定义限流资源
@SentinelResource("common")
public String common(){
return "common";
}
}
然后更改接口调用这个Service方法
@RestController
public class FlowLimitController {
@Autowired
TestService testService;
@GetMapping("/testA")
public String testA(){
return testService.common();
}
@GetMapping("/testB")
public String testB(){
return testService.common();
}
}
接下来配置流控规则:
这里要注意不要对/testA或者/testB进行限流规则的配置,要给用SentinelResource注解标注的资源进行配置限流规则,这里的意思为当我们用入口资源访问被SentinelResource注解标注的资源方法时,当超过阈值就会被限流。
注意:版本为
yml追加配置web-context-unify: false
spring:
application:
name: cloudalibaba-sentinel-service
cloud:
sentinel:
transport:
# 配置Sentinel dashboard地址
dashboard: localhost:8080
# 默认8719端口,键入被占用会自动从8719+1,直到找到未被占用的端口
port: 8719
web-context-unify: false
访问testB接口,达到阈值,限流
Wam Up:根据codeFactor(冷加载因子,默认3)的值,从阈值/codeFacotor,经过预热时长,才达到设置的QPS阈值
Sentinel官网文档
概念:Warm Up方式,即预热/冷启动方式。该方式主要用于系统长期处于低水位的情况下,当流量突然增加时,直接把系统拉升到高水位可能瞬间把系统压垮。通过"冷启动",让通过的流量缓慢增加,在一定时间内逐渐增加到阈值上限,给冷系统一个预热的时间,避免冷系统被压垮的情况。
预热公式:阈值/coldFactor(默认值为3),经过预热时间后才会达到阈值。
冷启动的过程系统允许通过的QPS曲线如下图:
使用场景:一般秒杀系统中会有这样的流控设置,为了防止秒杀瞬间造成系统崩溃。
具体演示
默认coldFactor为3,当发起请求即请求QPS从(阈值/3)开始,经过多长预热时长才逐步升至设定的QPS阈值,当前阈值设置为10,预热时长设置为5秒。
最终的效果,系统初始化时阈值/3约等于3,即阈值在此时为3,经过5秒后阈值才慢慢升高到10
首先我们先来设置流控效果:
测试,我们用最简单的方法进行测试,直接在浏览器上手动刷新,然后我们来看Sentinel的实时监控.
快速请求testA接口,Sentinel的实时监控,如下图:
效果:5秒内同频次访问有失败的,5秒后没有失败了。蓝色线拒绝QPS,绿色线通过QPS。
绿色线缓慢上升。
排队等待:匀速排队,让请求以匀速的速度通过,阈值类型必须设置为QPS,否则无效
概念:匀速排队方式会严格控制请求通过的间隔时间,也即是让请求以均匀的速度通过,对应的是漏桶算法。
这种方式主要用于处理间隔性突发的流量,例如消息队列。想象一下这样的场景,在某一秒有大量的请求到来,而接下来的几秒则处于空闲状态,我们希望系统能够在接下来的空闲期间逐渐处理这些请求,而不是在第一秒直接拒绝多余的请求(削峰填谷)。
匀速器
它的中心思想是,以固定的间隔时间让请求通过。当请求到来的时候,如果当前请求距离上个通过的请求通过的时间间隔不小于预设值,则让当前请求通过。否则,计算当前请求的预期通过时间,如果该请求的预期通过时间小于规则预设的 timeout 时间,则该请求会等待直到预设时间到来通过(排队等待处理);若预期的通过时间超出最大排队时长,则直接拒接这个请求。
Sentinel 匀速排队等待策略是漏桶算法结合虚拟队列等待机制实现的。
注意:匀速排队模式暂时不支持 QPS > 1000 的场景。
具体演示
为了看到效果,我们在代码中进行打印,更改8401微服务中的FlowLimitController
@RestController
@Slf4j
public class FlowLimitController {
@Autowired
TestService testService;
@GetMapping("/testA")
public String testA(){
log.info(Thread.currentThread().getName()+":testA");
return testService.common();
}
@GetMapping("/testB")
public String testB(){
return testService.common();
}
}
最后我们可以通过Postman来进行测试,发送请求时没有延迟,同时发送10条请求,然后我们会发现就是排队效果1秒执行一个请求,同时我们在Idea中也可以看到打桩效果
Idea中也可以看到打桩效果,日志,1秒处理1个请求
2023-06-04 16:57:56.207 INFO 13084 --- [nio-8401-exec-9] c.l.s.controller.FlowLimitController : http-nio-8401-exec-9:testA
2023-06-04 16:57:57.207 INFO 13084 --- [io-8401-exec-10] c.l.s.controller.FlowLimitController : http-nio-8401-exec-10:testA
2023-06-04 16:57:58.207 INFO 13084 --- [nio-8401-exec-1] c.l.s.controller.FlowLimitController : http-nio-8401-exec-1:testA
2023-06-04 16:57:59.207 INFO 13084 --- [nio-8401-exec-2] c.l.s.controller.FlowLimitController : http-nio-8401-exec-2:testA
2023-06-04 16:58:00.207 INFO 13084 --- [nio-8401-exec-3] c.l.s.controller.FlowLimitController : http-nio-8401-exec-3:testA
2023-06-04 16:58:01.206 INFO 13084 --- [nio-8401-exec-4] c.l.s.controller.FlowLimitController : http-nio-8401-exec-4:testA
2023-06-04 16:58:02.208 INFO 13084 --- [nio-8401-exec-5] c.l.s.controller.FlowLimitController : http-nio-8401-exec-5:testA
2023-06-04 16:58:03.207 INFO 13084 --- [nio-8401-exec-6] c.l.s.controller.FlowLimitController : http-nio-8401-exec-6:testA
2023-06-04 16:58:04.206 INFO 13084 --- [nio-8401-exec-7] c.l.s.controller.FlowLimitController : http-nio-8401-exec-7:testA
2023-06-04 16:58:05.207 INFO 13084 --- [nio-8401-exec-8] c.l.s.controller.FlowLimitController : http-nio-8401-exec-8:testA
Spring Cloud Alibaba - Nacos
干我们这行,啥时候懈怠,就意味着长进的停止,长进的停止就意味着被淘汰,只能往前冲,直到凤凰涅槃的一天!