【Spring Cloud Alibaba】开源组件Sentinel

什么是Sentinel

• 分布式系统的流量防卫兵
• Sentinel 是阿里中间件团队开源的，面向分布式服务架构的轻量级高可用流量控制组件，主要以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度来帮助用户保护服务的稳定性。
• Sentinel官网：https://github.com/alibaba/Sentinel/
• Sentinel中文官网：https://github.com/alibaba/Sentinel/wiki/介绍

发展历史

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

与Hystrix的异同

Sentinel可以做什么？

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

Sentinel的功能

Sentinel的开源生态

Sentinel的用户

安装Sentinel控制台

预备环境准备

Sentinel依赖 Java 环境来运行。请确保安装了JDK或JRE。

Sentinel 分为两个部分:

• 核心库（Java 客户端）不依赖任何框架/库，能够运行于所有 Java 运行时环境，同时对 Dubbo / Spring Cloud 等框架也有较好的支持。
• 控制台（Dashboard）基于 Spring Boot 开发，打包后可以直接运行，不需要额外的 Tomcat 等应用容器。

下载地址

• https://github.com/alibaba/Sentinel/releases
• 选择的版本：1.7.2
• 将下载好的jar包拷贝到D:\Soft\Sentinel(需要自己创建，也可以是其他盘路径)
• 进入D:\Soft\Sentinel，在磁盘地址栏中输入cmd，出现命令行窗口
• 在命令行窗口输入：java -jar sentinel-dashboard-1.7.2.jar
  • 因为我的电脑上装了JDK8和JDK17，sentinel这个版本只能用JDK8运行，因此我用这个命令：C:\Program Files\Java\jdk1.8.0_281\bin>java -jar D:\soft\Sentinel\sentinel-dashboard-1.7.2.jar
    
• 运行成功后，访问Sentinel的控制台
• 在浏览器中输入：http://localhost:8080
• 输入用户名和密码：sentinel
  

项目集成Sentinel

创建项目

• 指定artifactId为order-sentinel-provider
  

修改依赖信息

添加启动注解

• @EnableDiscoveryClient

@SpringBootApplication
@EnableDiscoveryClient
public class OrderSentinelProviderApplication {
    public static void main(String[] args) {
        SpringApplication.run(OrderSentinelProviderApplication.class, args);
    }
}

添加配置信息

spring:
  application:
    name: order-sentinel-provider
  cloud:
    nacos:
      discovery:
        server-addr: localhost:8848
    sentinel:
      transport:
        dashboard: localhost:8080
        port: 8719
server:
  port: 8086

在控制器类中新增一个测试接口

@RestController
@Slf4j
public class LimitFlowController {
    @RequestMapping("/test")
    public String test(){
        log.info("=========阈值类型为QPS，Sentinel测试。");
        return "Sentinel调试环境已经准备";
    }
}

启动Nacos、order-sentinel-provider

• 注意：直接启动订单微服务和Sentinel，会发现Sentinel中没有订单微服务的数据，因为Sentinel是懒加载机制，所以需要访问一下接口，再去访问Sentinel 就有数据了

Sentinel核心功能

Sentinel：分布式系统的流量防卫兵

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

流量控制

• 在高并发、大流量场景下，进入系统的流量如果不加控制的话，系统就很有可能会被流量压垮。
• 所以，在流量正式进入系统之前，需要对流量进行控制，以便使流量均匀、可控的方式进入系统。
• Sentinel作为一个非常出色的容错组件，能够将不可控的流量经过处理转化成均匀、可控的流量。

熔断降级

• 如果检测到系统中的某个调用链路中某个节点出现故障，比如请求超时、服务宕机或者异常比超出一定阈值时，就会对出现故障的节点的调用频率进行限制，甚至不调用出现故障的节点，让请求能够快速失败并返回，以最大程度避免影响到其他节点的服务而导致系统的级联故障。

Sentinel熔断降级策略

• Sentinel主要通过限制并发线程数和响应时间对资源的访问进行降级

限制并发线程数进行降级

• Sentinel可以通过限制服务节点的并发线程数量，来减少对其他服务节点的影响。
• 例如，当某个服务节点出现故障，例如响应时间变长，或者直接宕机。此时，对服务的直接影响就是会造成请求线程数的不断堆积。
• 如果这些堆积的线程数达到一定的数量后，对当前服务节点的后续请求就会被拒绝，等到堆积的线程完成任务后再开始继续接收新的请求。

通过响应时间进行降级

• Sentinel除了可以通过限制并发线程数进行降级外，也能够通过响应时间进行降级。
• 如果依赖的服务出现响应时间过长的情况，则所有对该服务的请求都会被拒绝，直到过了指定的时间窗口之后才能再次访问该服务。

系统负载保护

• Sentinel提供了系统维度的自适应保护能力。当系统的压力和负载比较高的时候，如果还持续让大量的请求进入系统，此时就有可能将系统压垮，进而导致系统宕机。
• Sentinel会在集群环境下，将本应服务A承载的流量转发到其他服务器上，比如转发到服务器B上。如果此时服务器B也处于高负载的状态，则Sentinel会提供相应的保护机制，让系统的入口流量和系统的整体负载达到平衡，让系统整体可用，并且能够最大限度的处理请求。

Sentinel核心规则

• Sentinel的核心规则包括流控规则、熔断规则、热点规则、授权规则和系统规则
• Sentinel能够对流量进行控制，主要是监控应用的QPS流量或者并发线程数等指标，如果达到指定的阈值时，就会被流量进行控制，以避免服务被瞬时的高并发流量击垮，保证服务的高可靠性

QPS和TPS

QPS

• Queries Per Second意思是“每秒查询率”，是一台服务器每秒能够相应的查询次数
• 是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。

TPS

• 是Transactions Per Second的缩写，也就是事务数/秒。
• 它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。
• 客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。

QPS VS TPS

• QPS基本类似于TPS，但是不同的是，对于一个页面的一次访问，形成一个TPS；
• 但一次页面请求，可能产生多次对服务器的请求，服务器对这些请求，就可计入“QPS”之中。
• 如，访问一个页面会请求服务器2次，一次访问，产生一个“T”，产生2个“Q”。

RT，响应时间

• 响应时间：执行一个请求从开始到最后收到响应数据所花费的总体时间,即从客户端发起请求到收到服务器响应结果的时间。
• 响应时间RT(Response-time)，是一个系统最重要的指标之一，它的数值大小直接反应了系统的快慢。

并发数：

• 并发数是指系统同时能处理的请求数量，这个也是反应了系统的负载能力。

吞吐量

• 系统的吞吐量与request对CPU的消耗、外部接口、IO等等紧密关联。
• 单个request 对CPU消耗越高，外部系统接口、IO速度越慢，系统吞吐能力越低，反之越高。

系统吞吐量几个重要参数

分别是：QPS（TPS）、并发数、响应时间。

• QPS（TPS）：（Query Per Second）每秒钟request/事务 数量
• 并发数：系统同时处理的request/事务数
• 响应时间：一般取平均响应时间

• QPS(TPS) = 并发数/平均响应时间
• 并发数 = QPS * 平均响应时间

簇点链路规则

• 点击簇点链路菜单，可以看到之前访问过的接口，如下所示
  

• 点击右侧的流控按钮，会弹出新增流控规则的提示框，如下所示
  

配置直接流控模式——阈值类型为QPS

• 这里，针对 http://localhost:8086/test接口进行直接流控模式
• 在新增流控规则里阈值类型选择QPS，单机阈值输入1，表示每秒钟的请求量如果超过1，则会触发Sentinel的限流操作

配置直接流控模式——阈值类型为线程数

• 这里，针对 http://localhost:8086/test2接口进行直接流控模式
• 在新增流控规则里阈值类型选择线程数，单机阈值输入1，表示当调用API的线程数达到阈值时，则会触发Sentinel的限流操作

接口(先访问一下)，然后再去控制台

@RestController
@Slf4j
public class LimitFlowController {
    @RequestMapping("/test")
    public String test(){
        log.info("=========阈值类型为QPS，Sentinel测试。");
        return "Sentinel调试环境已经准备";
    }
    @RequestMapping("/test2")
    public String test2() throws InterruptedException {
        System.out.println("=========阈值类型为线程数，Sentinel测试。");
        TimeUnit.SECONDS.sleep(2);
        return "Sentinel调试环境已经准备";
    }
}

配置关联流控模式——阈值类型为QPS

• 这里，针对 http://localhost:8086/test3接口进关联流控模式
• 在新增流控规则里阈值类型选择QPS，单机阈值输入5，表示当关联资源/test的QPS阈值超过5时，就限流/test3的访问

    @RequestMapping("/test3")
    public String test3() {
        System.out.println("=========阈值类型为QPS，流控模式为关联。");
        return "Sentinel调试环境已经准备";
    }

配置流控效果——Warm Up（预热）

• Warm up也叫预热模式，是应对服务冷启动的一种方案。请求阈值初始值是 threshold / coldFactor，持续指定时长后，逐渐提高到threshold值。而coldFactor的默认值是3。
  

    @RequestMapping("/save")
    public String save() {
        System.out.println("=========阈值类型为QPS，流控模式为直接，流控效果为 Warm up预热。");
        return "Sentinel调试环境已经准备：预热";
    }

配置流控效果——排队等待

• 能够使请求均匀的通过，单机的阈值为每秒通过的请求数量，其余的请求会排队等待。
• 另外，还会设置一个超时时间，当请求超过超时时间未处理时，会被丢弃。
  

    @RequestMapping("/query")
    public String query() {
        System.out.println("=========阈值类型为QPS，流控模式为直接，流控效果为等待。");
        return "Sentinel调试环境已经准备：排队等待";
    }

流控规则配置项的说明

• 资源名：资源的唯一名称，默认就是请求的接口路径，可以自行修改，但是要保证唯一。
• 针对来源：具体针对某个微服务进行限流，默认值为default，表示不区分来源，全部限流。
• 阈值类型：
  • QPS（每秒钟的请求数量）：当调用该API的阈值达到达到阈值时候，进行限流，
  • 并发线程数：当调用该API的线程数达到阈值时，进行限流。
• 单机阈值：与阈值类型组合使用。如果阈值类型选择的是QPS，表示当调用接口的QPS达到阈值时，进行限流操作。如果阈值类型选择的是并发线程数，则表示当调用接口的并发线程数达到阈值时，进行限流操作。
• 是否集群：选中则表示集群环境，不选中则表示非集群环境。
• 流控模式：
  • 直接：当API调用达到限流条件时，直接限流
  • 关联：当关联的资源达到阈值时，限流自己
  • 链路：统计从指定链路访问到本资源的请求，触发阈值时，对指定链路限流
• 流控效果
  • 快速失败：直接失败，抛出异常
  • Warm Up：根据codeFactor(冷加载因子 默认为3)的值，从阈值/codeFactor，经过预热时长，才达到设置的QPS阈值。
  • 排队等待：匀速排队，让请求以均匀的速度通过，阈值类型必须设置为QPS，否则无效

Sentinel的降级规则

回顾熔断降级

• 除了流量控制以外，对调用链路中不稳定的资源进行熔断降级也是保障高可用的重要措施之一。一个服务常常会调用别的模块，可能是另外的一个远程服务、数据库，或者第三方 API 等。
• 例如，支付的时候，可能需要远程调用银联提供的 API；查询某个商品的价格，可能需要进行数据库查询。然而，这个被依赖服务的稳定性是不能保证的。如果依赖的服务出现了不稳定的情况，请求的响应时间变长，那么调用服务的方法的响应时间也会变长，线程会产生堆积，最终可能耗尽业务自身的线程池，服务本身也变得不可用。
• 现代微服务架构都是分布式的，由非常多的服务组成。不同服务之间相互调用，组成复杂的调用链路。以上的问题在链路调用中会产生放大的效果。复杂链路上的某一环不稳定，就可能会层层级联，最终导致整个链路都不可用。因此我们需要对不稳定的弱依赖服务调用进行熔断降级，暂时切断不稳定调用，避免局部不稳定因素导致整体的雪崩。熔断降级作为保护自身的手段，通常在客户端（调用端）进行配置。

Sentinel熔断策略

RT（平均响应时间，秒级）

• 平均响应时间超出阈值且在时间窗口内通过的请求>=5,两个条件同时满足后触发降级
• 窗口期过后关闭断路器
• RT最大为4900（更大的值需要在配置文件中设置）

异常比例 (ERROR_RATIO)：

• QPS>=5且异常比例（秒级统计）超过阈值时，触发降级
• 时间窗口结束后，关闭降级

异常数 (ERROR_COUNT)：

• 异常数（分钟统计）超过阈值时，触发降级
• 时间窗口结束后，关闭降级

配置降级规则——降级策略为RT

这里，针对 http://localhost:8086/hy1接口进行降级

    @RequestMapping("/hy1")
    public String hy1() throws InterruptedException {
        TimeUnit.SECONDS.sleep(1);
        System.out.println("=========降级测试策略为RT，Sentinel测试。");
        return "Sentinel调试环境已经准备：降级测试";
    }

配置降级规则——降级策略为异常比例

这里，针对 http://localhost:8086/api/testSentinelE接口进行降级

    @RequestMapping("/hy2")
    public String hy2() throws InterruptedException {
        System.out.println(1/0);
        System.out.println("=========降级测试策略为异常比例，Sentinel测试。");
        return "Sentinel调试环境已经准备：异常比例";
    }

配置降级规则——降级策略为异常数

• 这里，针对 http://localhost:8086/api/testSentinelF接口进行降级
• 在新增降级规则里降级策略选择异常数，异常数为5，时间窗口为70。当1分钟的异常数超过超过5时，触发降级
• 点击5次以后，触发降级

    @RequestMapping("/hy3")
    public String hy3() throws InterruptedException {
        System.out.println(1/0);
        System.out.println("=========降级测试策略为异常数，Sentinel测试。");
        return "Sentinel调试环境已经准备：异常数";
    }

Sentinel的热点参数限流

何为热点

• 热点即经常访问的数据。很多时候我们希望统计某个热点数据中访问频次最高的 Top K 数据，并对其访问进行限制。比如
  • 商品 ID 为参数，统计一段时间内最常购买的商品 ID 并进行限制
  • 用户 ID 为参数，针对一段时间内频繁访问的用户 ID 进行限制

热点参数限流

• 热点参数限流会统计传入参数中的热点参数，并根据配置的限流阈值与模式，对包含热点参数的资源调用进行限流。
• 热点参数限流可以看做是一种特殊的流量控制，仅对包含热点参数的资源调用生效。

兜底方法

• 之前的兜底方法：限流出问题后，系统默认提示
  • Blocked by Sentinel(flow limiting)
• @SentinelResource 注解：用于自定义定义资源，并提供可选的异常处理和 fallback 配置项：
  • value：资源名称，必需项（不能为空）。
  • blockHandler / blockHandlerClass: blockHandler 对应处理 BlockException 的函数名称，可选项。
  • fallback / fallbackClass：fallback 函数名称，可选项，用于在抛出异常的时候提供 fallback 处理逻辑。

    @RequestMapping("/getGoods")
    @SentinelResource(value = "getGoods",blockHandler = "blockHandlerGetGoods")
    public String xian(String id,String name)  {
        return "Sentinel调试环境已经准备：异常比例";
    }

    public String blockHandlerGetGoods(String id, String name, BlockException ex){
        return "访问过快！等一会再访问吧！";
    }

• 注意：兜底方法，参数要一致，添加BlockException
• 配置热点规则——热点参数限流
  • 这里，针对 http://localhost:8086/getGoods接口进行热点参数限流
  • 新增热点规则
    
    发送请求测试
    http://localhost:8086/getGoods
    http://localhost:8086/getGoods?id=1
    http://localhost:8086/getGoods?id=1&name=aa
    http://localhost:8086/getGoods?name=aa
    

附：参考百度解释：吞吐量（TPS）、QPS、并发数、响应时间（RT）几个概念

响应时间(RT)

• 响应时间是指系统对请求作出响应的时间。
• 直观上看，这个指标与人对软件性能的主观感受是非常一致的，因为它完整地记录了整个计算机系统处理请求的时间。
• 由于一个系统通常会提供许多功能，而不同功能的处理逻辑也千差万别，因而不同功能的响应时间也不尽相同，甚至同一功能在不同输入数据的情况下响应时间也不相同。
• 所以，在讨论一个系统的响应时间时，人们通常是指该系统所有功能的平均时间或者所有功能的最大响应时间。
• 当然，往往也需要对每个或每组功能讨论其平均响应时间和最大响应时间。

---

• 对于单机的没有并发操作的应用系统而言，人们普遍认为响应时间是一个合理且准确的性能指标。
• 需要指出的是，响应时间的绝对值并不能直接反映软件的性能的高低，软件性能的高低实际上取决于用户对该响应时间的接受程度。
• 对于一个游戏软件来说，响应时间小于100毫秒应该是不错的，响应时间在1秒左右可能属于勉强可以接受，如果响应时间达到3秒就完全难以接受了。
• 而对于编译系统来说，完整编译一个较大规模软件的源代码可能需要几十分钟甚至更长时间，但这些响应时间对于用户来说都是可以接受的。

吞吐量(Throughput)

• 吞吐量是指系统在单位时间内处理请求的数量。
• 对于无并发的应用系统而言，吞吐量与响应时间成严格的反比关系，实际上此时吞吐量就是响应时间的倒数。
• 前面已经说过，对于单用户的系统，响应时间（或者系统响应时间和应用延迟时间）可以很好地度量系统的性能，但对于并发系统，通常需要用吞吐量作为性能指标。

---

• 对于一个多用户的系统，如果只有一个用户使用时系统的平均响应时间是t，当有你n个用户使用时，每个用户看到的响应时间通常并不是n×t，而往往比n×t小很多（当然，在某些特殊情况下也可能比n×t大，甚至大很多）。
• 这是因为处理每个请求需要用到很多资源，由于每个请求的处理过程中有许多不走难以并发执行，这导致在具体的一个时间点，所占资源往往并不多。
• 也就是说在处理单个请求时，在每个时间点都可能有许多资源被闲置，当处理多个请求时，如果资源配置合理，每个用户看到的平均响应时间并不随用户数的增加而线性增加。
• 实际上，不同系统的平均响应时间随用户数增加而增长的速度也不大相同，这也是采用吞吐量来度量并发系统的性能的主要原因。
• 一般而言，吞吐量是一个比较通用的指标，两个具有不同用户数和用户使用模式的系统，如果其最大吞吐量基本一致，则可以判断两个系统的处理能力基本一致。

并发用户数

• 并发用户数是指系统可以同时承载的正常使用系统功能的用户的数量。
• 与吞吐量相比，并发用户数是一个更直观但也更笼统的性能指标。
• 实际上，并发用户数是一个非常不准确的指标，因为用户不同的使用模式会导致不同用户在单位时间发出不同数量的请求。
• 以网站系统为例，假设用户只有注册后才能使用，但注册用户并不是每时每刻都在使用该网站，因此具体一个时刻只有部分注册用户同时在线，在线用户就在浏览网站时会花很多时间阅读网站上的信息，因而具体一个时刻只有部分在线用户同时向系统发出请求。
• 这样，对于网站系统我们会有三个关于用户数的统计数字：注册用户数、在线用户数和同时发请求用户数。
• 由于注册用户可能长时间不登陆网站，使用注册用户数作为性能指标会造成很大的误差。
• 而在线用户数和同事发请求用户数都可以作为性能指标。
• 相比而言，以在线用户作为性能指标更直观些，而以同时发请求用户数作为性能指标更准确些。

QPS每秒查询率(Query Per Second)

• 每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。
• 对应fetches/sec，即每秒的响应请求数，也即是最大吞吐能力。 （看来是类似于TPS，只是应用于特定场景的吞吐量）