雪崩问题虽然有四种方案，但是限流是避免服务因突发的流量而发生故障，是对微服务雪崩问题的预防。

簇点链路

当请求进入微服务时，首先会访问DispatcherServlet，然后进入Controller、Service、Mapper，这样的一个调用链就叫做簇点链路。簇点链路中被监控的每一个接口就是一个资源。
默认情况下sentinel会监控SpringMVC的每一个端点（Endpoint，也就是controller中的接口方法），因此SpringMVC的每一个端点（Endpoint）就是调用链路中的一个资源。
例如，我们刚才访问的order-service中的OrderController中的端点：/order/{orderId}
image.png
流控、熔断等都是针对簇点链路中的资源来设置的，因此我们可以点击对应资源后面的按钮来设置规则：

  • 流控：流量控制
  • 降级：降级熔断
  • 热点：热点参数限流，是限流的一种
  • 授权：请求的权限控制

    基础控流测试

    点击/order/{orderId}后面的控流按钮，可以弹出表单，表单中可以填写限流规则，如下
    image.png
    其含义是限制 /order/{orderId}这个资源的单机QPS为5，即每秒只允许5次请求，超出的请求会被拦截并报错。

然后我们打开JMeter，设置2秒内发20个请求到/order/{orderId}接口，QPS就是10，每秒10个请求
image.png
结果就会看到1秒只有5个请求成功
image.png
sentinel控制台实时监控
image.png

流控模式

在添加限流规则时，点击高级选项，可以选择三种流控模式：

  • 直接：统计当前资源的请求，触发阈值时对当前资源直接限流，也是默认的模式
  • 关联：统计与当前资源相关的另一个资源，触发阈值时，对当前资源限流
  • 链路：统计从指定链路访问到本资源的请求，触发阈值时，对指定链路限流

image.png

1.直接模式

基础控流测试就是直接模式。

2.关联模式

关联模式：统计与当前资源相关的另一个资源，触发阈值时，对当前资源限流
image.png
语法说明：当/write资源访问量触发阈值时，就会对/read资源限流，避免影响/write资源。
使用场景：比如用户支付时需要修改订单状态，同时用户要查询订单。查询和修改操作会争抢数据库锁，产生竞争。业务需求是优先支付和更新订单的业务，因此当修改订单业务触发阈值时，需要对查询订单业务限流。
满足以下条件可以使用关联模式：

  • 两个有竞争关系的资源

  • 一个优先级较高，一个优先级较低

    测试

    我们在order-service模块里面加入两个接口，不用实现逻辑，然后重启该服务，调用两个接口后，在sentinel控制台中查看簇点链路

    1.   @GetMapping("/query")
    2.   public String queryOrder() {
    3.       return "查询订单成功";
    4.   }
    5.   @GetMapping("/update")
    6.   public String updateOrder() {
    7.       return "更新订单成功";
    8.   }

    image.png
    对哪个端点限流，就点击哪个端点后面的按钮。我们是对订单查询/order/query限流，因此点击它后面的控流按钮：
    image.png
    用JMeter测试/order/update接口，请求1000，时间100秒，QPS10。
    测试在运行期间可以看到/order/update超过阈值了，但是没有限流
    image.png
    在这100秒期间，我们去看/order/query请求，报429错误，被限流了。
    image.png

    3.链路模式

    链路模式：只针对从指定链路访问到本资源的请求做统计，判断是否超过阈值。
    配置示例：
    例如有两条请求链路：

  • /test1 —> /common

  • /test2 —> /common

如果只希望统计从/test2进入到/common的请求，则可以这样配置：
image.png

测试

需求：有查询订单和创建订单业务，两者都需要查询商品。针对从查询订单进入到查询商品的请求统计，并设置限流。
我们先在OrderController中添加两个接口，查询订单和添加订单，两个接口都去调用OrderService里面的查询商品

  1.     @GetMapping("/query")
  2.     public String queryOrder() {
  3.         orderService.queryGoods();
  4.         System.out.println("查询订单成功");
  5.         return "查询订单成功";
  6.     }
  8.     @GetMapping("/save")
  9.     public String saveOrder() {
  10.         orderService.queryGoods();
  11.         System.out.println("添加订单成功");
  12.         return "添加订单成功";
  13.     }

默认情况下，Service层的方法是不被Sentinel监控的，需要我们自己通过注解来标记要监控的方法。
给OrderService的queryGoods方法添加@SentinelResource注解：

  1.     //不取名，在sentinel里面默认就是全类名
  2.     @SentinelResource("goods")
  3.     public void queryGoods() {
  4.         System.out.println("查询商品成功");
  5.     }

链路模式中，是对不同来源的两个链路做监控。但是sentinel默认会给进入SpringMVC的所有请求设置同一个root资源，会导致链路模式失效。
image.png
我们需要关闭这种对SpringMVC的资源聚合，修改order-service服务的application.yml文件：

  1. spring:
  2.   cloud:
  3.     sentinel:
  4.       web-context-unify: false # 关闭context整合

重启服务，访问/order/query和/order/save，可以查看到sentinel的簇点链路规则中，出现了新的资源，链路被分开了：
image.png
点击goods资源后面的流控按钮，在弹出的表单中填写下面信息：
只统计从/order/query进入/goods的资源，QPS阈值为2，超出则被限流
image.png
用JMeter给新增和查询两个接口发请求，请求数量200，请求时间50秒，QPS4
从/order/save进入goods的接口没有被限流
image.png
而从/order/query进入goods的接口被限流了
image.png

流控效果

在流控的高级选项中，还有一个流控效果选项：
image.png
流控效果是指请求达到流控阈值时应该采取的措施，包括三种：

  • 快速失败：达到阈值后，新的请求会被立即拒绝并抛出FlowException异常。是默认的处理方式。
  • warm up：预热模式，对超出阈值的请求同样是拒绝并抛出异常。但这种模式阈值会动态变化，从一个较小值逐渐增加到最大阈值。

  • 排队等待：让所有的请求按照先后次序排队执行，两个请求的间隔不能小于指定时长

    1.快速失败

    默认处理方式，限流就报错429

    2.Warm Up

    阈值一般是一个微服务能承担的最大QPS，但是一个服务刚刚启动时，一切资源尚未初始化（冷启动），如果直接将QPS跑到最大值，可能导致服务瞬间宕机。
    warm up也叫预热模式，是应对服务冷启动的一种方案。请求阈值初始值是 maxThreshold / coldFactor，持续指定时长后，逐渐提高到maxThreshold值。而coldFactor的默认值是3.
    例如，我设置QPS的maxThreshold为10，预热时间为5秒，那么初始阈值就是 10 / 3 ，也就是3，然后在5秒后逐渐增长到10.
    image-20210716110629796.png

    测试

    需求：给/order/{orderId}这个资源设置限流，最大QPS为50，利用warm up效果，预热时长为30秒
    image.png
    JMeter发300个请求，时间15秒，QPS正好是该资源最大QPS20
    刚启动时通过的请求不多
    image.png
    随着时间的推移，通过的请求越来越多
    image.png
    在sentinel控制台可以看到，通过的QPS越来越高，，拒绝的QPS越来越少，用Warm Up流控效果，QPS是逐渐增加的
    image.png

    3.排队等待

    当请求超过QPS阈值时，快速失败和warm up 会拒绝新的请求并抛出异常。
    而排队等待则是让所有请求进入一个队列中，然后按照阈值允许的时间间隔依次执行。后来的请求必须等待前面执行完成，如果请求预期的等待时间超出最大时长，则会被拒绝。
    工作原理
    例如：QPS = 5，每秒执行5个请求，意味着每200ms处理一个队列中的请求；超时时间= 2000，意味着预期等待时长超过2000ms的请求会被拒绝并抛出异常。
    那什么叫做预期等待时长呢？
    比如现在一下子来了12 个请求，因为每200ms执行一个请求，那么：

  • 第6个请求的预期等待时长 = 200 * （6 - 1） = 1000ms

  • 第12个请求的预期等待时长 = 200 * （12-1） = 2200ms

现在，第1秒同时接收到10个请求，但第2秒只有1个请求，此时QPS的曲线这样的：
image-20210716113147176.png
如果使用排队等待模式做流控，所有进入的请求都要排队，以固定的200ms的间隔执行，QPS会变的很平滑：
image-20210716113426524.png
平滑的QPS曲线，对于服务器来说是更友好的。

测试

需求：给/order/{orderId}这个资源设置限流，最大QPS为10，也就是每100ms处理一个请求，利用排队的流控效果，超时时长设置为5000ms。
Jmeter设置请求数量300个，时间20秒，QPS为15，已经超过了我们设定的10。
如果是之前的 快速失败、warmup模式，超出的请求应该会直接报错。

我们看实时监控：
QPS非常平滑，一致保持在10，但是超出的请求没有被拒绝，而是放入队列。因此响应时间（等待时间）会越来越长。
当队列满了以后，才会有部分请求失败：
image.png

参数限流

之前的限流是统计访问某个资源的所有请求，判断是否超过QPS阈值。而热点参数限流是分别统计参数值相同的请求，判断是否超过QPS阈值。

全局参数限流

例如，一个根据id查询商品的接口：
image-20210716115014663.png
访问/goods/{id}的请求中，id参数值会有变化，热点参数限流会根据参数值分别统计QPS，统计结果：
image-20210716115131463.png
当id=1的请求触发阈值被限流时，id值不为1的请求不受影响。

在簇点链路中点击后面的热点按钮，这个按钮没有高级选项，只能用于全局参数限流，高级选项看下面的热点参数限流

image.png
代表的含义是：对/order/{orderId}这个资源的某参数做统计，每1秒相同参数值的请求数不能超过 单机阈值

热点参数限流

刚才的配置中，对查询商品这个接口的所有商品一视同仁，QPS都限定为5.
而在实际开发中，可能部分商品是热点商品，例如秒杀商品，我们希望这部分商品的QPS限制与其它商品不一样，高一些。那就需要配置热点参数限流的高级选项了：

点击sentinel控制台左边的菜单，热点规则，然后点击新增热点规则才有高级选项

image.png
结合上一个配置，这里的含义是对0号的long类型参数限流，每1秒相同参数的QPS不能超过2，有两个例外：

  • 如果参数值是102，则每1秒允许的QPS为4
  • 如果参数值是103，则每1秒允许的QPS为10

    测试

    根据上图的设置进行测试 :::danger 注意事项：热点参数限流对默认的SpringMVC资源无效，需要利用@SentinelResource注解标记资源 :::
    1.   @SentinelResource("hot")
    2.   @GetMapping("{orderId}")
    3.   public Order queryOrderByUserId(@PathVariable("orderId") Long orderId) {
    4.       // 根据id查询订单并返回
    5.       return orderService.queryOrderById(orderId);
    6.   }
    用JMeter发三个http请求，QPS为5，是哪个请求的参数分别是101，102，103
    结果树为下面这样
    image.pngimage.pngimage.png