前端码农

Appearance

Sentinel组件 ​

初识sentinel ​

雪崩效应 ​

概述：在微服务系统架构中，服务间调用关系错综复杂，一个微服务往往依赖于多个其它微服务。一个服务的不可用导致整个系统的不可用的现象就被称之为雪崩效应。

如下图所示：

image-20230624203044831

当服务D出现了问题了以后，调用服务D的服务A的线程就得不到及时的释放，在高并发情况下，随着时间的不断推移服务A的系统资源会被线程耗尽，最终导致服务A出现了问题，同理就会导致其他的服务也不能进行访问了。

解决方案 ​

超时处理 ​

超时处理：设定超时时间，请求超过一定时间没有响应就返回错误信息，不会无休止等待

image-20230624203153340

隔离处理 ​

隔离处理：将错误隔离在可控的范围之内，不要让其影响到其他的程序的运行。

这种设计思想，来源于船舱的设计，如下图所示：

image-20230624203222353

船舱都会被隔板分离为多个独立空间，当船体破损时，只会导致部分空间进入，将故障控制在一定范围内，避免整个船体都被淹没。于此类似，我们业务系统也可以使用这种思想来防止出现雪崩效应，常见的隔离方式：线程隔离

image-20230624203256590

熔断处理 ​

熔断处理：由断路器统计业务执行的异常比例，如果超出阈值则会熔断该业务，拦截访问该业务的一切请求。

断路器会统计访问某个服务的请求数量，异常比例如下所示：

image-20230624203334370

请求了三次，两次出现异常，一次成功。当发现访问服务D的请求异常比例过高时，认为服务D有导致雪崩的风险，会拦截访问服务D的一切请求，形成熔断：

image-20230624203409785

触发熔断了以后，当在访问服务A的时候，就不会在通过服务A去访问服务D了，立马给用户进行返回，返回的是一种默认值，这种返回就是一种兜底方案。这种兜底方案也将其称之为降级逻辑。

流量控制 ​

流量控制：限制业务访问的QPS(每秒的请求数)，避免服务因流量的突增而故障。

image-20230624203508014

限流是一种预防措施，避免因瞬间高并发流量而导致服务故障，进而避免雪崩。其他的处理方式是一种补救措施，在部分服务故障时，将故障控制在一定范围，避免雪崩。

sentinel介绍 ​

官网地址：https://sentinelguard.io/zh-cn/

随着微服务的流行，服务和服务之间的稳定性变得越来越重要。Sentinel 以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。

  • Sentinel 的历史：

- 2012 年，Sentinel 诞生，主要功能为入口流量控制。

- 2013-2017 年，Sentinel 在阿里巴巴集团内部迅速发展，成为基础技术模块，覆盖了所有的核心场景。Sentinel 也因此积累了大量的流量归整场景以及生产实践。

- 2018 年，Sentinel 开源，并持续演进。

- 2019 年，Sentinel 朝着多语言扩展的方向不断探索，推出 C++ 原生版本，同时针对 Service Mesh 场景也推出了 Envoy 集群流量控制支持，以解决 Service Mesh 架构下多语言限流的问题。

- 2020 年，推出 Sentinel Go 版本，继续朝着云原生方向演进。

  • Sentinel 分为两个部分:

- 核心库（Java 客户端）不依赖任何框架/库，能够运行于所有 Java 运行时环境，同时对 Dubbo / Spring Cloud 等框架也有较好的支持。

- 控制台（Dashboard）基于 Spring Boot 开发，打包后可以直接运行，不需要额外的 Tomcat 等应用容器。

image-20230624203655208

具有的特征:

image-20230624203730680

sentinel入门 ​

下载sentinel控制台 ​

sentinel管理后台下载地址：https://github.com/alibaba/Sentinel/releases

image-20230624215112184

下载完毕以后就会得到一个jar包

image-20230624215403344

启动sentinel ​

  • 将jar包放到任意非中文目录，执行命令：
shell
java -jar sentinel-dashboard-2.0.0-alpha-preview.jar
  • 如果要修改Sentinel的默认端口、账户、密码，可以通过下列配置：
配置项默认值说明
server.port8080服务端口
sentinel.dashboard.auth.usernamesentinel默认用户名
sentinel.dashboard.auth.passwordsentinel默认密码
  • 例如，修改端口：
sh
java -Dserver.port=8090 -jar sentinel-dashboard-2.0.0-alpha-preview.jar

访问sentinel ​

访问http://localhost:8080页面，就可以看到sentinel的控制台了：

image-20230624215635555

需要输入账号和密码，默认都是：sentinel

登录后，发现一片空白，什么都没有：因为还没有监控任何服务。另外，sentinel是懒加载的，如果服务没有访问，看不到该服务信息。

image-20230624215704921

整合sentinel ​

我们在spzx-cloud-user中整合sentinel，并连接sentinel的控制台，步骤如下：

1、引入sentinel依赖

xml
<!--sentinel-->
<dependency>
    <groupId>com.alibaba.cloud</groupId> 
    <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>

2、配置控制台

修改application.yaml文件，添加下面内容

yml
spring:
  cloud:
    sentinel:
      transport:
        dashboard: localhost:8080  # 配置sentinel控制台地址

3、访问spzx-cloud-user的任意接口

打开浏览器，访问http://localhost:10100/api/user/findUserByUserId/1，这样才能触发sentinel的监控。然后再访问sentinel的控制台，查看效果：

image-20230624220303385

流量控制 ​

雪崩问题虽然有四种方案，但是限流是避免服务因突发的流量而发生故障，是对微服务雪崩问题的预防。我们先学习这种模式。

相关概念 ​

簇点链路：当请求进入微服务时，首先会访问DispatcherServlet，然后进入Controller、Service、Mapper，这样的一个调用链就叫做簇点链路。

资源：簇点链路中被监控的每一个接口就是一个资源，流控、熔断等都是针对簇点链路中的资源来设置的。

默认情况下sentinel会监控spring mvc的每一个端点（Endpoint，也就是controller中的方法），因此spring mvc的每一个端点就是调用链路中的一个资源。

例如，我们刚才访问的spzx-cloud-user中的UserController中的端点：/api/user/findUserByUserId/

image-20230624220603571

我们可以点击对应资源后面的按钮来设置规则：

1、流控：流量控制

2、降级：降级熔断

3、热点：热点参数限流，是限流的一种

4、授权：请求的权限控制

快速入门 ​

需求：给 /api/user/findUserByUserId/{userId}这个资源设置流控规则，QPS不能超过 5，然后测试。

步骤：

1、首先在sentinel控制台添加限流规则

image-20230628090407483

2、利用jmeter测试(模拟并发请求)

Apache JMeter 是 Apache 组织基于 Java 开发的压力测试工具，用于对软件做压力测试。

下载地址：https://archive.apache.org/dist/jmeter/binaries/

课前资料提供了编写好的Jmeter测试样例

image-20230628115300889

通过如下命令打开jmeter

shell
java -jar ApacheJMeter.jar

导入课前资料提供的测试样例

image-20220320111824238

选择流控入门

image-20220320111955904

10个线程，1秒内运行完，QPS是10，超过了5。

选中流控入门，QPS<5右键运行

image-20220320112040803

注意：不要点击菜单中的执行按钮来运行。

点击查看结果树，理想的请求执行结果应该如下所示：

image-20220320112142379

可以看到，成功的请求每次只有5个。

注意：如果测试结果不是上述情况，那是因为sentinel在统计请求的时候，把一部分的请求统计到了下一秒中导致的。

流控模式 ​

流控模式简介 ​

在添加限流规则时，点击高级选项，可以选择三种流控模式：

1、直接：统计当前资源的请求，触发阈值时对当前资源直接限流，也是默认的模式

2、关联：统计与当前资源相关的另一个资源，触发阈值时，对当前资源限流

3、链路：统计从指定链路访问到本资源的请求，触发阈值时，对指定链路限流

如下所示：

image-20230628091856122

快速入门测试的就是直接模式。

关联模式 ​

关联模式：统计与当前资源相关的另一个资源，触发阈值时，对当前资源限流

配置方式：

image-20230628092034118

语法说明：对/api/user/updateUserById资源的请求进行统计，当访问流量超过阈值时，就对/api/user/findUserByUserId/{userId}进行限流，避免影响/api/user/updateUserById资源。

使用场景：比如用户支付时需要修改订单状态，同时用户要查询订单。查询和修改操作会争抢数据库锁，产生竞争。业务需求是优先支付和更新订单的业务，因此当修改订单业务触发阈值时，需要对查询订单业务限流。

案例实现：

1、在UserController新建一个端点：/api/user/updateUserById，无需实现业务

java
// 修改用户数据端点
@GetMapping(value = "/updateUserById")
public String updateUserById() {
    return "修改用户数据成功";
}

2、重启服务，访问对应的端点，让其产生簇点链路

image-20230628092515666

3、配置流控规则，当/api/user/updateUserById资源被访问的QPS超过5时，对/api/user/findUserByUserId/1请求限流。对哪个端点限流，就点击哪个端点后面的按钮。我们是对用户查询/api/user/findUserByUserId/1限流，因此点击它后面的按钮：

image-20230628092751648

4、在Jmeter中进行测试

选择《流控模式-关联》：

image-20220320114459422

可以看到1000个线程，100秒，因此QPS为10，超过了我们设定的阈值：5

查看http请求：

image-20230628093126793

请求的目标是/api/user/updateUserById，这样这个端点就会触发阈值。但限流的目标是/api/user/findUserByUserId/1，我们在浏览器访问，可以发现：

image-20230628093300378

确实被限流了。

关联流控模式的使用场景：

1、两个有竞争关系的资源

2、一个优先级较高，一个优先级较低

对高优先级的资源的流量进行统计，当超过阈值对低优先级的资源进行限流。

链路模式 ​

链路模式：只针对从指定链路访问到本资源的请求做统计，判断是否超过阈值，如果超过阈值对从该链路请求进行限流。

配置方式：

1、/api/user/save --> users

2、/api/user/query --> users

如果只希望统计从/api/user/query进入到users的请求，并进行限流操作，则可以这样配置：

image-20230628095013326

案例实现：

1、在UserService中添加一个queryUsers方法，不用实现业务

java
public void queryUsers(){
    System.err.println("查询用户");
}

2、在UserController中，添加两个端点，在这两个端点中分别调用UserService中的queryUsers方法

java
@GetMapping(value = "/save")
public String save() {
    userService.queryUsers();
    System.out.println("保存用户");
    return "订单保存成功" ;
}

@GetMapping(value = "/query")
public String query() {
    userService.queryUsers();
    System.out.println("查询用户");
    return "查询用户成功" ;
}

4、通过**@SentinelResource**标记UserService中的queryUsers方法为一个sentinel监控的资源(默认情况下，sentinel只监控controller方法)

java
@SentinelResource("users")
public void queryUsers(){
    System.err.println("查询用户");
}

5、更改application.yml文件中的sentinel配置

链路模式中，是对不同来源的两个链路做监控。但是sentinel默认会给进入spring mvc的所有请求设置同一个root资源，会导致链路模式失效。因此需要关闭这种资源整合。

yml
spring:
  cloud:
    sentinel:
      web-context-unify: false # 关闭context整合

6、重启服务，访问/api/user/save和/api/user/query，可以查看到sentinel的簇点链路规则中，出现了新的资源

image-20230628094306219

7、添加流控规则

点击users资源后面的流控按钮，在弹出的表单中填写下面信息：

image-20230628094433574

只统计从/api/user/query进入/users的资源，QPS阈值为2，超出则被限流。

8、jmeter测试

选择《流控模式-链路》

image-20220320150559229

可以看到这里200个线程，50秒内发完，QPS为4，超过了我们设定的阈值2。

一个http请求是访问/api/user/save

image-20230628094648097

另一个是访问/api/user/query

image-20230628094713655

运行测试，察看结果树：

访问/api/user/save,没有进行限流

image-20230628094814795

访问/api/user/query,进行限流了

image-20230628094857374

流控效果 ​

在流控的高级选项中，还有一个流控效果选项

image-20230628095109686

流控效果是指请求达到流控阈值时应该采取的措施，包括三种：

1、快速失败：达到阈值后，新的请求会被立即拒绝并抛出FlowException异常，是默认的处理方式

2、warm up：预热模式，对超出阈值的请求同样是拒绝并抛出异常，但这种模式阈值会动态变化，从一个较小值逐渐增加到最大阈值

3、排队等待：让所有的请求按照先后次序进入到一个队列中进行排队，当某一个请求最大的预期等待时间超过了所设定的超时时间时同样是拒绝并抛出异常

warm up ​

阈值一般是一个微服务能承担的最大QPS，但是一个服务刚刚启动时，一切资源尚未初始化（冷启动），如果直接将QPS跑到最大值，可能导致服务瞬间宕机。

warm up也叫预热模式，是应对服务冷启动的一种方案。阈值会动态变化，从一个较小值逐渐增加到最大阈值。

工作特点：请求阈值初始值是 maxThreshold / coldFactor, 持续指定时长(预热时间)后，逐渐提高到maxThreshold值，而coldFactor的默认值是3。

例如，我设置QPS的maxThreshold为10，预热时间为5秒，那么初始阈值就是 10 / 3 ，也就是3，然后在5秒后逐渐增长到10。

image-20220320152944101

案例需求：给/api/user/findUserByUserId/{userId}这个资源设置限流，最大QPS为10，利用warm up效果，预热时长为5秒

1、配置流控规则

image-20230628095505037

2、jmeter测试

选择《流控效果，warm up》

image-20220320153409220

QPS为10

刚刚启动时，大部分请求失败，成功的只有3个，说明QPS被限定在3：

image-20220320153522505

随着时间推移，成功比例越来越高

image-20220320153646510

到sentinel控制台查看实时监控

image-20230628095925921

排队等待 ​

排队等待：让所有的请求按照先后次序进入到一个队列中进行排队，当某一个请求最大的预期等待时间超过了所设定的超时时间时同样是拒绝并抛出异常

例如：QPS = 5，意味着每200ms处理一个队列中的请求；timeout = 2000，意味着预期等待时长超过2000ms的请求会被拒绝并抛出异常。

那什么叫做预期等待时长呢？

比如现在一下子来了12 个请求，因为每200ms执行一个请求，那么：

1、第6个请求的预期等待时长 = 200 * （6 - 1） = 1000ms

2、第12个请求的预期等待时长 = 200 * （12-1） = 2200ms

现在，第1秒同时接收到10个请求，但第2秒只有1个请求，此时QPS的曲线这样的：

image-20230628100019712

如果使用队列模式做流控，所有进入的请求都要排队，以固定的200ms的间隔执行，QPS会变的很平滑

image-20230628100049968

平滑的QPS曲线，对于服务器来说是更友好的。

案例需求：给/api/user/findUserByUserId/{userId}这个资源设置限流，最大QPS为10，利用排队的流控效果，超时时长设置为5s

1、添加流控规则

image-20230628100313331

2、jmeter测试

image-20220320154801992

QPS为15，已经超过了我们设定的10。

运行测试用例，察看结果树：

image-20220320155103019

全部都通过了。

再去sentinel查看实时监控的QPS曲线

image-20220320155202523

QPS非常平滑，一致保持在10，但是超出的请求没有被拒绝，而是放入队列。因此响应时间（等待时间）会越来越长。

热点参数限流 ​

配置介绍 ​

之前的限流是统计访问某个资源的所有请求，判断是否超过QPS阈值。而热点参数限流是分别统计参数值相同的请求，判断是否超过QPS阈值。

例如，一个根据id查询商品的接口：

image-20230628100914491

访问/goods/{id}的请求中，id参数值会有变化，热点参数限流会根据参数值分别统计QPS，统计结果：

image-20230628101012945

当id=1的请求触发阈值被限流时，id值不为1的请求不受影响。

配置方式(点击资源中的热点按钮)：

image-20230628101216576

代表的含义是：对hot这个资源的0号参数（第一个参数）做统计，每1秒相同参数值的请求数不能超过2。这种配置是对查询商品这个接口的所有商品一视同仁，QPS都限定为5。而在实际开发中，可能部分商品是热点商品，例如秒杀商品，我们希望这部分商品的QPS限制与其它商品不一样，高一些。那就需要配置热点参数限流的高级选项了：

image-20230628101331468

案例演示 ​

案例需求：给/api/user/findUserByUserId/{userId}这个资源添加热点参数限流，规则如下：

1、默认的热点参数规则是每1秒请求量不超过2

2、给2这个参数设置例外：每1秒请求量不超过4

3、给3这个参数设置例外：每1秒请求量不超过10

注意事项：热点参数限流对默认的spring mvc资源无效，需要利用@SentinelResource注解标记资源

实现步骤：

1、标记资源

给UserController中的/api/user/findUserByUserId/{userId}资源添加注解：

java
@SentinelResource("hot")  // 声明资源名称
@GetMapping(value = "/findUserByUserId/{userId}")
public User findUserByUserId(@PathVariable(value = "userId") Long userId ,
                             @RequestHeader(name = "Truth" , required = false)String header) {
    log.info("UserController...findUserByUserId方法执行了... ,header: {} , dateformat: {} " , header , patternProperties.getDateformat());
    return userService.findUserByUserId(userId) ;
}

2、热点参数限流规则

访问该接口，可以看到我们标记的hot资源出现了

image-20230628101715773

这里不要点击hot后面的按钮，页面有BUG

点击左侧菜单中热点规则菜单：

image-20230628102031276

3、jmeter测试

选择《热点参数限流 QPS1》

image-20220320162420189

这里发起请求的QPS为5。

包含三个请求，参数分别为：101 ， 102 ， 103，运行测试程序，察看结果树：

101image-20220320162905731
102image-20220320163002195
103image-20220320163023729