四、Sentinel控制台（二）流控规则介绍

---

流控规则

名词解释

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

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

• 阈值类型/单机阈值：

  • QPS（每秒钟的请求数量）：当调用该API的QPS达到阈值的时候，进行限流
  • 线程数：当调用该API的线程数量达到阈值的时候，进行限流

• 是否集群：当前不需要集群

• 流控模式：

  • 直接：API达到限流条件时，直接限流
  • 关联：当关联的资源达到阈值时，就限流自己
  • 链路：只记录指定链路上的流量（指定资源从入口资源进来的流量，如果达到阈值，就进行限流）(API级别的针对来源)

• 流控效果：

  • 快速失败：直接失败，抛异常

  • Wam Up：根据codeFactor（冷加载因子，默认3）的值，从阈值/codeFacotor，经过预热时长，才达到设置的QPS阈值

  • 排队等待：匀速排队，让请求以匀速的速度通过，阈值类型必须设置为QPS，否则无效

规则

（1）直接-QPS直接失败案例

这里的意思就是我们现在单机阈值设定为1，代表的是当前这个接口只能被1秒访问一次，超过这个阈值，就会被Sentinel阻塞，现在默认为直接失败。

流控效果：

（2）直接-线程数直接失败案例

此时修改代码：

@GetMapping("/testA")
public String testA(){
    //暂停0.8秒
    try {
        TimeUnit.MILLISECONDS.sleep(800);
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
    return "-----testA";
}

测试方法：

方法一：双浏览器测试（F5刷新）

先快速刷新第一个浏览器

再快速刷新第二个浏览器，此时可以看到流控效果

方法二：postman测试

把数值修改为：

• Iterations：为50
• Delay：300

意思就是50个线程每间隔0.3秒访问一次

点击Run Sentinel, 此时我们来看网页中testA接口的流控效果

方法三：jemter测试

流控效果:

QPS和并发线程数规则详解:

（3）关联

​ 官方解释：当关联的资源达到阈值时，就限流自己。

​ 通俗解释来说，比如那我们的程序，现在有testA接口和testB接口，当A关联的资源B达到阈值后，限流A本身。换到程序里面来说比如一个电商系统中，支付系统达到阈值，就限流下订单系统。

流控效果:

（4）链路

链路流控模式指的是，当从某个接口过来的资源达到限流条件时，开启限流，它的功能有点类似于针对来源配置项，区别在于：针对来源是针对上级微服务，而链路流控是针对上级接口，也就是说它的粒度更细。

​ 比如在一个微服务中，两个接口都调用了同一个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(){
        log.info(Thread.currentThread().getName()+": testA");
        return testService.common();
    }

    @GetMapping("/testB")
    public String testB(){
        return testService.common();
    }
}

让Sentinel 源码中 CommonFilter 中的 WEB_CONTEXT_UNIFY 参数为 false，将其配置为 false 即可根据不同的URL 进行链路限流，如果不配置将不会生效。

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
      # 配置为false
      web-context-unify: false

这是因为从1.6.3 版本开始， Sentinel Web filter默认收敛所有URL的入口context

1.7.0 版本开始（对应Spring Cloud Alibaba的2.1.1.RELEASE)，官方在引入了spring.cloud.sentinel.web-context-unify 参数，用于控制是否收敛context；将其配置为 false 即可根据不同的URL 进行链路限流。

web-context-unify 为true的时候，取到的是收敛的context名称sentinel_spring_web_context；为false的时候，就可以正确地取到/testA 资源名。

接下来配置流控规则：

这里要注意不要对/testA或者/testB进行限流规则的配置，要给用SentinelResource注解标注的资源进行配置限流规则，这里的意思为当我们用入口资源访问被SentinelResource注解标注的资源方法时，当超过阈值就会被限流。

最后这个时候我们再来频繁的访问testA接口，就会出现异常的情况，这也是流量效果快速失败在链路上的体现，是直接抛出异常。

然后访问testB接口，不受影响

（5）预热

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

使用场景：一般秒杀系统中会有这样的流控设置，为了防止秒杀瞬间造成系统崩溃。

默认coldFactor为3，当发起请求即请求QPS从（阈值/3）开始，经过多长预热时长才逐步升至设定的QPS阈值，当前阈值设置为10，预热时长设置为5秒。

​ 最终的效果，系统初始化时阈值/3约等于3，即阈值在此时为3，经过5秒后阈值才慢慢升高到10

流控效果（postman测试更直观）：

（6）排队等待

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

该方式的作用如下图所示：

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

注意：匀速排队模式暂时不支持 QPS > 1000 的场景。

匀速器

​ 它的中心思想是，以固定的间隔时间让请求通过。当请求到来的时候，如果当前请求距离上个通过的请求通过的时间间隔不小于预设值，则让当前请求通过。否则，计算当前请求的预期通过时间，如果该请求的预期通过时间小于规则预设的 timeout 时间，则该请求会等待直到预设时间到来通过（排队等待处理）；若预期的通过时间超出最大排队时长，则直接拒接这个请求。

流控效果（postman测试更直观）：