阿里限流神器Sentinel夺命连环 17 问？（上篇）

1、前言

这篇文章介绍一下阿里开源的流量防卫兵Sentinel，一款非常优秀的开源项目，经过近10年的双十一的考验，非常成熟的一款产品。

文章目录如下：

2、什么是sentinel？

sentinel顾名思义：卫兵；在Redis中叫做哨兵，用于监控主从切换，但是在微服务中叫做流量防卫兵。

Sentinel 以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。

Sentinel 具有以下特征:

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

Sentinel 的主要特性如下图：

Sentinel 分为两个部分:

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

总之一句话：sentinel真牛逼，完爆Hystrix.........

3、sentinel和Hystrix有何区别？

不多说了，总之一句话：Hystrix赶紧放弃，用sentinel......

具体区别如下图：

4、sentinel版本如何选择？

由于陈某写的是Spring Cloud 进阶一个系列，使用的聚合项目，因此版本还是保持和之前文章一样，不清楚的可以看这篇：​​五十五张图告诉你微服务的灵魂摆渡者Nacos究竟有多强？​​

这里选择的​​spring-cloud-alibaba-dependencies​​​的版本是​​2.2.1.RELEASE​​​，因此sentinel版本选择​​1.7.1​​，大家可以根据自己的版本选择对应sentinel的版本，版本对应关系如下图：

注意：一定要按照官方推荐的版本适配，否则出现意想不到的BUG追悔莫及.........

5、Sentinel 控制台如何安装？

sentinel和nacos一样，都有一个控制台，但是这里不用自己手动搭建一个微服务，官方已经搭建好了，只需要下载对应得jar包运行即可。下载地址：​​https://github.com/alibaba/Sentinel/tags​​

选择对应得版本下载即可，我这里选择​​1.7.1​​版本，下载的jar包如下图：

当然你可以通过源码构建：mvn clean package

注意：JDK版本必须​​>=1.8​​

此时我们只需要运行这个jar包即可，命令如下：

java -Dserver.port=8080 -Dcsp.sentinel.dashboard.server=localhost:8080 -Dproject.name=sentinel-dashboard -jar sentinel-dashboard-1.7.1.jar

上述参数含义如下：

• ​​-Dserver.port​​​：指定启动的端口，默认​​8080​​
• ​​-Dproject.name​​：指定本服务的名称
• ​​-Dcsp.sentinel.dashboard.server​​：指定sentinel控制台的地址，用于将自己注册进入实现监控自己

启动成功之后，浏览器访问：​​http://localhost:8080​​，登录页面如下图：

默认的用户名和密码：sentinel/sentinel

登录成功之后页面如下：

可以看到目前只有一个服务​​sentinel-dashboard​​被监控了，这个服务就是自己。

注意：上述参数都是可选的，没必要可以不填。

那么问题来了：默认的用户名和密码在生产环境上肯定不能用，如何修改呢？

从 Sentinel 1.6.0 起sentinel已经支持自定义用户名和密码了，只需要在执行jar命令时指定即可，命令如下：

java -Dsentinel.dashboard.auth.username=admin -Dsentinel.dashboard.auth.password=123 -jar sentinel-dashboard-1.7.1.jar

用户可以通过如下参数进行配置：

• ​​-Dsentinel.dashboard.auth.username=sentinel​​​ 用于指定控制台的登录用户名为 ​​sentinel​​；
• ​​-Dsentinel.dashboard.auth.password=123456​​​ 用于指定控制台的登录密码为 ​​123456​​​；如果省略这两个参数，默认用户和密码均为 ​​sentinel​​；
• ​​-Dserver.servlet.session.timeout=7200​​​ 用于指定 Spring Boot 服务端 session 的过期时间，如 ​​7200​​​ 表示 7200 秒；​​60m​​ 表示 60 分钟，默认为 30 分钟；

注意：部署多台控制台时，session 默认不会在各实例之间共享，这一块需要自行改造。

除了用户名密码相关的配置，sentinel控制台还提供了其他的可配置选项，如下图：

6、微服务如何接入sentinel控制台？

微服务为什么要集成sentinel控制台，sentinel不是提供了相关的API吗？

其实Spring Boot 官方一直提倡约定>配置>编码的规则，能够不硬编码何乐而不为呢？

因此本文后续内容主要还是结合sentinel控制台进行讲解，关于API的使用大家可以按照官方文档学习，讲解的非常清楚。

好了，言归正传，微服务如何接入sentinel控制台呢？

1、新建微服务模块注册进入Nacos

这里的注册中心依然使用的是nacos，有不会用的请看专栏第一篇Nacos文章：​​五十五张图告诉你微服务的灵魂摆渡者Nacos究竟有多强？​​

新建一个微服务模块：sentinel-service9008，相关代码不贴出了。

相关配置如下：

server:
  port: 9008
spring:
  application:
    ## 指定服务名称，在nacos中的名字
    name: sentinel-service
  cloud:
    nacos:
      discovery:
        # nacos的服务地址，nacos-server中IP地址:端口号
        server-addr: 127.0.0.1:8848
management:
  endpoints:
    web:
      exposure:
        ## yml文件中存在特殊字符，必须用单引号包含，否则启动报错
        include: '*'

源码全部会上传，获取方式看文末！

2、添加依赖

除了Nacos的依赖，还需要添加一个sentinel的依赖：

<!--sentinel的依赖-->
<dependency>
 <groupId>com.alibaba.cloud</groupId>
 <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>

以上只贴出了sentinel相关依赖，nacos依赖不再贴了，见源码！

3、添加配置集成控制台

只需要添加如下配置即可集成sentinel控制台：

spring:
  cloud:
    sentinel:
      transport:
       ## 指定控制台的地址，默认端口8080
        dashboard: localhost:8080

4、新建一个测试接口

下面新建一个测试接口，用于测试相关规则，如下：

@RestController
@RequestMapping("/sentinel")
public class FlowLimitController {

    @GetMapping("/test")
    public String test(){
        return "接收到一条消息--------";
    }
}

5、启动微服务

启动9008这个微服务，然后浏览器输入：​​http://localhost:9008/sentinel/test​​，此时查看sentinel控制台，将会看见sentinel-service这个服务已经被监控了，如下图：

注意：sentinel是懒加载机制，只有访问过一次的资源才会被监控。

不过可以通过配置关闭懒加载，在项目启动时就连接sentinel控制台，配置如下：

spring:
    sentinel:
      # 取消控制台懒加载，项目启动即连接Sentinel
      eager: true

7、流量控制如何配置？

流量控制（flow control），其原理是监控应用流量的 QPS 或并发线程数等指标，当达到指定的阈值时对流量进行控制，以避免被瞬时的流量高峰冲垮，从而保障应用的高可用性。

QPS：每秒请求数，即在不断向服务器发送请求的情况下，服务器每秒能够处理的请求数量。

并发线程数：指的是施压机施加的同时请求的线程数量。

同一个资源可以创建多条限流规则，一条限流规则由以下元素组成：

• resource：资源名，即限流规则的作用对象。
• count： 限流阈值
• grade：限流阈值类型（1：QPS  0：并发线程数），默认值QPS
• limitApp：流控针对的调用来源，若为 ​​default​​ 则不区分调用来源，默认值default
• strategy：判断的根据是资源自身*(0)*，还是根据其它关联资源 (1)，还是根据链路入口*(2)*，默认值根据资源本身。
• controlBehavior： 流控效果（直接拒绝(0) / 排队等待(2) / 预热冷启动(1))，默认值直接拒绝。

以上元素限流元素对应的类是​​com.alibaba.csp.sentinel.slots.block.flow.FlowRule​​，各元素如下图：

注意：各个元素的取值以及默认值一定要记住，后续配置将会用到。

以上几个元素在sentinel控制台对应规则如下图：

1、三种流控效果

流控效果总共分为三种，对应元素​​controlBehavior​​，分别如下：

快速失败

默认的流量控制方式，当QPS超过任意规则的阈值后，新的请求就会被立即拒绝，拒绝方式为抛出​​FlowException​​。

warm up

即预热/冷启动方式。当系统长期处于低水位的情况下，当流量突然增加时，直接把系统拉升到高水位可能瞬间把系统压垮。通过"冷启动"，让通过的流量缓慢增加，在一定时间内逐渐增加到阈值上限，给冷系统一个预热的时间，避免冷系统被压垮。

注意：这一效果只针对QPS流控，并发线程数流控不支持。

预热底层是根据令牌桶算法实现的，源码对应得类在​​com.alibaba.csp.sentinel.slots.block.flow.controller.WarmUpController​​。

算法中有一个冷却因子​​coldFactor​​，默认值是3，即请求 QPS 从 ​​**threshold(阈值) / 3**​​ 开始，经预热时长逐渐升至设定的 QPS 阈值。

比如设定QPS阈值为3，流控效果为warm up，预热时长为5秒，如下图：

这样配置之后有什么效果呢：QPS起初会从(3/3/=1)每秒通过一次请求开始预热直到5秒之后达到每秒通过3次请求。动态效果图如下：

从上述动画可以清楚的看见：前几秒是频繁流控的，直到5秒，QPS阈值达到了3。

具体算法原理请看：​​https://github.com/alibaba/Sentinel/wiki/%E9%99%90%E6%B5%81---%E5%86%B7%E5%90%AF%E5%8A%A8​​

排队等待

匀速排队方式会严格控制请求通过的间隔时间，也即是让请求以均匀的速度通过，对应的是漏桶算法。源码对应得类：​​com.alibaba.csp.sentinel.slots.block.flow.controller.RateLimiterController​​

注意：这一效果只针对QPS流控，并发线程数流控不支持。

简单举个栗子：你去大学食堂吃饭，只有一个阿姨在打饭，那么所有人都要排队打饭，每次只有一个人打到饭，其他人都在排队等待。

不同的是sentinel有个超时等待时间，一旦超过这个预定设置的时间将会被限流。

该方式作用如下图：

这种方式适合用于请求以突刺状来到，这个时候我们不希望一下子把所有的请求都通过，这样可能会把系统压垮；同时我们也期待系统以稳定的速度，逐步处理这些请求，以起到“削峰填谷”的效果，而不是拒绝所有请求。

比如设置QPS阈值为1，超时等待时间为10000毫秒，如下图：

此时的效果如下：

从上图可以看到：连续点击刷新请求，虽然设置了QPS阈值为1，但是并没有被限流，而是在等待，因为设置了超时等待时间为10秒。

具体算法原理请看：​​https://github.com/alibaba/Sentinel/wiki/%E6%B5%81%E9%87%8F%E6%8E%A7%E5%88%B6-%E5%8C%80%E9%80%9F%E6%8E%92%E9%98%9F%E6%A8%A1%E5%BC%8F​​

2、三种流控模式

流控模式总共分为三种，对应元素​​strategy​​，分别如下：

• 直接拒绝：接口达到限流条件时，直接限流
• 关联：当关联的资源达到阈值时，就限流自己
• 链路：只记录指定链路上的流量（指定资源从入口资源进来的流量，如果达到阈值，就可以限流）

下面来详细介绍下以上三种流控模式。

直接拒绝

顾名思义：默认的流量控制方式，当QPS超过任意规则的阈值后，新的请求就会被立即拒绝，拒绝方式为抛出​​FlowException​​。上面的几个例子都是配置了直接拒绝这个模式，这里不再详细介绍。

关联

典型的使用场景：一个是支付接口，一个是下单接口，此时一旦支付接口达到了阈值，那么订单接口就应该被限流，不然这边还在下单，消费者等待或者直接被拒绝支付将会极大的影响用户体验。

简而言之：A关联B，一旦B达到阈值，则A被限流

演示一下效果，创建以下两个接口：

@RestController
@RequestMapping("/sentinel")
public class FlowLimitController {

    /**
     * 下单接口
     * @return
     */
    @GetMapping("/order")
    public String order(){
        return "下单成功..........";
    }

    /**
     * 支付接口
     * @return
     */
    @GetMapping("/pay")
    public String pay(){
        return "支付成功..........";
    }
}

此时的流控规则配置如下图：

注意：关联之后，这里设置的限流规则是对被关联资源，也就是​​/sentinel/pay​​​这个资源，但是真正被限流则是​​/sentinel/order​​。

如何演示效果呢？很简单，只需要不断的请求​​/sentinel/pay​​​达到阈值，然后在请求​​/sentinel/order​​。

利用POSTMAN不断向​​/sentinel/pay​​​发出请求，然后浏览器请求​​/sentinel/order​​，结果如下图：

可以看到订单接口被限流了.............

3、两种统计类型

流控分为两种统计类型，分别是QPS，并发线程数，很多人不太明白这两种统计类型有什么区别？

举个栗子：陈某带了一个亿去银行存钱，但是银行大门保安要查健康码，每秒最多只能同时进入4个人，并且银行中只有两个工作人员工作，如下图：

此时的QPS含义：从保安到银行这一段，即是保安放行进入银行的人数。

此时并发线程数的含义：银行只有两个工作人员在工作，那么最多只能同时处理两个任务，这里并发线程数的阈值就是2。

8、降级规则如何配置？

熔断降级在日常生活中也是比较常见的，场景如下：

• 股票市场的熔断，当价格触发到了熔点之后，会暂停交易一段时间，或者交易可以继续进行，但是报价会限制在一定的范围。
• 电压过高导致保险丝触发熔断保护

在大型的分布式系统中，一个请求的依赖如下图：

如果这个时候，某个服务出现一些异常，比如：

• 服务提供者不可用(硬件故障、程序bug、网络故障、用户请求量较大)
• 重试导致的流量过大
• 服务调用者使用同步调用，产生大量的等待线程占用系统资源，一旦线程资源被耗尽，调用者提供的服务也会变成不可用状态

那么将会导致整个服务不可用，用古话来讲就是：千里之堤毁于蚁穴。

所谓编程源于生活，架构师们根据生活的经验设计出了服务的熔断降级策略，很好的解决了这类问题。

熔断降级规则对应sentinel控制台的降级规则这一栏，如下图：

熔断降级涉及到的几个属性如下表：

源码中对应得类为：​​com.alibaba.csp.sentinel.slots.block.degrade.DegradeRule​​。

三种熔断策略

Sentinel 提供以下几种熔断策略：

1. **平均响应时间 (**​​**DEGRADE_GRADE_RT**​​*)*：当 1s 内持续进入 5 个请求，对应时刻的平均响应时间（秒级）均超过阈值（​​count​​​，以 ms 为单位），那么在接下的时间窗口（​​DegradeRule​​​ 中的 ​​timeWindow​​​，以 s 为单位）之内，对这个方法的调用都会自动地熔断（抛出 ​​DegradeException​​）。注意 Sentinel 默认统计的 RT 上限是 4900 ms，超出此阈值的都会算作 4900 ms，若需要变更此上限可以通过启动配置项 ​​-Dcsp.sentinel.statistic.max.rt=xxx​​ 来配置。
2. **异常比例 (**​​**DEGRADE_GRADE_EXCEPTION_RATIO**​​*)*：当资源的每秒请求量 >= 5，并且每秒异常总数占通过量的比值超过阈值（​​DegradeRule​​​ 中的 ​​count​​​）之后，资源进入降级状态，即在接下的时间窗口（​​DegradeRule​​​ 中的 ​​timeWindow​​​，以 s 为单位）之内，对这个方法的调用都会自动地返回。异常比率的阈值范围是 ​​[0.0, 1.0]​​，代表 0% - 100%。
3. **异常数 (**​​**DEGRADE_GRADE_EXCEPTION_COUNT**​​*)*：当资源近 1 分钟的异常数目超过阈值之后会进行熔断。注意由于统计时间窗口是分钟级别的，若 ​​timeWindow​​ 小于 60s，则结束熔断状态后仍可能再进入熔断状态。

下面演示一个平均响应时间熔断，创建一个接口，如下：

@RestController
@RequestMapping("/sentinel/provider")
@Slf4j
public class FlowLimitController {

    @GetMapping("/test")
    public String test() throws InterruptedException {
        //休眠3秒钟
        Thread.sleep(3000);
        log.info("收到一条消息----test");
        return "接收到一条消息--------";
    }
}

在控台为这个接口设置平均响应时间为200毫秒，时间窗口为1秒，大致意思：平均的响应时间大于200毫秒之后，在接下来的1秒时间内将会直接熔断，如下图：

使用Jmeter开启10个线程循环跑，然后在浏览器中访问这个接口，返回结果如下图：

为什么呢？由于的接口中休眠了3秒，平均响应时间肯定大于200毫秒，因此直接被熔断了。

注意：这里熔断后直接返回默认的信息，后面会介绍如何定制熔断返回信息。

9、热点参数如何限流？

顾名思义：热点就是经常访问的数据，很多时候肯定是希望统计某个访问频次​​Top K​​数据并对其进行限流。

比如秒杀系统中的商品ID，对于热点商品那一瞬间的并发量是非常可怕的，因此必须要对其进行限流。

Sentinel 利用 LRU 策略统计最近最常访问的热点参数，结合令牌桶算法来进行参数级别的流控。

注意：热点参数限流只针对QPS。

官方文档：​​https://github.com/alibaba/Sentinel/wiki/%E7%83%AD%E7%82%B9%E5%8F%82%E6%95%B0%E9%99%90%E6%B5%81​​

概念理解了，来看下sentinel控制台如何设置热点参数限流，如下图：

规则对应得源码在​​com.alibaba.csp.sentinel.slots.block.flow.param.ParamFlowRule​​这个类中，各种属性含义如下图：

规则都懂了，下面我们通过实战来演示一下热点参数到底是如何限流的。

注意：热点参数限流只作用于八大基本类型。

1、创建一个资源

现在先创建一个service，用​​@SentinelResource​​这个注解定义一个资源，这个注解后续将会详细介绍，先忽略，代码如下：

@Service
@Slf4j
public class FlowServiceImpl implements FlowService {

    /**
     * @SentinelResource的value属性指定了资源名，一定要唯一
     * blockHandler属性指定了兜底方法
     */
    @Override
    @SentinelResource(value = "OrderQuery",blockHandler = "handlerQuery")
    public String query(String p1, String p2){
        log.info("查询商品，p1：{}，p2：{}",p1,p2);
        return "查询商品：success";
    }

    /**
     * 对应得兜底方法，一旦被限流将会调用这个方法来处理
     */
    public String handlerQuery(@RequestParam(value = "p1",required = false) String p1,
                               @RequestParam(value = "p2",required = false)String p2,
                               BlockException exception){
        log.info("查询商品，p1：{}，p2：{}",p1,p2);
        return "查询商品：熔断了......";
    }
}

上述代码什么意思呢？如下：

• 如果query这个接口没有被限流则返回：查询商品：success
• 如果query这个接口被限流了，则进入了兜底方法​​handlerQuery​​方法，返回：查询商品：熔断了......

2、创建controller接口

下面创建一个controller进行测试，代码如下：

@RestController
@RequestMapping("/sentinel/provider")
@Slf4j
public class FlowLimitController {
    @Autowired
    private FlowService flowService;

    @GetMapping("/order/query")
    public String query(@RequestParam(value = "p1",required = false) String p1, @RequestParam(value = "p2",required = false)String p2){
        return flowService.query(p1,p2);
    }

}

可以看到接口中有两个参数，分别是​​p1​​​、​​p2​​。

3、添加热点参数限流规则

在sentinel控制台点击​​热点规则->新增热点限流规则​​，添加如下图规则：

上述配置的具体含义：当​​OrderQuery​​这个资源中的第0个参数QPS超过1秒1次将会被限流。这里参数索引是从0开始，第0个就是对应接口中的​​p1​​这个参数。

第一个测试：浏览器直接访问：​​http://localhost:9009/sentinel/provider/order/query?p1=22&p2=1222，连续点击将会看到这个接口被熔断降级了，如下图：​​

这也正是验证了上述的热点参数限流配置。

第二个测试：浏览器输入：​​http://localhost:9009/sentinel/provider/order/query?p2=1222，连续点击将会看到这个接口并没有被熔断降级，如下图：​​

注意：对于热点参数限流，只有包含指定索引的参数请求才会被限流，否则不影响。

此时产品说：ID为100的这个产品点击量太少了，你们赶紧调整下这个商品的限流规则。这个时候该怎么办呢？

别着急，sentinel显然考虑到了这一点，提供了参数例外项这项配置，针对产品需求配置如下：

从上图配置中，我们将参数值p1这个参数值等于100的时候，限流阈值设置成了100，也就是说​​p1=100​​这个请求QPS放宽到1秒请求100次以上才会被限流。

验证：浏览器输入地址：​​http://localhost:9009/sentinel/provider/order/query?p1=100，无论点击多么快，都没有被熔断降级，显然是配置生效了，如下图：​​

10、系统自适应如何限流？

前面热点参数、普通流量限流都是针对的某个接口，这里系统自适应限流针对是整个系统的入口流量，从单台机器的 load、CPU 使用率、平均 RT、入口 QPS 和并发线程数等几个维度监控应用指标，让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。

sentinel控制台对应如下图：

阈值类型有五种，分别如下：

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

官方文档：​​https://github.com/alibaba/Sentinel/wiki/%E7%B3%BB%E7%BB%9F%E8%87%AA%E9%80%82%E5%BA%94%E9%99%90%E6%B5%81​​

系统规则的配置比较简单，这里以入口QPS为例进行演示，为了演示真实情况，清掉所有的限流规则，添加系统规则，如下图：

这个QPS系统规则一配置，该微服务中的所有接口都将会被这个规则限制，比如访问：​​http://localhost:9009/sentinel/provider/pay，连续点击，如下图：​​

可以看到已经被限流了，不仅是这个接口，所有接口都会生效。

注意：系统规则中的入口QPS这个规则不建议配置，一旦配置上了可能导致整个服务不可用。

文章转载自公众号： 码猿技术专栏