sentinel 基本概念

开发的原因，需要对吞吐量（TPS）、QPS、并发数、响应时间（RT）几个概念做下了解，查自百度百科，记录如下：

1. 响应时间(RT)
   　　响应时间是指系统对请求作出响应的时间。直观上看，这个指标与人对软件性能的主观感受是非常一致的，因为它完整地记录了整个计算机系统处理请求的时间。由于一个系统通常会提供许多功能，而不同功能的处理逻辑也千差万别，因而不同功能的响应时间也不尽相同，甚至同一功能在不同输入数据的情况下响应时间也不相同。所以，在讨论一个系统的响应时间时，人们通常是指该系统所有功能的平均时间或者所有功能的最大响应时间。当然，往往也需要对每个或每组功能讨论其平均响应时间和最大响应时间。
   　　对于单机的没有并发操作的应用系统而言，人们普遍认为响应时间是一个合理且准确的性能指标。需要指出的是，响应时间的绝对值并不能直接反映软件的性能的高低，软件性能的高低实际上取决于用户对该响应时间的接受程度。对于一个游戏软件来说，响应时间小于100毫秒应该是不错的，响应时间在1秒左右可能属于勉强可以接受，如果响应时间达到3秒就完全难以接受了。而对于编译系统来说，完整编译一个较大规模软件的源代码可能需要几十分钟甚至更长时间，但这些响应时间对于用户来说都是可以接受的。
2. 吞吐量(Throughput)
   吞吐量是指系统在单位时间内处理请求的数量。对于无并发的应用系统而言，吞吐量与响应时间成严格的反比关系，实际上此时吞吐量就是响应时间的倒数。前面已经说过，对于单用户的系统，响应时间（或者系统响应时间和应用延迟时间）可以很好地度量系统的性能，但对于并发系统，通常需要用吞吐量作为性能指标。
   　　对于一个多用户的系统，如果只有一个用户使用时系统的平均响应时间是t，当有你n个用户使用时，每个用户看到的响应时间通常并不是n×t，而往往比n×t小很多（当然，在某些特殊情况下也可能比n×t大，甚至大很多）。这是因为处理每个请求需要用到很多资源，由于每个请求的处理过程中有许多不走难以并发执行，这导致在具体的一个时间点，所占资源往往并不多。也就是说在处理单个请求时，在每个时间点都可能有许多资源被闲置，当处理多个请求时，如果资源配置合理，每个用户看到的平均响应时间并不随用户数的增加而线性增加。实际上，不同系统的平均响应时间随用户数增加而增长的速度也不大相同，这也是采用吞吐量来度量并发系统的性能的主要原因。一般而言，吞吐量是一个比较通用的指标，两个具有不同用户数和用户使用模式的系统，如果其最大吞吐量基本一致，则可以判断两个系统的处理能力基本一致。
3. 并发用户数
   并发用户数是指系统可以同时承载的正常使用系统功能的用户的数量。与吞吐量相比，并发用户数是一个更直观但也更笼统的性能指标。实际上，并发用户数是一个非常不准确的指标，因为用户不同的使用模式会导致不同用户在单位时间发出不同数量的请求。一网站系统为例，假设用户只有注册后才能使用，但注册用户并不是每时每刻都在使用该网站，因此具体一个时刻只有部分注册用户同时在线，在线用户就在浏览网站时会花很多时间阅读网站上的信息，因而具体一个时刻只有部分在线用户同时向系统发出请求。这样，对于网站系统我们会有三个关于用户数的统计数字：注册用户数、在线用户数和同时发请求用户数。由于注册用户可能长时间不登陆网站，使用注册用户数作为性能指标会造成很大的误差。而在线用户数和同事发请求用户数都可以作为性能指标。相比而言，以在线用户作为性能指标更直观些，而以同时发请求用户数作为性能指标更准确些。
4. QPS每秒查询率(Query Per Second)
   每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。对应fetches/sec，即每秒的响应请求数，也即是最大吞吐能力。 （看来是类似于TPS，只是应用于特定场景的吞吐量）

1、什么是Sentinel:

Sentinel是阿里开源的项目，提供了流量控制、熔断降级、系统负载保护等多个维度来保障服务之间的稳定性。
官网：Home · alibaba/Sentinel Wiki · GitHub

2012年，Sentinel诞生于阿里巴巴，其主要目标是流量控制。2013-2017年，Sentinel迅速发展，并成为阿里巴巴所有微服务的基本组成部分。 它已在6000多个应用程序中使用，涵盖了几乎所有核心电子商务场景。2018年，Sentinel演变为一个开源项目。2020年，Sentinel Golang发布。

Sentinel 具有以下特征:

丰富的应用场景 ：Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，例如秒杀（即
突发流量控制在系统容量可以承受的范围）、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。
完备的实时监控 ：Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机
器秒级数据，甚至 500 台以下规模的集群的汇总运行情况。
广泛的开源生态 ：Sentinel 提供开箱即用的与其它开源框架/库的整合模块，例如与 Spring
Cloud、Dubbo、gRPC 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入Sentinel。

完善的 SPI 扩展点：Sentinel 提供简单易用、完善的 SPI 扩展接口。您可以通过实现扩展接口来快
速地定制逻辑。例如定制规则管理、适配动态数据源等。

Sentinel的生态圈

Sentinel主要特性：

关于Sentinel与Hystrix的区别见：技术选型：Sentinel vs Hystrix-阿里云开发者社区

到这已经学习Sentinel的基本的使用，在很多的特性和Hystrix有很多类似的功能。以下是Sentinel和Hystrix的对比。

Sentinel 的使用

Sentinel 的使用可以分为两个部分:

• 控制台（Dashboard）：控制台主要负责管理推送规则、监控、集群限流分配管理、机器发现等。

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

在这里我们看下控制台的使用

Sentinel中的管理控制台

2.1 获取 Sentinel 控制台

您可以从 release 页面 下载最新版本的控制台 jar 包。

您也可以从最新版本的源码自行构建 Sentinel 控制台：

• 下载 控制台 工程
• 使用以下命令将代码打包成一个 fat jar: mvn clean package

2.2 sentinel服务启动

java -server -Xms64m -Xmx256m -Dserver.port=8849 -Dcsp.sentinel.dashboard.server=localhost:8849 -Dproject.name=sentinel-dashboard -jar /work/sentinel-dashboard-1.7.1.jar

开机启动：启动命令可以加入到启动的 rc.local 配置文件， 之后做到开机启动

启动 sentinel

/usr/bin/su - root -c "nohup java -server -Xms64m -Xmx256m -Dserver.port=8849 -Dcsp.sentinel.dashboard.server=localhost:8849 -Dproject.name=sentinel-dashboard -jar /work/sentinel-dashboard-1.7.1.jar 2>&1 &"

除了流量控制以外，对调用链路中不稳定的资源进行熔断降级也是保障高可用的重要措施之一。

由于调用关系的复杂性，如果调用链路中的某个资源不稳定，最终会导致请求发生堆积。Sentinel 熔断降级会在调用链路中某个资源出现不稳定状态时（例如调用超时或异常比例升高），对这个资源的调用进行限制，让请求快速失败，避免影响到其它的资源而导致级联错误。当资源被降级后，在接下来的降级时间窗口之内，对该资源的调用都自动熔断（默认行为是抛出 DegradeException）。

关于熔断降级的介绍见：Sentinel熔断降级。

下面就使用基于注解的方式实现Sentinel的熔断降级的demo。

注意：启动 Sentinel 控制台需要 JDK 版本为 1.8 及以上版本。

使用如下命令启动控制台：

nohup java -server -Xms64m -Xmx256m -Dserver.port=8849 -Dcsp.sentinel.dashboard.server=localhost:8849 -Dproject.name=sentinel-dashboard -jar /work/sentinel-dashboard-1.7.1.jar &

其中 -Dserver.port=8849用于指定 Sentinel 控制台端口为 8849 ， 这个端口可以按需指定。

从 Sentinel 1.6.0 起，Sentinel 控制台引入基本的登录功能，默认用户名和密码都是 sentinel。可以参考 鉴权模块文档 配置用户名和密码。

注：若您的应用为 Spring Boot 或 Spring Cloud 应用，您可以通过 Spring 配置文件来指定配置，详情请参考 Spring Cloud Alibaba Sentinel 文档。（1）获取 Sentinel 控制台
您可以从官方 网站中 下载最新版本的控制台 jar 包，下载地址如下：

https://github.com/alibaba/Sentinel/releases/download/1.6.3/sentinel-dashboard-1.7.1.jar

（2）启动
使用如下命令启动控制台：
其中 - Dserver.port=8888 用于指定 Sentinel 控制台端口为 8888 。
从 Sentinel 1.6.0 起，Sentinel 控制台引入基本的登录功能，默认用户名和密码都是 sentinel 。可以参考 鉴权模块文档 配置用户名和密码。

[root@192 ~]# java -Dserver.port=8888 -Dcsp.sentinel.dashboard.server=localhost:8888 -Dproject.name=sentinel-dashboard -jar sentinel-dashboard-1.6.3.jar INFO: log base dir is: /root/logs/csp/ INFO: log name use pid is: false . ____ _ __ _ _ /\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \ ( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \ \\/ ___)| |_)| | | | | || (_| | ) ) ) ) ' |____| .__|_| |_|_| |_\__, | / / / / =========|_|==============|___/=/_/_/_/ :: Spring Boot :: (v2.0.5.RELEASE) 2020-02-08 13:07:29.316 INFO 114031 --- [ main] c.a.c.s.dashboard.DashboardApplication : Starting DashboardApplication on 192.168.180.137 with PID 114031 (/root/sentinel-dashboard-1.6.3.jar started by root in /root) 2020-02-08 13:07:29.319 INFO 114031 --- [ main] c.a.c.s.dashboard.DashboardApplication : No active profile set, falling back to default profiles: default 2020-02-08 13:07:29.456 INFO 114031 --- [ main] ConfigServletWebServerApplicationContext : Refreshing org.springframework.boot.web.servlet.context.AnnotationConfigServletWebServerApplicationContext@59690aa4: startup date [Sat Feb 08 13:07:29 CST 2020]; root of context hierarchy 2020-02-08 13:07:33.783 INFO 114031 --- [ main] o.s.b.w.embedded.tomcat.TomcatWebServer : Tomcat initialized with port(s): 8888 (http)

启动 Sentinel 控制台需要 JDK 版本为 1.8 及以上版本。

查看机器列表以及健康情况
默认情况下Sentinel 会在客户端首次调用的时候进行初始化，开始向控制台发送心跳包。也可以配置
sentinel.eager=true ,取消Sentinel控制台懒加载。
打开浏览器即可展示Sentinel的管理控制台

客户端能接入控制台

控制台启动后，客户端需要按照以下步骤接入到控制台。

父工程引入 alibaba实现的SpringCloud

<dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> <version>Greenwich.RELEASE</version> <type>pom</type> <scope>import</scope> </dependency> <dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-alibaba-dependencies</artifactId> <version>2.1.0.RELEASE</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement>

子工程中引入 sentinel

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

（ 2）配置启动参数
在工程的application.yml中添加Sentinel 控制台配置信息

spring: cloud: sentinel: transport: dashboard: 192.168.180.137:8888 #sentinel控制台的请求地址

这里的 spring.cloud.sentinel.transport.dashboard 配置控制台的请求路径。

Sentinel与Hystrix的区别

迁移方案
Sentinel 官方提供了详细的由Hystrix 迁移到Sentinel 的方法

2 使用 Sentinel 来进行熔断与限流

Sentinel 可以简单的分为 Sentinel 核心库和 Dashboard。核心库不依赖 Dashboard，但是结合
Dashboard 可以取得最好的效果。
使用 Sentinel 来进行熔断保护，主要分为几个步骤:

1. 定义资源

   资源：可以是任何东西，一个服务，服务里的方法，甚至是一段代码。

2. 定义规则

   规则：Sentinel 支持以下几种规则：流量控制规则、熔断降级规则、系统保护规则、来源访问控制规则
   和 热点参数规则。

3. 检验规则是否生效

Sentinel 的所有规则都可以在内存态中动态地查询及修改，修改之后立即生效. 先把可能需要保护的资源定义好，之后再配置规则。

也可以理解为，只要有了资源，我们就可以在任何时候灵活地定义各种流量控制规则。在编码的时候，只需要考虑这个代码是否需要保护，如果需要保
护，就将之定义为一个资源。

1. 定义资源

资源是 Sentinel 的关键概念。它可以是 Java 应用程序中的任何内容，例如，由应用程序提供的服务，或由应用程序调用的其它应用提供的服务，RPC接口方法，甚至可以是一段代码。

只要通过 Sentinel API 定义的代码，就是资源，能够被 Sentinel 保护起来。大部分情况下，可以使用方法签名，URL，甚至服务名称作为资源名来标示资源。

把需要控制流量的代码用 Sentinel的关键代码 SphU.entry("资源名") 和 entry.exit() 包围起来即可。

实例代码：

Entry entry = null; try { // 定义一个sentinel保护的资源，名称为test-sentinel-api entry = SphU.entry(resourceName); // 模拟执行被保护的业务逻辑耗时 Thread.sleep(100); return a; } catch (BlockException e) { // 如果被保护的资源被限流或者降级了，就会抛出BlockException log.warn("资源被限流或降级了", e); return "资源被限流或降级了"; } catch (InterruptedException e) { return "发生InterruptedException"; } finally { if (entry != null) { entry.exit(); } ContextUtil.exit(); } }

在下面的例子中， 用 try-with-resources 来定义资源。参考代码如下:

public static void main(String[] args) { // 配置规则. initFlowRules(); while (true) { // 1.5.0 版本开始可以直接利用 try-with-resources 特性 try (Entry entry = SphU.entry("HelloWorld")) { // 被保护的逻辑 System.out.println("hello world"); } catch (BlockException ex) { // 处理被流控的逻辑 System.out.println("blocked!"); } } }

资源注解@SentinelResource

也可以使用Sentinel提供的注解@SentinelResource来定义资源，实例如下:

@SentinelResource("HelloWorld") public void helloWorld() { // 资源中的逻辑 System.out.println("hello world"); }

@SentinelResource 注解

注意：注解方式埋点不支持 private 方法。

@SentinelResource 用于定义资源，并提供可选的异常处理和 fallback 配置项。 @SentinelResource 注解包含以下属性：

• value：资源名称，必需项（不能为空）
• entryType：entry 类型，可选项（默认为 EntryType.OUT）
• blockHandler / blockHandlerClass:

blockHandler 对应处理 BlockException的函数名称，可选项。blockHandler 函数访问范围需要是 public，返回类型需要与原方法相匹配，参数类型需要和原方法相匹配并且最后加一个额外的参数，类型为 BlockException。blockHandler 函数默认需要和原方法在同一个类中。若希望使用其他类的函数，则可以指定 blockHandlerClass 为对应的类的 Class 对象，注意对应的函数必需为 static 函数，否则无法解析。

• fallback /fallbackClass

  ：fallback 函数名称，可选项，用于在抛出异常的时候提供 fallback 处理逻辑。fallback 函数可以针对所有类型的异常（除了exceptionsToIgnore里面排除掉的异常类型）进行处理。

• defaultFallback

  （since 1.6.0）：默认的 fallback 函数名称，可选项，通常用于通用的 fallback 逻辑（即可以用于很多服务或方法）。默认 fallback 函数可以针对所有类型的异常（除了exceptionsToIgnore里面排除掉的异常类型）进行处理。若同时配置了 fallback 和 defaultFallback，则只有 fallback 会生效。

fallback 函数签名和位置要求：

• 返回值类型必须与原函数返回值类型一致；

• 方法参数列表需要和原函数一致，或者可以额外多一个 Throwable 类型的参数用于接收对应的异常。

• fallback 函数默认需要和原方法在同一个类中。若希望使用其他类的函数，则可以指定 fallbackClass为对应的类的 Class 对象，注意对应的函数必需为 static 函数，否则无法解析。

defaultFallback 函数签名要求：

• 返回值类型必须与原函数返回值类型一致；
• 方法参数列表需要为空，或者可以额外多一个 Throwable 类型的参数用于接收对应的异常。
• defaultFallback 函数默认需要和原方法在同一个类中。若希望使用其他类的函数，则可以指定 fallbackClass 为对应的类的 Class 对象，注意对应的函数必需为 static 函数，否则无法解析。
• exceptionsToIgnore（since 1.6.0）：用于指定哪些异常被排除掉，不会计入异常统计中，也不会进入 fallback 逻辑中，而是会原样抛出。

2. 定义规则

规则主要有流控规则、 熔断降级规则、系统规则、权限规则、热点参数规则等：

一段硬编码的方式定义流量控制规则如下：

private void initSystemRule() { List<SystemRule> rules = new ArrayList<>(); SystemRule rule = new SystemRule(); rule.setHighestSystemLoad(10); rules.add(rule); SystemRuleManager.loadRules(rules); }

加载规则：

FlowRuleManager.loadRules(List<FlowRule> rules); // 修改流控规则 DegradeRuleManager.loadRules(List<DegradeRule> rules); // 修改降级规则 SystemRuleManager.loadRules(List<SystemRule> rules); // 修改系统规则 AuthorityRuleManager.loadRules(List<AuthorityRule> rules); // 修改授权规则

3 sentinel 熔断降级

1 什么是熔断降级

熔断降级对调用链路中不稳定的资源进行熔断降级是保障高可用的重要措施之一。

由于调用关系的复杂性，如果调用链路中的某个资源不稳定，最终会导致请求发生堆积。Sentinel 熔断降级会在调用链路中某个资源出现不稳定状态时（例如调用超时或异常比例升高），对这个资源的调用进行限制，让请求快速失败，避免影响到其它的资源而导致级联错误。当资源被降级后，在接下来的降级时间窗口之内，对该资源的调用都自动熔断（默认行为是抛出 DegradeException）

2. 熔断降级规则

熔断降级规则包含下面几个重要的属性：

3.Sentinel限流入门(监控入门) 概述: 系统中的数据库连接池，线程池，nginx的瞬时并发等在使用时都会给定一个限定的值，这本身就是一种限流的设计。限流的目的防止恶意请求流量、恶意攻击，或者防止流量超过系统峰值。 第一步：Sentinel 应用于服务提供方(sca-provider)，在消费方添加依赖: <dependency>     <groupId>com.alibaba.cloud</groupId>     <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId> </dependency> 1 2 3 4 第二步：打开服务消费方配置文件bootstrap.yml，添加sentinel配置: #服务注册地址   cloud:     sentinel:       transport:  #sentinel  控制台服务的地址         dashboard: localhost:8180 1 2 3 4 5 第三步：创建一个用于演示限流操作的Controller对象: @RestController @RequestMapping("/provider") public class ProviderSentinelController {     @GetMapping("/sentinel01")     public String deSentinel01(){         return "test Sentinel 01";     } } 1 2 3 4 5 6 7 8 第四步：启动sca-provider服务，然后对指定服务进行访问： 第五步：刷新sentinel 控制台，实时监控信息，如图： Sentinel的控制台其实就是一个SpringBoot编写的程序，我们需要将我们的服务注册到控制台上，即在微服务中指定控制台的地址，并且还要在消费端开启一个与sentinel控制台传递数据端的端口，控制台可以通过此端口调用微服务中的监控程序来获取各种信息。 4.Sentinel限流入门实践 设置一下指定接口的流控(流量控制)，QPS（每秒请求次数）单机阈值为1，代表每秒请求不能超出1次，要不然就做限流处理，处理方式直接调用失败。 第一步：选择要限流的链路： 第二步：设置限流策略，点击新增： 第三步：反复刷新访问消费端端服务，检测是否有限流信息输出： 5.Sentinel流控规则分析 5.1阈值类型 QPS(Queries Per Second)：当调用相关url对应的资源时，QPS达到单机阈值时，就会限流。 线程数：当调用相关url对应的资源时，线程数达到单机阈值时，就会限流。 5.2设置限流模式 直接模式 Sentinel的流控模式代表的流控的方式，默认【直接】，还有关联，链路。 直接模式，Sentinel默认的流控处理就是【直接->快速失败】。 关联模式 **当关联的资源达到阈值，就限流自己。**例如设置了关联资源为/ur2时，假如关联资源/url2的qps阀值超过1时，就限流/url1接口。举个例子，订单服务中会有2个重要的接口，一个是读取订单信息接口，一个是写入订单信息接口。在高并发业务场景中，两个接口都会占用资源，如果读取接口访问过大，就会影响写入接口的性能。业务中如果我们希望写入订单比较重要，要优先考虑写入订单接口。那就可以利用关联模式；在关联资源上面设置写入接口，资源名设置读取接口就行了；这样就起到了优先写入，一旦写入请求多，就限制读的请求。 第一步：在ProviderSentinelController中添加一个方法：    @GetMapping("/sentinel02")    public String doSentinel02(){      return "sentinel 02 test  ...";    } 1 2 3 4 第二步：在sentinel中做限流设计： 第三步：打开两个测试窗口，对/provider/sentinel02进行访问，检查/provider/sentinel01的状态： 链路模式 链路模式只记录指定链路入口的流量。也就是当多个服务对指定资源调用时，假如流量超出了指定阈值，则进行限流。被调用的方法用@SentinelResource进行注解，然后分别用不同业务方法对此业务进行调用，假如A业务设置了链路模式的限流,在B业务中是不受影响的。 第一步:在指定包创建一个ResourceService类: package com.jt.provider.service; @Service public class ResourceService{     @SentinelResource("doGetResource")     public String doGetResource(){         return "doGetResource";     } } 1 2 3 4 5 6 7 8 第二步:在ProviderSentinelController中添加一个方法: @Autowired private ResourceService resourceService; @GetMapping("/sentinel03") public String deSentinel03(){     resourceService.doGetResource();     return "test Sentinel 03"; } @GetMapping("/sentinel04") public String deSentinel04(){     resourceService.doGetResource();     return "test Sentinel 04"; } 1 2 3 4 5 6 7 8 9 10 11 12 第三步:在sentinel中配置限流规则: 设置链路流控规则后，再频繁对限流链路进行访问，检测是否会出现500异常: 说明，流控模式为链路模式时，假如是sentinel 1.7.2以后版本，Sentinel Web过滤器默认会聚合所有URL的入口为sentinel_spring_web_context，因此单独对指定链路限流会不生效，需要在application.yml添加如下语句来关闭URL PATH聚合： sentinel:      web-context-unify: false 1 2 对provider/sentinel03限流，对04不限流设置： 测试对03限流，对04不限流 当我们也可以基于@SentinelResource注解描述的方法进行限流后的异常进行自定义处理: 第一步:定义BlockHandlerClass： /**  * 基于ResourceBlockHandler中的相关方法（例如call方法），  * 如果@SentinelResource注解描述的方法上出现的限流异常。  * 方法的返回  * 值类型为@SentinelResource注解描述的返回值类型,  * 方法的其他参数为@SentinelResource注解描述的方法参数,  * 并且此方法必须为静态方法  */ @Slf4j @Component public class ResourceBlockHandler {     /**      * 此方法中的异常类型必须为BlockException类型      * (它是所有限流,降级等异常的父类类型),      * */     public static String call(BlockException ex) {         log.error("block exception {}", "@SentinelResource 描述的方法执行时限流了" + ex.getMessage());         return "访问太频繁了,稍等片刻再访问";     } } 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 第二步:修改@SentinelResource注解中的属性定义： 1.value属性的值用于作为链路节点的名称（自己随意定义） 2.blockHandlerClass用于指定处理链路限流异常的类型 3.blockHandler用于指定blockHandlerClass属性指定的类型中的异常处理方法 @Service public class ResourceService {     @SentinelResource(value = "doGetResource111",                       blockHandlerClass = ResourceBlockHandler.class,                       blockHandler = "call")     public String doGetResource(){         //...         return "do Get Resource";     } } 1 2 3 4 5 6 7 8 9 10 第三步:在controller方法中,调用@Sentinel注解描述的方法： @GetMapping("/sentinel04") public String deSentinel04(){     return resourceService.doGetResource(); } 1 2 3 4 第四步测试： 6.自定义拦截器 拦截器原理： 自定义一个拦截器： /**  * 遵循SpringMVC规范，自定义拦截器，对要访问controller方法的请求进行拦截  * 然后基于乐舞进行预处理，例如进行时间访问控制  */ public class TimeInterceptor implements HandlerInterceptor {     /**      * 此方法会在目标controller方法执行之前执行      * handler对象，对应目标controller      * 返回结果决定此请求是否放行，false=不放行，true=放行      */     @Override     public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {         System.out.println("===preHandle===");         response.setStatus(429);         LocalTime now = LocalTime.now();         int hour = now.getHour();         if (hour < 9 || hour > 18) {         throw new RuntimeException("请在9-18点之间访问");         }         return true;     } } 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 配置拦截器： @Configuration public class SpringWebConfig implements WebMvcConfigurer {     /**      * 注册拦截器，并定义拦截规则      * registry 负责注册拦截器的对象      * */     @Override     public void addInterceptors(InterceptorRegistry registry) {         registry.addInterceptor(new TimeInterceptor())//注册拦截器                 .addPathPatterns("/provider/sentinel01"); //定义要拦截的请求     } } 1 2 3 4 5 6 7 8 9 10 11 12 7.Sentinel降级应用 7.1概述 除了流量控制外，对调用链路中不稳定资源进行熔断降级可以保障高可用。由于调用关系的复杂性，如果调用链路中的某个资源不稳定，最终会导致请求发生堆积。 7.2Sentinel降级入门 准备： 在ProviderController 类中添加doSentinel04方法,基于此方法演示慢调用过程下的限流： /**  * 通过此方法模拟慢调用，或不稳定资源（经常出异常）  * AtomicXxx 底层基于CAS算法（乐观锁方式）保证了线程安全和性能  */ private AtomicInteger atomicInteger = new AtomicInteger(1); //初始值1 @GetMapping("/sentinel05") public String deSentinel05() throws InterruptedException {     int count = atomicInteger.getAndIncrement();//先取值，再递增     if (count %2 == 0) {         Thread.sleep(200);  //模拟耗时     }     return "test Sentinel 05"; } 1 2 3 4 5 6 7 8 9 10 11 12 13 14 这里表示熔断策略选择"慢调用比例"，表示请求数超过3时，假如平均响应时间超过200毫秒的有30%，则对请求进行熔断，熔断时长为10秒钟，10秒以后恢复正常。 我们也可以进行断点调试，在DefaultBlockExceptionHandler中的handle方法内部加断点，分析异常类型，假如异常类型DegradeException则为降级熔断。 7.3Sentinel 异常处理 系统提供了默认的异常处理机制，假如默认处理机制不满足我们需求，我们可以自己进行定义。定义方式上可以直接或间接实现BlockExceptionHandler接口，并将对象交给spring管理。 //@Lazy   //无用，系统底层在构建实现类的方法 @Component public class SentinelBlockExceptionHandler implements BlockExceptionHandler { /*    public SentinelBlockExceptionHandler(){         System.out.println("==SentinelBlockExceptionHandler==");     }*/     @Override     public void handle(HttpServletRequest request,                        HttpServletResponse response,                        BlockException e) throws Exception {         //设置响应编码         response.setCharacterEncoding("utf-8");         //告诉浏览器向它响应的内容类型及编码方式         response.setContentType("text/html;charset=utf-8");         response.setStatus(429);         PrintWriter out = response.getWriter();         Map<String, Object> map = new HashMap<>();         map.put("status", 429);         String msg = "Blocked by Sentinel(flow limiting)";         if (e instanceof DegradeException) {             msg = "服务不稳定，稍后再试";         } else if (e instanceof FlowException) {             msg = "服务访问太频繁，限流了";         }         map.put("msg", msg);         //ObjectMapper对象属于jackson api，这组api在spring-boot-starter-web         //writeValueAsString将map集合转为json串         String jsonResult = new ObjectMapper().writeValueAsString(map);         out.print(jsonResult);         out.flush();         out.close();     } } 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 8.Sentinel热点规则分析（重点） 热点即经常访问的数据。 热点参数限流会统计传入参数中的热点数据，并**根据配置的限流阈值与模式，对包含热点参数的资源调用进行限流。**热点参数限流可以看做是一种特殊的流量控制，仅对包含热点参数的资源调用生效。其中，Sentinel会利用 LRU 策略统计最近最常访问的热点参数，结合令牌桶算法来进行参数级别的流控。 8.1快速入门 第一步：在sca-provider中添加如下方法： @GetMapping("/sentinel07") @SentinelResource("resource") public String doFindById(@RequestParam("id") Integer id){     return "resource id is " + id; } 1 2 3 4 5 第二步：服务启动后，选择要限流的热点链路： 第三步：设置要限流的热点： 热点规则的限流模式只有QPS模式（这才叫热点）。**参数索引为@SentinelResource注解的方法参数下标，0代表第一个参数，1代表第二个参数。**单机阈值以及统计窗口时长表示在此窗口时间超过阈值就限流。 第四步：多次访问热点参数方法，前端会出现如下界面: 后台： 8.2特定参数设计 9.Sentinel系统规则（了解） 系统在生产环境运行过程中，我们经常需要监控服务器的状态，看服务器CPU、内存、IO等的使用率；主要目的就是保证服务器正常的运行，不能被某些应用搞崩溃了；而且在保证稳定的前提下，保持系统的最大吞吐量。 9.1快速入门 Sentinel的系统保护规则是从应用级别的入口流量进行控制，从单台机器的总体 Load（负载）、RT（响应时间）、入口 QPS 、线程数和CPU使用率五个维度监控应用数据，让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。 9.2系统规则是一种全局设计规则 Load（仅对 Linux/Unix-like 机器生效）：当系统 load1超过阈值，且系统当前的并发线程数超过系统容量时才会触发系统保护。系统容量由系统的 maxQps * minRt计算得出。设定参考值一般是 CPU cores * 2.5。 CPU使用率：当系统 CPU 使用率超过阈值即触发系统保护（取值范围 0.0-1.0）。 RT：当单台机器上所有入口流量的平均 RT 达到阈值即触发系统保护，单位是毫秒。 线程数：当单台机器上所有入口流量的并发线程数达到阈值即触发系统保护。 入口 QPS：当单台机器上所有入口流量的 QPS 达到阈值即触发系统保护。 10.Sentinel授权规则(重要) 10.1黑白名单介绍 可以使用sentinel的黑白名单控制功能。 黑白名单根据资源的请求来源（origin）限制资源是否通过，若配置白名单则只有请求来源位于白名单内时才可通过；若配置黑名单则请求来源位于黑名单时不通过，其余的请求通过。 sentinel可以基于黑白名单方式进行授权规则设计 黑白名单规则（AuthorityRule），主要有以下配置项： 资源名:即限流规则的作用对象 流控应用:对应的黑名单/白名单中设置的规则值,多个值用逗号隔开 授权类型:白名单，黑名单(不允许访问) 10.2实现案例 定义请求解析器,用于对请求进行解析,并返回解析结果,sentinel底层在拦截到用户请求以后,会对请求数据基于此对象进行解析,判定是否符合黑白名单规则 第一步:定义RequestOriginParser接口的实现类，在接口方法中解析请求参数数据并返回,底层会基于此返回值进行授权规则应用。 下列方法的返回值会与授权规则黑、白名单值进行比对。 public class DefaultRequestOriginParser implements RequestOriginParser {     @Override     public String parseOrigin(HttpServletRequest request) {         //这里的参数名会与请求中的参数名一致         String origin = request.getParameter("origin");         return origin;     } } 1 2 3 4 5 6 7 8 第二步:定义流控规则： 第三步:执行资源访问,检测授权规则应用,当我们配置的流控应用值为app1时，假如规则为黑名单，则基于 http://ip:port/path?origin=app1的请求不可以通过: 10.3基于请求ip等方式进行黑白名单的规则设计 第一步: 修改请求解析器,获取请求ip并返回: @Component public class DefaultRequestOriginParser  implements RequestOriginParser {     //解析请求源数据     @Override     public String parseOrigin(HttpServletRequest request) {         //获取访问请求中的ip地址,基于ip地址进行黑白名单设计（例如在流控应用栏写ip地址）         String ip= request.getRemoteAddr();         System.out.println("ip="+ip);         return ip;     }//授权规则中的黑白名单的值,来自此方法的返回值 } 1 2 3 4 5 6 7 8 9 10 11 第二步:在sentinel控制台定义授权规则: 第三步:规则定义后以后,基于你的ip地址,进行访问测试,检测黑白名单效果: ———————————————— 版权声明：本文为CSDN博主「Sun.niss」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/qq_45932374/article/details/122122786

3 几种降级策略

我们通常用以下几种降级策略：

• 平均响应时间 (DEGRADE_GRADE_RT)：

  当资源的平均响应时间超过阈值（DegradeRule 中的 count，以 ms 为单位）之后，资源进入准降级状态。如果接下来 1s 内持续进入 5 个请求（即 QPS >= 5），它们的 RT 都持续超过这个阈值，那么在接下的时间窗口（DegradeRule 中的 timeWindow，以 s 为单位）之内，对这个方法的调用都会自动地熔断（抛出 DegradeException）。

  注意 Sentinel 默认统计的 RT 上限是 4900 ms，超出此阈值的都会算作 4900 ms，若需要变更此上限可以通过启动配置项 -Dcsp.sentinel.statistic.max.rt=xxx 来配置。

• 异常比例 (DEGRADE_GRADE_EXCEPTION_RATIO)：

  当资源的每秒异常总数占通过量的比值超过阈值（DegradeRule 中的 count）之后，资源进入降级状态，即在接下的时间窗口（DegradeRule 中的 timeWindow，以 s 为单位）之内，对这个方法的调用都会自动地返回。

  异常比率的阈值范围是 [0.0, 1.0]，代表 0% - 100%。

• 异常数 (DEGRADE_GRADE_EXCEPTION_COUNT)：

  当资源近 1 分钟的异常数目超过阈值之后会进行熔断。

  注意由于统计时间窗口是分钟级别的，若 timeWindow 小于 60s，则结束熔断状态后仍可能再进入熔断状态。

4 熔断降级代码实现

可以通过调用 DegradeRuleManager.loadRules() 方法来用硬编码的方式定义流量控制规则。

@PostConstruct public void initSentinelRule() { //熔断规则： 5s内调用接口出现异常次数超过5的时候, 进行熔断 List<DegradeRule> degradeRules = new ArrayList<>(); DegradeRule rule = new DegradeRule(); rule.setResource("queryGoodsInfo"); rule.setCount(5); rule.setGrade(RuleConstant.DEGRADE_GRADE_EXCEPTION_COUNT);//熔断规则 rule.setTimeWindow(5); degradeRules.add(rule); DegradeRuleManager.loadRules(degradeRules); }

具体源码，请参见疯狂创客圈crazy-springcloud 源码工程

5 控制台降级规则

配置

参数

Field	说明	默认值
resource	资源名，即限流规则的作用对象
count	阈值
grade	降级模式，根据 RT 降级还是根据异常比例降级	RT
timeWindow	降级的时间，单位为 s

6 与Hystrix的熔断对比：

Hystrix常用的线程池隔离会造成线程上下切换的overhead比较大；Hystrix使用的信号量隔离对某个资源调用的并发数进行控制，效果不错，但是无法对慢调用进行自动降级；

Sentinel通过并发线程数的流量控制提供信号量隔离的功能；此外，Sentinel支持的熔断降级维度更多，可对多种指标进行流控、熔断，且提供了实时监控和控制面板，功能更为强大。

4 Sentinel 流控（限流）

流量控制(Flow Control)，原理是监控应用流量的QPS或并发线程数等指标，当达到指定阈值时对流量进行控制，避免系统被瞬时的流量高峰冲垮，保障应用高可用性。

通过流控规则来指定允许该资源通过的请求次数，例如下面的代码定义了资源 HelloWorld 每秒最多只能通过 20 个请求。 参考的规则定义如下：

private static void initFlowRules(){ List<FlowRule> rules = new ArrayList<>(); FlowRule rule = new FlowRule(); rule.setResource("HelloWorld"); rule.setGrade(RuleConstant.FLOW_GRADE_QPS); // Set limit QPS to 20. rule.setCount(20); rules.add(rule); FlowRuleManager.loadRules(rules); }

一条限流规则主要由下面几个因素组成，我们可以组合这些元素来实现不同的限流效果：

• resource：资源名，即限流规则的作用对象

• count: 限流阈值

• grade: 限流阈值类型（QPS 或并发线程数）

• limitApp: 流控针对的调用来源，若为 default 则不区分调用来源

• strategy: 调用关系限流策略

• controlBehavior: 流量控制效果（直接拒绝、Warm Up、匀速排队）

基本的参数

资源名：唯一名称，默认请求路径

针对来源：Sentinel可以针对调用者进行限流，填写微服务名，默认为default(不区分来源)

阈值类型/单机阈值：

1.QPS：每秒请求数，当前调用该api的QPS到达阈值的时候进行限流

2.线程数：当调用该api的线程数到达阈值的时候，进行限流

是否集群：是否为集群

流控的几种strategy：

1.直接：当api大达到限流条件时，直接限流

2.关联：当关联的资源到达阈值，就限流自己

3.链路：只记录指定路上的流量，指定资源从入口资源进来的流量，如果达到阈值，就进行限流，api级别的限流

4.1 直接失败模式

使用API进行资源定义

/** * 限流实现方式一: 抛出异常的方式定义资源 * * @param orderId * @return */ @ApiOperation(value = "纯代码限流") @GetMapping("/getOrder") @ResponseBody public String getOrder(@RequestParam(value = "orderId", required = false)String orderId) { Entry entry = null; // 资源名 String resourceName = "getOrder"; try { // entry可以理解成入口登记 entry = SphU.entry(resourceName); // 被保护的逻辑, 这里为订单查询接口 return "正常的业务逻辑 OrderInfo :" + orderId; } catch (BlockException blockException) { // 接口被限流的时候, 会进入到这里 log.warn("---getOrder1接口被限流了---, exception: ", blockException); return "接口限流, 返回空"; } finally { // SphU.entry(xxx) 需要与 entry.exit() 成对出现,否则会导致调用链记录异常 if (entry != null) { entry.exit(); } } }

代码限流规则

//限流规则 QPS mode, List<FlowRule> rules = new ArrayList<FlowRule>(); FlowRule rule1 = new FlowRule(); rule1.setResource("getOrder"); // QPS控制在2以内 rule1.setCount(2); // QPS限流 rule1.setGrade(RuleConstant.FLOW_GRADE_QPS); rule1.setLimitApp("default"); rules.add(rule1); FlowRuleManager.loadRules(rules);

网页限流规则配置

选择QPS，直接，快速失败，单机阈值为2。

配置

![流控规则](

参数

Field	说明	默认值
resource	资源名，资源名是限流规则的作用对象
count	限流阈值
grade	限流阈值类型，QPS 或线程数模式	QPS 模式
limitApp	流控针对的调用来源	default，代表不区分调用来源
strategy	判断的根据是资源自身，还是根据其它关联资源 (refResource)，还是根据链路入口	根据资源本身
controlBehavior	流控效果（直接拒绝 / 排队等待 / 慢启动模式）	直接拒绝

测试

频繁刷新请求，1秒访问2次请求，正常，超过设置的阈值，将报默认的错误。

再次的1秒访问2次请求，访问正常。超过2次，访问异常

4.2 关联模式

调用关系包括调用方、被调用方；一个方法又可能会调用其它方法，形成一个调用链路的层次关系。Sentinel 通过 NodeSelectorSlot 建立不同资源间的调用的关系，并且通过 ClusterBuilderSlot 记录每个资源的实时统计信息。

当两个资源之间具有资源争抢或者依赖关系的时候，这两个资源便具有了关联。

比如对数据库同一个字段的读操作和写操作存在争抢，读的速度过高会影响写得速度，写的速度过高会影响读的速度。如果放任读写操作争抢资源，则争抢本身带来的开销会降低整体的吞吐量。可使用关联限流来避免具有关联关系的资源之间过度的争抢.

举例来说，read_db 和 write_db 这两个资源分别代表数据库读写，我们可以给 read_db 设置限流规则来达到写优先的目的。具体的方法：

设置 `strategy` 为 `RuleConstant.STRATEGY_RELATE` 设置 `refResource` 为 `write_db`。 这样当写库操作过于频繁时，读数据的请求会被限流。

还有一个例子，电商的 下订单 和 支付两个操作，需要优先保障 支付， 可以根据 支付接口的 流量阈值，来对订单接口进行限制，从而保护支付的目的。

使用注解进行资源定义

添加2个请求

@SentinelResource(value = "test1", blockHandler = "exceptionHandler") @GetMapping("/test1") public String test1() { log.info(Thread.currentThread().getName() + "\t" + "...test1"); return "-------hello baby，i am test1"; } // Block 异常处理函数，参数最后多一个 BlockException，其余与原函数一致. public String exceptionHandler(BlockException ex) { // Do some log here. ex.printStackTrace(); log.info(Thread.currentThread().getName() + "\t" + "...exceptionHandler"); return String.format("error: test1 is not OK"); } @SentinelResource(value = "test1_ref") @GetMapping("/test1_ref") public String test1_ref() { log.info(Thread.currentThread().getName() + "\t" + "...test1_related"); return "-------hello baby，i am test1_ref"; }

代码配置关联限流规则

// 关联模式流控 QPS控制在1以内 String refResource = "test1_ref"; FlowRule rRule = new FlowRule("test1") .setCount(1) // QPS控制在1以内 .setStrategy(RuleConstant.STRATEGY_RELATE) .setRefResource(refResource); rules.add(rRule); FlowRuleManager.loadRules(rules);

网页限流规则配置

测试

选择QPS，单机阈值为1，选择关联，关联资源为/test_ref，这里用Jmeter模拟高并发，请求/test_ref。

在大批量线程高并发访问/test_ref，导致/test失效了

链路类型的关联也类似，就不再演示了。多个请求调用同一微服务。

4.3 Warm up（预热）模式

当流量突然增大的时候，我们常常会希望系统从空闲状态到繁忙状态的切换的时间长一些。即如果系统在此之前长期处于空闲的状态，我们希望处理请求的数量是缓步的增多，经过预期的时间以后，到达系统处理请求个数的最大值。Warm Up（冷启动，预热）模式就是为了实现这个目的的。

默认 coldFactor 为 3，即请求 QPS 从 threshold / 3 开始，经预热时长逐渐升至设定的 QPS 阈值。

使用注解定义资源

@SentinelResource(value = "testWarmUP", blockHandler = "exceptionHandlerOfWarmUp") @GetMapping("/testWarmUP") public String testWarmUP() { log.info(Thread.currentThread().getName() + "\t" + "...test1"); return "-------hello baby，i am testWarmUP"; }

代码限流规则

FlowRule warmUPRule = new FlowRule(); warmUPRule.setResource("testWarmUP"); warmUPRule.setCount(20); warmUPRule.setGrade(RuleConstant.FLOW_GRADE_QPS); warmUPRule.setLimitApp("default"); warmUPRule.setControlBehavior(RuleConstant.CONTROL_BEHAVIOR_WARM_UP); warmUPRule.setWarmUpPeriodSec(10);

网页限流规则配置

先在单机阈值10/3，3的时候，预热10秒后，慢慢将阈值升至20。刚开始刷/testWarmUP，会出现默认错误，预热时间到了后，阈值增加，没超过阈值刷新，请求正常。

通常冷启动的过程系统允许通过的 QPS 曲线如下图所示：

如秒杀系统在开启瞬间，会有很多流量上来，很可能把系统打死，预热方式就是为了保护系统，可慢慢的把流量放进来，慢慢的把阈值增长到设置的阈值。

通过jmeter进行测试

4.4 排队等待模式

匀速排队（RuleConstant.CONTROL_BEHAVIOR_RATE_LIMITER）方式会严格控制请求通过的间隔时间，也即是让请求以均匀的速度通过，对应的是漏桶算法。阈值必须设置为QPS。

这种方式主要用于处理间隔性突发的流量，例如消息队列。想象一下这样的场景，在某一秒有大量的请求到来，而接下来的几秒则处于空闲状态，我们希望系统能够在接下来的空闲期间逐渐处理这些请求，而不是在第一秒直接拒绝多余的请求。

某瞬时来了大流量的请求, 而如果此时要处理所有请求，很可能会导致系统负载过高，影响稳定性。但其实可能后面几秒之内都没有消息投递，若直接把多余的消息丢掉则没有充分利用系统处理消息的能力。Sentinel的Rate Limiter模式能在某一段时间间隔内以匀速方式处理这样的请求, 充分利用系统的处理能力, 也就是削峰填谷, 保证资源的稳定性.

Sentinel会以固定的间隔时间让请求通过, 访问资源。当请求到来的时候，如果当前请求距离上个通过的请求通过的时间间隔不小于预设值，则让当前请求通过；否则，计算当前请求的预期通过时间，如果该请求的预期通过时间小于规则预设的 timeout 时间，则该请求会等待直到预设时间到来通过；反之，则马上抛出阻塞异常。

使用Sentinel的这种策略, 简单点说, 就是使用一个时间段(比如20s的时间)处理某一瞬时产生的大量请求, 起到一个削峰填谷的作用, 从而充分利用系统的处理能力, 下图能很形象的展示这种场景: X轴代表时间, Y轴代表系统处理的请求.

示例

模拟2个用户同时并发的访问资源，发出100个请求,

如果设置QPS阈值为1, 拒绝策略修改为Rate Limiter匀速RuleConstant.CONTROL_BEHAVIOR_RATE_LIMITER方式, 还需要设置setMaxQueueingTimeMs(20 * 1000)表示每一请求最长等待时间, 这里等待时间大一点, 以保证让所有请求都能正常通过;

假设这里设置的排队等待时间过小的话, 导致排队等待的请求超时而抛出异常BlockException, 最终结果可能是这100个并发请求中只有一个请求或几个才能正常通过, 所以使用这种模式得根据访问资源的耗时时间决定排队等待时间. 按照目前这种设置, QPS阈值为10的话, 每一个请求相当于是以匀速100ms左右通过.

使用注解定义资源

@SentinelResource(value = "testLineUp", blockHandler = "exceptionHandlerOftestLineUp") @GetMapping("/testLineUp") public String testLineUp() { log.info(Thread.currentThread().getName() + "\t" + "...test1"); return "-------hello baby，i am testLineUp"; }

代码限流规则

FlowRule lineUpRule = new FlowRule(); lineUpRule.setResource("testLineUp"); lineUpRule.setCount(10); lineUpRule.setGrade(RuleConstant.FLOW_GRADE_QPS); lineUpRule.setLimitApp("default"); lineUpRule.setMaxQueueingTimeMs(20 * 1000); // CONTROL_BEHAVIOR_DEFAULT means requests more than threshold will be rejected immediately. // CONTROL_BEHAVIOR_DEFAULT将超过阈值的流量立即拒绝掉. lineUpRule.setControlBehavior(RuleConstant.CONTROL_BEHAVIOR_RATE_LIMITER); rules.add(lineUpRule);

网页限流规则配置

通过jmeter进行测试

4.5 热点规则 (ParamFlowRule)

何为热点？热点即经常访问的数据。很多时候我们希望统计某个热点数据中访问频次最高的 Top K 数据，并对其访问进行限制。比如：

• 商品 ID 为参数，统计一段时间内最常购买的商品 ID 并进行限制
• 用户 ID 为参数，针对一段时间内频繁访问的用户 ID 进行限制 热点参数限流会统计传入参数中的热点参数，并根据配置的限流阈值与模式，对包含热点参数的资源调用进行限流。热点参数限流可以看做是一种特殊的流量控制，仅对包含热点参数的资源调用生效。 使用该规则需要引入依赖：

热点参数规则（ParamFlowRule）类似于流量控制规则（FlowRule）：

属性	说明	默认值
resource	资源名，必填
count	限流阈值，必填
grade	限流模式	QPS 模式
durationInSec	统计窗口时间长度（单位为秒），1.6.0 版本开始支持	1s
controlBehavior	流控效果（支持快速失败和匀速排队模式），1.6.0 版本开始支持	快速失败
maxQueueingTimeMs	最大排队等待时长（仅在匀速排队模式生效），1.6.0 版本开始支持	0ms
paramIdx	热点参数的索引，必填，对应 SphU.entry(xxx, args) 中的参数索引位置
paramFlowItemList	参数例外项，可以针对指定的参数值单独设置限流阈值，不受前面 count 阈值的限制。仅支持基本类型和字符串类型
clusterMode	是否是集群参数流控规则	false
clusterConfig	集群流控相关配置

自定义资源

@GetMapping("/byHotKey") @SentinelResource(value = "byHotKey", blockHandler = "userAccessError") public String test4(@RequestParam(value = "userId", required = false) String userId, @RequestParam(value = "goodId", required = false) int goodId) { log.info(Thread.currentThread().getName() + "\t" + "...byHotKey"); return "-----------by HotKey： UserId"; }

限流规则代码：

可以通过 ParamFlowRuleManager 的 loadRules 方法更新热点参数规则，下面是官方实例：

ParamFlowRule rule = new ParamFlowRule(resourceName) .setParamIdx(0) .setCount(5); // 针对 int 类型的参数 PARAM_B，单独设置限流 QPS 阈值为 10，而不是全局的阈值 5. ParamFlowItem item = new ParamFlowItem().setObject(String.valueOf(PARAM_B)) .setClassType(int.class.getName()) .setCount(10); rule.setParamFlowItemList(Collections.singletonList(item)); ParamFlowRuleManager.loadRules(Collections.singletonList(rule));

具体的限流代码如下：

ParamFlowRule pRule = new ParamFlowRule("byHotKey") .setParamIdx(1) .setCount(1); // 针对 参数值1000，单独设置限流 QPS 阈值为 5，而不是全局的阈值 1. ParamFlowItem item = new ParamFlowItem().setObject(String.valueOf(1000)) .setClassType(int.class.getName()) .setCount(5); pRule.setParamFlowItemList(Collections.singletonList(item)); ParamFlowRuleManager.loadRules(Collections.singletonList(pRule));

网页限流规则配置

5. Sentinel 系统保护

系统保护的目的

在开始之前，我们先了解一下系统保护的目的：

• 保证系统不被拖垮
• 在系统稳定的前提下，保持系统的吞吐量

长期以来，系统保护的思路是根据硬指标，即系统的负载 (load1) 来做系统过载保护。当系统负载高于某个阈值，就禁止或者减少流量的进入；当 load 开始好转，则恢复流量的进入。这个思路给我们带来了不可避免的两个问题：

• load 是一个“结果”，如果根据 load 的情况来调节流量的通过率，那么就始终有延迟性。也就意味着通过率的任何调整，都会过一段时间才能看到效果。当前通过率是使 load 恶化的一个动作，那么也至少要过 1 秒之后才能观测到；同理，如果当前通过率调整是让 load 好转的一个动作，也需要 1 秒之后才能继续调整，这样就浪费了系统的处理能力。所以我们看到的曲线，总是会有抖动。
• 恢复慢。想象一下这样的一个场景（真实），出现了这样一个问题，下游应用不可靠，导致应用 RT 很高，从而 load 到了一个很高的点。过了一段时间之后下游应用恢复了，应用 RT 也相应减少。这个时候，其实应该大幅度增大流量的通过率；但是由于这个时候 load 仍然很高，通过率的恢复仍然不高。

系统保护的目标是 在系统不被拖垮的情况下，提高系统的吞吐率，而不是 load 一定要到低于某个阈值。如果我们还是按照固有的思维，超过特定的 load 就禁止流量进入，系统 load 恢复就放开流量，这样做的结果是无论我们怎么调参数，调比例，都是按照果来调节因，都无法取得良好的效果。

Sentinel 在系统自适应保护的做法是，用 load1 作为启动自适应保护的因子，而允许通过的流量由处理请求的能力，即请求的响应时间以及当前系统正在处理的请求速率来决定。

系统保护规则的应用

系统规则支持以下的模式：

• 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 达到阈值即触发系统保护。

系统保护规则是从应用级别的入口流量进行控制，从单台机器的 load、CPU 使用率、平均 RT、入口 QPS 和并发线程数等几个维度监控应用指标，让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。

系统保护规则是应用整体维度的，而不是资源维度的，并且仅对入口流量生效。入口流量指的是进入应用的流量（EntryType.IN），比如 Web 服务或 Dubbo 服务端接收的请求，都属于入口流量。

系统规则的参数说明:

• highestSystemLoad 最大的 load1，参考值 -1 (不生效)
• avgRt 所有入口流量的平均响应时间 -1 (不生效)
• maxThread 入口流量的最大并发数 -1 (不生效)
• qps 所有入口资源的 QPS -1 (不生效)

硬编码的方式定义流量控制规则如下：

List<SystemRule> srules = new ArrayList<>(); SystemRule srule = new SystemRule(); srule.setAvgRt(3000); srules.add(srule); SystemRuleManager.loadRules(srules);

网页限流规则配置

6 黑白名单规则

很多时候，我们需要根据调用方来限制资源是否通过，这时候可以使用 Sentinel 的访问控制（黑白名单）的功能。黑白名单根据资源的请求来源（origin）限制资源是否通过，若配置白名单则只有请求来源位于白名单内时才可通过；若配置黑名单则请求来源位于黑名单时不通过，其余的请求通过。

调用方信息通过 ContextUtil.enter(resourceName, origin) 方法中的 origin 参数传入。

访问控制规则 (AuthorityRule)

授权规则，即黑白名单规则（AuthorityRule）非常简单，主要有以下配置项：

• resource：资源名，即限流规则的作用对象
• limitApp：对应的黑名单/白名单，不同 origin 用 , 分隔，如 appA,appB
• strategy：限制模式，AUTHORITY_WHITE 为白名单模式，AUTHORITY_BLACK 为黑名单模式，默认为白名单模式 比如我们希望控制对资源 test 的访问设置白名单，只有来源为 appA 和 appB 的请求才可通过，则可以配置如下白名单规则：

AuthorityRule rule = new AuthorityRule(); rule.setResource("test"); rule.setStrategy(RuleConstant.AUTHORITY_WHITE); rule.setLimitApp("appA,appB"); AuthorityRuleManager.loadRules(Collections.singletonList(rule));

7 核心组件

Resource

resource是sentinel中最重要的一个概念，sentinel通过资源来保护具体的业务代码或其他后方服务。sentinel把复杂的逻辑给屏蔽掉了，用户只需要为受保护的代码或服务定义一个资源，然后定义规则就可以了，剩下的通通交给sentinel来处理了。并且资源和规则是解耦的，规则甚至可以在运行时动态修改。定义完资源后，就可以通过在程序中埋点来保护你自己的服务了，埋点的方式有两种：

• try-catch 方式（通过 SphU.entry(...)），当 catch 到BlockException时执行异常处理(或fallback)
• if-else 方式（通过 SphO.entry(...)），当返回 false 时执行异常处理(或fallback)

以上这两种方式都是通过硬编码的形式定义资源然后进行资源埋点的，对业务代码的侵入太大，从0.1.1版本开始，sentinel加入了注解的支持，可以通过注解来定义资源，具体的注解为：SentinelResource 。通过注解除了可以定义资源外，还可以指定 blockHandler 和 fallback 方法。

在sentinel中具体表示资源的类是：ResourceWrapper ，他是一个抽象的包装类，包装了资源的 Name 和EntryType。他有两个实现类，分别是：StringResourceWrapper 和 MethodResourceWrapper。顾名思义，StringResourceWrapper 是通过对一串字符串进行包装，是一个通用的资源包装类，MethodResourceWrapper 是对方法调用的包装。

Context

Context是对资源操作时的上下文环境，每个资源操作(针对Resource进行的entry/exit)必须属于一个Context，如果程序中未指定Context，会创建name为"sentinel_default_context"的默认Context。一个Context生命周期内可能有多个资源操作，Context生命周期内的最后一个资源exit时会清理该Context，这也预示这整个Context生命周期的结束。Context主要属性如下：

public class Context { // context名字，默认名字 "sentinel_default_context" private final String name; // context入口节点，每个context必须有一个entranceNode private DefaultNode entranceNode; // context当前entry，Context生命周期中可能有多个Entry，所有curEntry会有变化 private Entry curEntry; // The origin of this context (usually indicate different invokers, e.g. service consumer name or origin IP). private String origin = ""; private final boolean async; }

注意：一个Context生命期内Context只能初始化一次，因为是存到ThreadLocal中，并且只有在非null时才会进行初始化。

如果想在调用 SphU.entry() 或 SphO.entry() 前，自定义一个context，则通过ContextUtil.enter()方法来创建。context是保存在ThreadLocal中的，每次执行的时候会优先到ThreadLocal中获取，为null时会调用 MyContextUtil.myEnter(Constants.CONTEXT_DEFAULT_NAME, "", resourceWrapper.getType())创建一个context。当Entry执行exit方法时，如果entry的parent节点为null，表示是当前Context中最外层的Entry了，此时将ThreadLocal中的context清空。

Context的创建与销毁

首先我们要清楚的一点就是，每次执行entry()方法，试图冲破一个资源时，都会生成一个上下文。这个上下文中会保存着调用链的根节点和当前的入口。

Context是通过ContextUtil创建的，具体的方法是trueEntry，代码如下：

protected static Context trueEnter(String name, String origin) { // 先从ThreadLocal中获取 Context context = contextHolder.get(); if (context == null) { // 如果ThreadLocal中获取不到Context // 则根据name从map中获取根节点，只要是相同的资源名，就能直接从map中获取到node Map<String, DefaultNode> localCacheNameMap = contextNameNodeMap; DefaultNode node = localCacheNameMap.get(name); if (node == null) { // 省略部分代码 try { LOCK.lock(); node = contextNameNodeMap.get(name); if (node == null) { // 省略部分代码 // 创建一个新的入口节点 node = new EntranceNode(new StringResourceWrapper(name, EntryType.IN), null); Constants.ROOT.addChild(node); // 省略部分代码 } } finally { LOCK.unlock(); } } // 创建一个新的Context，并设置Context的根节点，即设置EntranceNode context = new Context(node, name); context.setOrigin(origin); // 将该Context保存到ThreadLocal中去 contextHolder.set(context); } return context; }

上面的代码中我省略了部分代码，只保留了核心的部分。从源码中还是可以比较清晰的看出生成Context的过程：

• 1.先从ThreadLocal中获取，如果能获取到直接返回，如果获取不到则继续第2步
• 2.从一个static的map中根据上下文的名称获取，如果能获取到则直接返回，否则继续第3步
• 3.加锁后进行一次double check，如果还是没能从map中获取到，则创建一个EntranceNode，并把该EntranceNode添加到一个全局的ROOT节点中去，然后将该节点添加到map中去(这部分代码在上述代码中省略了)
• 4.根据EntranceNode创建一个上下文，并将该上下文保存到ThreadLocal中去，下一个请求可以直接获取

那保存在ThreadLocal中的上下文什么时候会清除呢？从代码中可以看到具体的清除工作在ContextUtil的exit方法中，当执行该方法时，会将保存在ThreadLocal中的context对象清除，具体的代码非常简单，这里就不贴代码了。

那ContextUtil.exit方法什么时候会被调用呢？有两种情况：一是主动调用ContextUtil.exit的时候，二是当一个入口Entry要退出，执行该Entry的trueExit方法的时候，此时会触发ContextUtil.exit的方法。但是有一个前提，就是当前Entry的父Entry为null时，此时说明该Entry已经是最顶层的根节点了，可以清除context。

Entry

刚才在Context身影中也看到了Entry的出现，现在就谈谈Entry。每次执行 SphU.entry() 或 SphO.entry() 都会返回一个Entry，Entry表示一次资源操作，内部会保存当前invocation信息。在一个Context生命周期中多次资源操作，也就是对应多个Entry，这些Entry形成parent/child结构保存在Entry实例中，entry类CtEntry结构如下：

class CtEntry extends Entry { protected Entry parent = null; protected Entry child = null; protected ProcessorSlot<Object> chain; protected Context context; } public abstract class Entry implements AutoCloseable { private long createTime; private Node curNode; /** * {@link Node} of the specific origin, Usually the origin is the Service Consumer. */ private Node originNode; private Throwable error; // 是否出现异常 protected ResourceWrapper resourceWrapper; // 资源信息 }

Entry实例代码中出现了Node，这个又是什么东东呢 😦，咱们接着往下看：

DefaultNode

Node（关于StatisticNode的讨论放到下一小节）默认实现类DefaultNode，该类还有一个子类EntranceNode；context有一个entranceNode属性，Entry中有一个curNode属性。

• EntranceNode：该类的创建是在初始化Context时完成的（ContextUtil.trueEnter方法），注意该类是针对Context维度的，也就是一个context有且仅有一个EntranceNode。
• DefaultNode：该类的创建是在NodeSelectorSlot.entry完成的，当不存在context.name对应的DefaultNode时会新建（new DefaultNode(resourceWrapper, null)，对应resouce）并保存到本地缓存（NodeSelectorSlot中private volatile Map<String, DefaultNode> map）；获取到context.name对应的DefaultNode后会将该DefaultNode设置到当前context的curEntry.curNode属性，也就是说，在NodeSelectorSlot中是一个context有且仅有一个DefaultNode。

看到这里，你是不是有疑问？为什么一个context有且仅有一个DefaultNode，我们的resouece跑哪去了呢，其实，这里的一个context有且仅有一个DefaultNode是在NodeSelectorSlot范围内，NodeSelectorSlot是ProcessorSlotChain中的一环，获取ProcessorSlotChain是根据Resource维度来的。总结为一句话就是：针对同一个Resource，多个context对应多个DefaultNode；针对不同Resource，(不管是否是同一个context)对应多个不同DefaultNode。这还没看明白 : (，好吧，我不bb了，上图吧：

public class DefaultNode extends StatisticNode {
private ResourceWrapper id;
/**
* The list of all child nodes.
* 子节点集合
/
private volatile Set childList = new HashSet<>();
/*
* Associated cluster node.
*/
private ClusterNode clusterNode;
}

一个Resouce只有一个clusterNode，多个defaultNode对应一个clusterNode，如果defaultNode.clusterNode为null，则在ClusterBuilderSlot.entry中会进行初始化。

同一个Resource，对应同一个ProcessorSlotChain，这块处理逻辑在lookProcessChain方法中，如下：

ProcessorSlot lookProcessChain(ResourceWrapper resourceWrapper) {
ProcessorSlotChain chain = chainMap.get(resourceWrapper);
if (chain == null) {
synchronized (LOCK) {
chain = chainMap.get(resourceWrapper);
if (chain == null) {
// Entry size limit.
if (chainMap.size() >= Constants.MAX_SLOT_CHAIN_SIZE) {
return null;
}

chain = SlotChainProvider.newSlotChain(); Map<ResourceWrapper, ProcessorSlotChain> newMap = newHashMap<ResourceWrapper, ProcessorSlotChain>( chainMap.size() + 1); newMap.putAll(chainMap); newMap.put(resourceWrapper, chain); chainMap = newMap; } }

}
return chain;
}

StatisticNode

StatisticNode中保存了资源的实时统计数据（基于滑动时间窗口机制），通过这些统计数据，sentinel才能进行限流、降级等一系列操作。StatisticNode属性如下： public class StatisticNode implements Node { /** * 秒级的滑动时间窗口（时间窗口单位500ms） */ private transient volatile Metric rollingCounterInSecond = newArrayMetric(SampleCountProperty.SAMPLE_COUNT, IntervalProperty.INTERVAL); /** * 分钟级的滑动时间窗口（时间窗口单位1s） */ private transient Metric rollingCounterInMinute = new ArrayMetric(60, 60 * 1000,false); /** * The counter for thread count. 线程个数用户触发线程数流控 */ private LongAdder curThreadNum = new LongAdder(); } public class ArrayMetric implements Metric { private final LeapArray<MetricBucket> data; } public class MetricBucket { // 保存统计值 private final LongAdder[] counters; // 最小rt private volatile long minRt; }

其中MetricBucket.counters数组大小为MetricEvent枚举值的个数，每个枚举对应一个统计项，比如PASS表示通过个数，限流可根据通过的个数和设置的限流规则配置count大小比较，得出是否触发限流操作，所有枚举值如下：

public enum MetricEvent { PASS, // Normal pass. BLOCK, // Normal block. EXCEPTION, SUCCESS, RT, OCCUPIED_PASS }

8 插槽Slot

slot是另一个sentinel中非常重要的概念，sentinel的工作流程就是围绕着一个个插槽所组成的插槽链来展开的。需要注意的是每个插槽都有自己的职责，他们各司其职完好的配合，通过一定的编排顺序，来达到最终的限流降级的目的。默认的各个插槽之间的顺序是固定的，因为有的插槽需要依赖其他的插槽计算出来的结果才能进行工作。

但是这并不意味着我们只能按照框架的定义来，sentinel 通过 SlotChainBuilder 作为 SPI 接口，使得 Slot Chain 具备了扩展的能力。我们可以通过实现 SlotsChainBuilder 接口加入自定义的 slot 并自定义编排各个 slot 之间的顺序，从而可以给 sentinel 添加自定义的功能。

那SlotChain是在哪创建的呢？是在 CtSph.lookProcessChain() 方法中创建的，并且该方法会根据当前请求的资源先去一个静态的HashMap中获取，如果获取不到才会创建，创建后会保存到HashMap中。这就意味着，同一个资源会全局共享一个SlotChain。默认生成ProcessorSlotChain为：

// DefaultSlotChainBuilder public ProcessorSlotChain build() { ProcessorSlotChain chain = new DefaultProcessorSlotChain(); chain.addLast(new NodeSelectorSlot()); chain.addLast(new ClusterBuilderSlot()); chain.addLast(new LogSlot()); chain.addLast(new StatisticSlot()); chain.addLast(new SystemSlot()); chain.addLast(new AuthoritySlot()); chain.addLast(new FlowSlot()); chain.addLast(new DegradeSlot()); return chain;

这里大概的介绍下每种Slot的功能职责：

• NodeSelectorSlot 负责收集资源的路径，并将这些资源的调用路径，以树状结构存储起来，用于根据调用路径来限流降级；
• ClusterBuilderSlot 则用于存储资源的统计信息以及调用者信息，例如该资源的 RT, QPS, thread count 等等，这些信息将用作为多维度限流，降级的依据；
• StatisticsSlot 则用于记录，统计不同维度的 runtime 信息；
• SystemSlot 则通过系统的状态，例如 load1 等，来控制总的入口流量；
• AuthoritySlot 则根据黑白名单，来做黑白名单控制；
• FlowSlot 则用于根据预设的限流规则，以及前面 slot 统计的状态，来进行限流；
• DegradeSlot 则通过统计信息，以及预设的规则，来做熔断降级；

每个Slot执行完业务逻辑处理后，会调用fireEntry()方法，该方法将会触发下一个节点的entry方法，下一个节点又会调用他的fireEntry，以此类推直到最后一个Slot，由此就形成了sentinel的责任链。

下面我们就来详细研究下这些Slot的原理。

NodeSelectorSlot

NodeSelectorSlot 是用来构造调用链的，具体的是将资源的调用路径，封装成一个一个的节点，再组成一个树状的结构来形成一个完整的调用链，NodeSelectorSlot是所有Slot中最关键也是最复杂的一个Slot，这里涉及到以下几个核心的概念：

• Resource

资源是 Sentinel 的关键概念。它可以是 Java 应用程序中的任何内容，例如，由应用程序提供的服务，或由应用程序调用的其它服务，甚至可以是一段代码。

只要通过 Sentinel API 定义的代码，就是资源，能够被 Sentinel 保护起来。大部分情况下，可以使用方法签名，URL，甚至服务名称作为资源名来标示资源。

简单来说，资源就是 Sentinel 用来保护系统的一个媒介。源码中用来包装资源的类是：com.alibaba.csp.sentinel.slotchain.ResourceWrapper，他有两个子类：StringResourceWrapper 和 MethodResourceWrapper，通过名字就知道可以将一段字符串或一个方法包装为一个资源。

打个比方，我有一个服务A，请求非常多，经常会被陡增的流量冲垮，为了防止这种情况，简单的做法，我们可以定义一个 Sentinel 的资源，通过该资源来对请求进行调整，使得允许通过的请求不会把服务A搞崩溃。

每个资源的状态也是不同的，这取决于资源后端的服务，有的资源可能比较稳定，有的资源可能不太稳定。那么在整个调用链中，Sentinel 需要对不稳定资源进行控制。当调用链路中某个资源出现不稳定，例如，表现为 timeout，或者异常比例升高的时候，则对这个资源的调用进行限制，并让请求快速失败，避免影响到其它的资源，最终导致雪崩的后果。

• Context

上下文是一个用来保存调用链当前状态的元数据的类，每次进入一个资源时，就会创建一个上下文。相同的资源名可能会创建多个上下文。一个Context中包含了三个核心的对象：

1）当前调用链的根节点：EntranceNode

2）当前的入口：Entry

3）当前入口所关联的节点：Node

上下文中只会保存一个当前正在处理的入口Entry，另外还会保存调用链的根节点。需要注意的是，每次进入一个新的资源时，都会创建一个新的上下文。

• Entry

每次调用 SphU#entry() 都会生成一个Entry入口，该入口中会保存了以下数据：入口的创建时间，当前入口所关联的节点，当前入口所关联的调用源对应的节点。Entry是一个抽象类，他只有一个实现类，在CtSph中的一个静态类：CtEntry

• Node

节点是用来保存某个资源的各种实时统计信息的，他是一个接口，通过访问节点，就可以获取到对应资源的实时状态，以此为依据进行限流和降级操作。

可能看到这里，大家还是比较懵，这么多类到底有什么用，接下来就让我们更进一步，挖掘一下这些类的作用，在这之前，我先给大家展示一下他们之间的关系，如下图所示：

这里把几种Node的作用先大概介绍下：

节点	作用
StatisticNode	执行具体的资源统计操作
DefaultNode	该节点持有指定上下文中指定资源的统计信息，当在同一个上下文中多次调用entry方法时，该节点可能下会创建有一系列的子节点。 另外每个DefaultNode中会关联一个ClusterNode
ClusterNode	该节点中保存了资源的总体的运行时统计信息，包括rt，线程数，qps等等，相同的资源会全局共享同一个ClusterNode，不管他属于哪个上下文
EntranceNode	该节点表示一棵调用链树的入口节点，通过他可以获取调用链树中所有的子节点

调用链树

当在一个上下文中多次调用了 SphU#entry() 方法时，就会创建一棵调用链树。具体的代码在entry方法中创建CtEntry对象时：

CtEntry(ResourceWrapper resourceWrapper, ProcessorSlot<Object> chain, Context context) { super(resourceWrapper); this.chain = chain; this.context = context; // 获取「上下文」中上一次的入口 parent = context.getCurEntry(); if (parent != null) { // 然后将当前入口设置为上一次入口的子节点 ((CtEntry)parent).child = this; } // 设置「上下文」的当前入口为该类本身 context.setCurEntry(this); }

这里可能看代码没有那么直观，可以用一些图形来描述一下这个过程。

构造树干

创建context

context的创建在上面已经分析过了，初始化的时候，context中的curEntry属性是没有值的，如下图所示：

创建Entry

每创建一个新的Entry对象时，都会重新设置context的curEntry，并将context原来的curEntry设置为该新Entry对象的父节点，如下图所示：

退出Entry

某个Entry退出时，将会重新设置context的curEntry，当该Entry是最顶层的一个入口时，将会把ThreadLocal中保存的context也清除掉，如下图所示：

构造叶子节点

上面的过程是构造了一棵调用链的树，但是这棵树只有树干，没有叶子，那叶子节点是在什么时候创建的呢？DefaultNode就是叶子节点，在叶子节点中保存着目标资源在当前状态下的统计信息。通过分析，我们知道了叶子节点是在NodeSelectorSlot的entry方法中创建的。具体的代码如下：

@Override public void entry(Context context, ResourceWrapper resourceWrapper, Object obj, int count, Object... args) throws Throwable { // 根据「上下文」的名称获取DefaultNode // 多线程环境下，每个线程都会创建一个context， // 只要资源名相同，则context的名称也相同，那么获取到的节点就相同 DefaultNode node = map.get(context.getName()); if (node == null) { synchronized (this) { node = map.get(context.getName()); if (node == null) { // 如果当前「上下文」中没有该节点，则创建一个DefaultNode节点 node = Env.nodeBuilder.buildTreeNode(resourceWrapper, null); // 省略部分代码 } // 将当前node作为「上下文」的最后一个节点的子节点添加进去 // 如果context的curEntry.parent.curNode为null，则添加到entranceNode中去 // 否则添加到context的curEntry.parent.curNode中去 ((DefaultNode)context.getLastNode()).addChild(node); } } // 将该节点设置为「上下文」中的当前节点 // 实际是将当前节点赋值给context中curEntry的curNode // 在Context的getLastNode中会用到在此处设置的curNode context.setCurNode(node); fireEntry(context, resourceWrapper, node, count, args); }

上面的代码可以分解成下面这些步骤：
1）获取当前上下文对应的DefaultNode，如果没有的话会为当前的调用新生成一个DefaultNode节点，它的作用是对资源进行各种统计度量以便进行流控；
2）将新创建的DefaultNode节点，添加到context中，作为「entranceNode」或者「curEntry.parent.curNode」的子节点；
3）将DefaultNode节点，添加到context中，作为「curEntry」的curNode。

上面的第2步，不是每次都会执行。我们先看第3步，把当前DefaultNode设置为context的curNode，实际上是把当前节点赋值给context中curEntry的curNode，用图形表示就是这样：

多次创建不同的Entry，并且执行NodeSelectorSlot的entry方法后，就会变成这样一棵调用链树：

PS：这里图中的node0，node1，node2可能是相同的node，因为在同一个context中从map中获取的node是同一个，这里只是为了表述的更清楚所以用了不同的节点名。

保存子节点

上面已经分析了叶子节点的构造过程，叶子节点是保存在各个Entry的curNode属性中的。

我们知道context中只保存了入口节点和当前Entry，那子节点是什么时候保存的呢，其实子节点就是上面代码中的第2步中保存的。

下面我们来分析上面的第2步的情况：

第一次调用NodeSelectorSlot的entry方法时，map中肯定是没有DefaultNode的，那就会进入第2步中，创建一个node，创建完成后会把该节点加入到context的lastNode的子节点中去。我们先看一下context的getLastNode方法：

public Node getLastNode() { // 如果curEntry不存在时，返回entranceNode // 否则返回curEntry的lastNode， // 需要注意的是curEntry的lastNode是获取的parent的curNode， // 如果每次进入的资源不同，就会每次都创建一个CtEntry，则parent为null， // 所以curEntry.getLastNode()也为null if (curEntry != null && curEntry.getLastNode() != null) { return curEntry.getLastNode(); } else { return entranceNode; } }

代码中我们可以知道，lastNode的值可能是context中的entranceNode也可能是curEntry.parent.curNode，但是他们都是「DefaultNode」类型的节点，DefaultNode的所有子节点是保存在一个HashSet中的。

第一次调用getLastNode方法时，context中curEntry是null，因为curEntry是在第3步中才赋值的。所以，lastNode最初的值就是context的entranceNode。那么将node添加到entranceNode的子节点中去之后就变成了下面这样：

紧接着再进入一次，资源名不同，会再次生成一个新的Entry，上面的图形就变成下图这样：

此时再次调用context的getLastNode方法，因为此时curEntry的parent不再是null了，所以获取到的lastNode是curEntry.parent.curNode，在上图中可以很方便的看出，这个节点就是node0。那么把当前节点node1添加到lastNode的子节点中去，上面的图形就变成下图这样：

然后将当前node设置给context的curNode，上面的图形就变成下图这样：

假如再创建一个Entry，然后再进入一次不同的资源名，上面的图就变成下面这样：

至此NodeSelectorSlot的基本功能已经大致分析清楚了。

PS：以上的分析是基于每次执行SphU.entry(name)时，资源名都是不一样的前提下。如果资源名都一样的话，那么生成的node都相同，则只会再第一次把node加入到entranceNode的子节点中去，其他的时候，只会创建一个新的Entry，然后替换context中的curEntry的值。

ClusterBuilderSlot

NodeSelectorSlot的entry方法执行完之后，会调用fireEntry方法，此时会触发ClusterBuilderSlot的entry方法。

ClusterBuilderSlot的entry方法比较简单，具体代码如下：

@Override public void entry(Context context, ResourceWrapper resourceWrapper, DefaultNode node, int count, Object... args) throws Throwable { if (clusterNode == null) { synchronized (lock) { if (clusterNode == null) { // Create the cluster node. clusterNode = Env.nodeBuilder.buildClusterNode(); // 将clusterNode保存到全局的map中去 HashMap<ResourceWrapper, ClusterNode> newMap = new HashMap<ResourceWrapper, ClusterNode>(16); newMap.putAll(clusterNodeMap); newMap.put(node.getId(), clusterNode); clusterNodeMap = newMap; } } } // 将clusterNode塞到DefaultNode中去 node.setClusterNode(clusterNode); // 省略部分代码 fireEntry(context, resourceWrapper, node, count, args); }

NodeSelectorSlot的职责比较简单，主要做了两件事：

一、为每个资源创建一个clusterNode，然后把clusterNode塞到DefaultNode中去

二、将clusterNode保持到全局的map中去，用资源作为map的key

PS：一个资源只有一个ClusterNode，但是可以有多个DefaultNode

StatistcSlot

StatisticSlot负责来统计资源的实时状态，具体的代码如下：

@Override public void entry(Context context, ResourceWrapper resourceWrapper, DefaultNode node, int count, Object... args) throws Throwable { try { // 触发下一个Slot的entry方法 fireEntry(context, resourceWrapper, node, count, args); // 如果能通过SlotChain中后面的Slot的entry方法，说明没有被限流或降级 // 统计信息 node.increaseThreadNum(); node.addPassRequest(); // 省略部分代码 } catch (BlockException e) { context.getCurEntry().setError(e); // Add block count. node.increaseBlockedQps(); // 省略部分代码 throw e; } catch (Throwable e) { context.getCurEntry().setError(e); // Should not happen node.increaseExceptionQps(); // 省略部分代码 throw e; } } @Override public void exit(Context context, ResourceWrapper resourceWrapper, int count, Object... args) { DefaultNode node = (DefaultNode)context.getCurNode(); if (context.getCurEntry().getError() == null) { long rt = TimeUtil.currentTimeMillis() - context.getCurEntry().getCreateTime(); if (rt > Constants.TIME_DROP_VALVE) { rt = Constants.TIME_DROP_VALVE; } node.rt(rt); // 省略部分代码 node.decreaseThreadNum(); // 省略部分代码 } fireExit(context, resourceWrapper, count); }

代码分成了两部分，第一部分是entry方法，该方法首先会触发后续slot的entry方法，即SystemSlot、FlowSlot、DegradeSlot等的规则，如果规则不通过，就会抛出BlockException，则会在node中统计被block的数量。反之会在node中统计通过的请求数和线程数等信息。第二部分是在exit方法中，当退出该Entry入口时，会统计rt的时间，并减少线程数。

这些统计的实时数据会被后续的校验规则所使用，具体的统计方式是通过 滑动窗口 来实现的。

SystemSlot

SystemSlot就是根据总的请求统计信息，来做流控，主要是防止系统被搞垮，具体的代码如下：

@Override public void entry(Context context, ResourceWrapper resourceWrapper, DefaultNode node, int count, boolean prioritized, Object... args) throws Throwable { SystemRuleManager.checkSystem(resourceWrapper); fireEntry(context, resourceWrapper, node, count, prioritized, args); }

public static void checkSystem(ResourceWrapper resourceWrapper) throws BlockException { if (resourceWrapper == null) { return; } // Ensure the checking switch is on. if (!checkSystemStatus.get()) { return; } // for inbound traffic only if (resourceWrapper.getEntryType() != EntryType.IN) { return; } // total qps double currentQps = Constants.ENTRY_NODE == null ? 0.0 : Constants.ENTRY_NODE.successQps(); if (currentQps > qps) { throw new SystemBlockException(resourceWrapper.getName(), "qps"); } // total thread int currentThread = Constants.ENTRY_NODE == null ? 0 : Constants.ENTRY_NODE.curThreadNum(); if (currentThread > maxThread) { throw new SystemBlockException(resourceWrapper.getName(), "thread"); } double rt = Constants.ENTRY_NODE == null ? 0 : Constants.ENTRY_NODE.avgRt(); if (rt > maxRt) { throw new SystemBlockException(resourceWrapper.getName(), "rt"); } // BBR算法 // load. BBR algorithm. if (highestSystemLoadIsSet && getCurrentSystemAvgLoad() > highestSystemLoad) { if (!checkBbr(currentThread)) { throw new SystemBlockException(resourceWrapper.getName(), "load"); } } // cpu usage if (highestCpuUsageIsSet && getCurrentCpuUsage() > highestCpuUsage) { throw new SystemBlockException(resourceWrapper.getName(), "cpu"); } }

其中的Constants.ENTRY_NODE是一个全局的ClusterNode，该节点的值是在StatisticsSlot中进行统计的。

当前的统计值和系统配置的进行比较，各个维度超过范围抛BlockException

AuthoritySlot

AuthoritySlot做的事也比较简单，主要是根据黑白名单进行过滤，只要有一条规则校验不通过，就抛出异常。

@Override public void entry(Context context, ResourceWrapper resourceWrapper, DefaultNode node, int count, boolean prioritized, Object... args) throws Throwable { checkBlackWhiteAuthority(resourceWrapper, context); fireEntry(context, resourceWrapper, node, count, prioritized, args); } void checkBlackWhiteAuthority(ResourceWrapper resource, Context context) throws AuthorityException { // 通过监听来的规则集 Map<String, Set<AuthorityRule>> authorityRules = AuthorityRuleManager.getAuthorityRules(); if (authorityRules == null) { return; } // 根据资源名称获取相应的规则 Set<AuthorityRule> rules = authorityRules.get(resource.getName()); if (rules == null) { return; } for (AuthorityRule rule : rules) { // 黑名单白名单验证 // 只要有一条规则校验不通过，就抛出AuthorityException if (!AuthorityRuleChecker.passCheck(rule, context)) { throw new AuthorityException(context.getOrigin(), rule); } } }

FlowSlot

FlowSlot主要是根据前面统计好的信息，与设置的限流规则进行匹配校验，如果规则校验不通过则进行限流，具体的代码如下：

@Override public void entry(Context context, ResourceWrapper resourceWrapper, DefaultNode node, int count, boolean prioritized, Object... args) throws Throwable { checkFlow(resourceWrapper, context, node, count, prioritized); fireEntry(context, resourceWrapper, node, count, prioritized, args); } void checkFlow(ResourceWrapper resource, Context context, DefaultNode node, int count, boolean prioritized) throws BlockException { checker.checkFlow(ruleProvider, resource, context, node, count, prioritized); }

DegradeSlot

DegradeSlot主要是根据前面统计好的信息，与设置的降级规则进行匹配校验，如果规则校验不通过则进行降级，具体的代码如下：

@Override public void entry(Context context, ResourceWrapper resourceWrapper, DefaultNode node, int count, boolean prioritized, Object... args) throws Throwable { performChecking(context, resourceWrapper); fireEntry(context, resourceWrapper, node, count, prioritized, args); } void performChecking(Context context, ResourceWrapper r) throws BlockException { List<CircuitBreaker> circuitBreakers = DegradeRuleManager.getCircuitBreakers(r.getName()); if (circuitBreakers == null || circuitBreakers.isEmpty()) { return; } for (CircuitBreaker cb : circuitBreakers) { if (!cb.tryPass(context)) { throw new DegradeException(cb.getRule().getLimitApp(), cb.getRule()); } } }

DefaultProcessorSlotChain

Chain 是链条的意思，从build的方法可看出，ProcessorSlotChain 是一个链表，里面添加了很多个 Slot。都是 ProcessorSlot 的子类。具体的实现需要到 DefaultProcessorSlotChain 中去看。

public class DefaultProcessorSlotChain extends ProcessorSlotChain { AbstractLinkedProcessorSlot<?> first = new AbstractLinkedProcessorSlot<Object>() { @Override public void entry(Context context, ResourceWrapper resourceWrapper, Object t, int count, boolean prioritized, Object... args) throws Throwable { super.fireEntry(context, resourceWrapper, t, count, prioritized, args); } @Override public void exit(Context context, ResourceWrapper resourceWrapper, int count, Object... args) { super.fireExit(context, resourceWrapper, count, args); } }; AbstractLinkedProcessorSlot<?> end = first; @Override public void addFirst(AbstractLinkedProcessorSlot<?> protocolProcessor) { protocolProcessor.setNext(first.getNext()); first.setNext(protocolProcessor); if (end == first) { end = protocolProcessor; } } @Override public void addLast(AbstractLinkedProcessorSlot<?> protocolProcessor) { end.setNext(protocolProcessor); end = protocolProcessor; } /** * Same as {@link #addLast(AbstractLinkedProcessorSlot)}. * * @param next processor to be added. */ @Override public void setNext(AbstractLinkedProcessorSlot<?> next) { addLast(next); } @Override public AbstractLinkedProcessorSlot<?> getNext() { return first.getNext(); } @Override public void entry(Context context, ResourceWrapper resourceWrapper, Object t, int count, boolean prioritized, Object... args) throws Throwable { first.transformEntry(context, resourceWrapper, t, count, prioritized, args); } @Override public void exit(Context context, ResourceWrapper resourceWrapper, int count, Object... args) { first.exit(context, resourceWrapper, count, args); } }

DefaultProcessorSlotChain中有两个AbstractLinkedProcessorSlot类型的变量：first和end，这就是链表的头结点和尾节点。

创建DefaultProcessorSlotChain对象时，首先创建了首节点，然后把首节点赋值给了尾节点，可以用下图表示：

将第一个节点添加到链表中后，整个链表的结构变成了如下图这样：

将所有的节点都加入到链表中后，整个链表的结构变成了如下图所示：

这样就将所有的Slot对象添加到了链表中去了，每一个Slot都是继承自AbstractLinkedProcessorSlot。而AbstractLinkedProcessorSlot是一种责任链的设计，每个对象中都有一个next属性，指向的是另一个AbstractLinkedProcessorSlot对象。其实责任链模式在很多框架中都有，比如Netty中是通过pipeline来实现的。

知道了SlotChain是如何创建的了，那接下来就要看下是如何执行Slot的entry方法的了

从这里可以看到，从fireEntry方法中就开始传递执行entry了，这里会执行当前节点的下一个节点transformEntry方法，上面已经分析过了，transformEntry方法会触发当前节点的entry，也就是说fireEntry方法实际是触发了下一个节点的entry方法。

从最初的调用Chain的entry()方法，转变成了调用SlotChain中Slot的entry()方法。从 @SpiOrder(-10000) 知道，SlotChain中的第一个Slot节点是NodeSelectorSlot。

slot总结

sentinel的限流降级等功能，主要是通过一个SlotChain实现的。在链式插槽中，有7个核心的Slot，这些Slot各司其职，可以分为以下几种类型：

一、进行资源调用路径构造的NodeSelectorSlot和ClusterBuilderSlot

二、进行资源的实时状态统计的StatisticsSlot

三、进行系统保护，限流，降级等规则校验的SystemSlot、AuthoritySlot、FlowSlot、DegradeSlot

后面几个Slot依赖于前面几个Slot统计的结果。至此，每种Slot的功能已经基本分析清楚了。

9 .sentinel滑动窗口实现原理

基本原理

滑动窗口可以先拆为滑动跟窗口两个词，先介绍下窗口，你可以这么理解，一段是时间就是窗口，比如说我们可以把这个1s认为是1个窗口
这个样子我们就能将1分钟就可以划分成60个窗口了，这个没毛病吧。如下图我们就分成了60个窗口（这个多了我们就画5个表示一下）

比如现在处于第1秒上，那1s那个窗口就是当前窗口，就如下图中红框表示。

好了，窗口就介绍完了，现在在来看下滑动，滑动很简单，比如说现在时间由第1秒变成了第2秒，就是从当前这个窗口---->下一个窗口就可以了，这个时候下一个窗口就变成了当前窗口，之前那个当前窗口就变成了上一个窗口，这个过程其实就是滑动。

好了，介绍完了滑动窗口，我们再来介绍下这个sentinel的滑动窗口的实现原理。
其实你要是理解了上面这个滑动窗口的意思，sentinel实现原理就简单了。
先是介绍下窗口中里面都存储些啥。也就是上面这个小框框都有啥。

1. 它得有个开始时间吧，不然你怎么知道这个窗口是什么时候开始的
2. 还得有个窗口的长度吧，不然你咋知道窗口啥时候结束，通过这个开始时间+窗口长度=窗口结束时间，就比如说上面的1s，间隔1s
3. 最后就是要在这个窗口里面统计的东西，你总不能白搞些窗口，搞些滑动吧。所以这里就存储了一堆要统计的指标（qps，rt等等）

说完了这一个小窗口里面的东西，就得来说说是怎么划分这个小窗口，怎么管理这些小窗口的了，也就是我们的视野得往上提高一下了，不能总聚在这个小窗口上。

1. 要知道有多少个小窗口，在sentinel中也就是sampleCount，比如说我们有60个窗口。
2. 还有就是intervalInMs，这个intervalInMs是用来计算这个窗口长度的，intervalInMs/窗口数量= 窗口长度。也就是我给你1分钟，你给我分成60个窗口，这个时候窗口长度就是1s了，那如果我给你1s，你给我分2个窗口，这个时候窗口长度就是500毫秒了，这个1分钟，就是intervalInMs。
3. 再就是存储这个窗口的容器（这里是数组），毕竟那么多窗口，还得提供计算当前时间窗口的方法等等

最后我们就来看看这个当前时间窗口是怎么计算的。
咱们就拿 60个窗口，这个60个窗口放在数组中，窗口长度是1s 来计算，看看当前时间戳的一个时间窗口是是在数组中哪个位置。

比如说当前时间戳是1609085401454 ms，算出秒 = 1609085401454 /1000（窗口长度）

在数组的位置 = 算出秒 %数组长度

我们再来计算下 某个时间戳对应窗口的起始时间，还是以1609085401454 来计算

窗口startTime = 1609085401454 - 1609085401454%1000（窗口长度）=454

这里1609085401454%1000（窗口长度） 能算出来它的毫秒值，也就是454 ， 减去这个后就变成了1609085401000

好了，sentinel 滑动窗口原理就介绍完成了。

2.sentinel使用滑动窗口都统计啥

我们来介绍下使用这个滑动窗口都来统计啥

public enum MetricEvent { /** * Normal pass. */ PASS,// 通过 /** * Normal block. */ BLOCK,// 拒绝的 EXCEPTION,// 异常 SUCCESS,//成功 RT,// 耗时 /** * Passed in future quota (pre-occupied, since 1.5.0). */ OCCUPIED_PASS } 1234567891011121314151617

这是最基本的指标，然后通过这些指标，又可以计算出来比如说最大，最小，平均等等的一些指标。

3.滑动窗口源码实现

我们先来看下这个窗口里面的统计指标的实现 MetricBucket

3.1 MetricBucket

这个MetricBucket 是由LongAdder数组组成的，一个LongAdder就是一个MetricEvent ，也就是第二小节里面的PASS ，BLOCK等等。
我们稍微看下就可以了

可以看到它在实例化的时候创建一个LongAdder 数据，个数就是那堆event的数量。这个LongAdder 是jdk8里面的原子操作类，你可以把它简单认为AtomicLong。然后下面就是一堆get 跟add 的方法了，这里我们就不看了。
接下来再来看看那这个窗口的实现WindowWrap类

3.2 WindowWrap

先来看下这个成员

窗口长度，窗口startTime ，指标统计的 都有了，下面的就没啥好看的了，我们再来看下的一个方法吧

就是判断某个时间戳是不是在这个窗口中
时间戳要大于等于窗口开始时间 && 小于这个结束时间。

接下来再来看下这个管理窗口的类LeapArray

3.3 LeapArray

看下它的成员， 窗口长度， 样本数sampleCount 也就是窗口个数， intervalInMs ，再就是窗口数组
看看它的构造方法

这个构造方法其实就是计算出来这个窗口长度，创建了窗口数组。
再来看下一个很重要的方法