1. 前言

在前面的文章中，已经介绍过了 Sentinel安装和基本使用。这次主要讲的是Sentinel 的流量控制规则，使用版本为1.8.0，它提供了以下几个配置项：

在这里插入图片描述

资源名： 唯一名称，默认是接口的请求路径
针对来源： Sentinel可以针对调用者限流，填写微服务名称，默认default（不区分来源）
阈值类型/单机阈值：
- QPS：当调用该API的QPS达到阈值，进行限流
- 线程数：当调用该API的线程数达到阈值，进行限流
是否集群： 不需要
流控模式：
- 直接：该API达到限流条件，进行限流
- 关联：当关联的资源达到阈值，就限流自己
- 链路：只记录指定链路上的流量，指定资源从入口资源进来的流量，如果达到条件，就进行限流（API级别的针对来源）
流控效果：
- 快速失败：直接失败，抛出异常
- Warm Up：根据codeFactor（冷加载因子，默认3），从阈值/codeFactor 开始，经过配置的预热时长，才达到设定的QPS阈值
- 排队等待：匀速排队，让请求以匀速的速度通过，阈值类型必须设置为QPS，否则无效

2. 阈值类型

2.1 QPS

Queries Per Second，每秒请求量。

首先，我们给 /test 接口配置如下流控规则。

配置项	值
QPS	10
流控规则	直接
流控效果	快速失败

接着，启动JMeter在1秒内发送20个请求。结果就是产生大量异常，直接报错Blocked by Sentinel (flow limiting) ，说明Sentinel拦截生效

在这里插入图片描述

2.2 线程数

将上一步的 QPS 改成线程数，阈值设置为2，测试结果如下：
在这里插入图片描述
竟然所有请求都通过了，这是因为CPU的执行速度远远超出了我们的想象，并非每个HTTP请求都会New出新的线程进行执行，可能一个线程就全部处理掉了。为了让CPU创建大量线程，我们改下接口代码：

    @GetMapping("/test")
    public String test(){
    
    
        try {
    
    
            Thread.sleep(1000);
        } catch (InterruptedException e) {
    
    
            e.printStackTrace();
        }
        return "test";
    }

重新执行JMeter，结果如下，符合预期：
在这里插入图片描述

3. 流控模式

3.1 直接

针对当前资源的接口进行控制，前面的例子用的就是这项配置

3.2 关联

当关联的资源达到阈值，就限流自己。例如：当支付接口的调用达到阈值，就限制下单接口。

创建另一个接口 /test2，针对/test资源配置如下限流规则：
在这里插入图片描述
接下来，使用JMeter对/test2接口发起大量请求。然后，立刻马上在浏览器访问/test，就能重现Blocked by Sentinel (flow limiting)的异常。这就是关联流控的使用方式。

3.3 链路

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

举个例子：

创建一个OrderService，里面写个getOrder方法，并加上 @SentinelResource 注解，表示当前方法资源名称是 getOrder

@Service
public class OrderServiceImpl implements OrderService {
    
    

    @SentinelResource(value = "getOrder")
    @Override
    public String getOrder(String id) {
    
    
        return "Order:" + id;
    }
}

在controller分别创建2个接口：order1、order2

    @GetMapping("/order1")
    public String order1(){
    
    
        return orderService.getOrder("111");
    }

    @GetMapping("/order2")
    public String order2(){
    
    
        return orderService.getOrder("222");
    }