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

簇点链路

簇点链路：就是项目内的调用链路，链路中被监控的每个接口就是一个资源。

当请求进入微服务时，首先会访问 DispatcherServlet，然后进入 Controller、Service、Mapper，这样的一个调用链就叫做簇点链路。簇点链路中被监控的每一个接口就是一个资源。

默认情况下 sentinel 会监控 SpringMVC 的每一个端点（Endpoint，也就是 controller 中的方法），因此 Spring MVC 的每一个端点（Endpoint）就是调用链路中的一个资源。

例如，我们刚才访问的 order-service 中的 OrderController 中的端点：/order/{orderId}

流量控制 - 图1

流控、熔断等都是针对簇点链路中的资源来设置的，因此我们可以点击对应资源后面的按钮来设置规则：

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

快速入门

点击资源 /order/{orderId} 后面的流控按钮，就可以弹出表单。

表单中可以填写限流规则，如下：

流量控制 - 图2

其含义是限制 /order/{orderId} 这个资源的单机 QPS 为 1，即每秒只允许 1 次请求，超出的请求会被拦截并报错。

需求：给 /order/{orderId} 这个资源设置流控规则，QPS 不能超过 5，然后利用 JMeter 测试。

流控模式

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

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

快速入门测试的就是直接模式。

关联模式

关联模式：统计与当前资源相关的另一个资源，触发阈值时，对当前资源限流

使用场景：比如用户支付时需要修改订单状态，同时用户要查询订单。查询和修改操作会争抢数据库锁，产生竞争。业务需求是有限支付和更新订单的业务，因此当修改订单业务触发阈值时，需要对查询订单业务限流。

配置规则：

流量控制 - 图3

语法说明：当 /write 资源访问量触发阈值时，就会对 /read 资源限流，避免影响 /write 资源。

需求说明：

  • 在 OrderController 新建两个端点：/order/query 和 /order/update，无需实现业务
  • 配置流控规则，当 /order/update 资源被访问的 QPS 超过 5 时，对 /order/query 请求限流

定义 /order/query 端点，模拟订单查询

  1. @GetMapping("/query")
  2. public String queryOrder() {
  3.     return "查询订单成功";
  4. }

定义 /order/update 端点，模拟订单更新

  1. @GetMapping("/update")
  2. public String updateOrder() {
  3.     return "更新订单成功";
  4. }

重启服务，查看 sentinel 控制台的簇点链路

配置流控规则，对哪个端点限流，就点击哪个端点后面的按钮。我们是对订单查询 /order/query 限流，因此点击它后面的按钮，在表单中填写流控规则：

流量控制 - 图4

在 JMeter 测试

满足下面条件可以使用关联模式：

  • 两个有竞争关系的资源
  • 一个优先级较高，一个优先级较低

链路模式

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

配置示例：

例如有两条请求链路：

  • /test1 → /common
  • /test2 → /common

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

流量控制 - 图5

案例需求：有查询订单和创建订单业务，两者都需要查询商品。针对从查询订单进入到查询商品的请求统计，并设置限流。

步骤：

  1. 在 OrderService 中添加一个 queryGoods 方法，不用实现业务
  2. 在 OrderController 中，改造 /order/query 端点，调用 OrderService 中的 queryGoods 方法
  3. 在 OrderController 中添加一个 /order/save 的端点，调用 OrderService 的 queryGoods 方法
  4. 给 queryGoods 设置限流规则，从 /order/query 进入 queryGoods 的方法限制QPS必须小于2

添加查询商品方法，在 order-service 服务中，给 OrderService 类添加一个 queryGoods 方法：

  1. public void queryGoods(){
  2.     System.err.println("查询商品");
  3. }

查询订单时，查询商品，在 order-service 的 OrderController 中，修改 /order/query 端点的业务逻辑：

  1. @GetMapping("/query")
  2. public String queryOrder() {
  3.     // 查询商品
  4.     orderService.queryGoods();
  5.     // 查询订单
  6.     System.out.println("查询订单");
  7.     return "查询订单成功";
  8. }

新增订单，查询商品，在 order-service 的 OrderController 中，添加 /order/save 端点，模拟新增订单：

  1. @GetMapping("/save")
  2. public String saveOrder() {
  3.     // 查询商品
  4.     orderService.queryGoods();
  5.     // 查询订单
  6.     System.err.println("新增订单");
  7.     return "新增订单成功";
  8. }

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

  1. @SentinelResource("goods")
  2. public void queryGoods(){
  3.     System.err.println("查询商品");
  4. }

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

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

重启服务，访问 /order/query 和 /order/save，可以查看到 Sentinel 的簇点链路规则中，出现了新的资源：

流量控制 - 图6

添加流控规则，点击 goods 资源后面的流控按钮，在弹出的表单中填写下面信息：

流量控制 - 图7

只统计从 /order/query 进入 /goods 的资源，QPS 阈值为 2，超出则被限流。最后使用 JMeter 测试。

流控模式总结

  • 直接：对当前资源限流
  • 关联：高优先级资源触发阈值，对低优先级资源限流。
  • 链路：阈值统计时，只统计从指定资源进入当前资源的请求，是对请求来源的限流

流控效果

在流控的高级选项中，还有一个流控效果选项：

流控效果是指请求达到流控阈值时应该采取的措施，包括三种：

  • 快速失败：达到阈值后，新的请求会被立即拒绝并抛出 FlowException 异常。是默认的处理方式。
  • Warm Up：预热模式，对超出阈值的请求同样是拒绝并抛出异常。但这种模式阈值会动态变化，从一个较小值逐渐增加到最大阈值。
  • 排队等待：让所有的请求按照先后次序排队执行，两个请求的间隔不能小于指定时长

Warm Up

阈值一般是一个微服务能承担的最大 QPS，但是一个服务刚刚启动时，一切资源尚未初始化（冷启动），如果直接将 QPS 跑到最大值，可能导致服务瞬间宕机。

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

例如，我设置 QPS 的 maxThreshold 为 10，预热时间为 5 秒，那么初始阈值就是 10 / 3 ，也就是 3，然后在 5 秒后逐渐增长到 10。

流量控制 - 图8

案例需求：给 /order/{orderId} 这个资源设置限流，最大 QPS 为 10，利用 Warm Up 效果，预热时长为 5 秒

排队等待

当请求超过 QPS 阈值时，快速失败和 Warm Up 会拒绝新的请求并抛出异常。

而排队等待则是让所有请求进入一个队列中，然后按照阈值允许的时间间隔依次执行。后来的请求必须等待前面执行完成，如果请求预期的等待时间超出最大时长，则会被拒绝。

工作原理

例如：QPS = 5，意味着每 200ms 处理一个队列中的请求；timeout = 2000，意味着预期等待时长超过 2000ms 的请求会被拒绝并抛出异常。

那什么叫做预期等待时长呢？

比如现在一下子来了 12 个请求，因为每 200ms 执行一个请求，那么：

  • 第 6 个请求的预期等待时长 = 200 * (6 - 1) = 1000ms
  • 第 12 个请求的预期等待时长 = 200 * (12-1) = 2200ms

现在，第 1 秒同时接收到 10 个请求，但第 2 秒只有 1 个请求，此时 QPS 的曲线这样的：

流量控制 - 图9

如果使用队列模式做流控，所有进入的请求都要排队，以固定的 200ms 的间隔执行，QPS 会变的很平滑

流量控制 - 图10

平滑的 QPS 曲线，对于服务器来说是更友好的。

案例需求：给 /order/{orderId} 这个资源设置限流，最大 QPS 为 10，利用排队的流控效果，超时时长设置为 5s

流控效果总结

  • 快速失败：QPS 超过阈值时，拒绝新的请求
  • Warm Up： QPS 超过阈值时，拒绝新的请求；QPS 阈值是逐渐提升的，可以避免冷启动时高并发导致服务宕机。
  • 排队等待：请求会进入队列，按照阈值允许的时间间隔依次执行请求；如果请求预期等待时长大于超时时间，直接拒绝

热点参数限流

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

全局参数限流

例如，一个根据 id 查询商品的接口，访问 /goods/{id} 的请求中，id 参数值会有变化，热点参数限流会根据参数值分别统计 QPS，统计结果：

流量控制 - 图11

当 id=1 的请求触发阈值被限流时，id 值不为 1 的请求不受影响。

配置示例：

流量控制 - 图12

代表的含义是：对 hot 这个资源的 0 号参数（第一个参数）做统计，每 1 秒相同参数值的请求数不能超过 5

热点参数限流

刚才的配置中，对查询商品这个接口的所有商品一视同仁，QPS 都限定为 5。

而在实际开发中，可能部分商品是热点商品，例如秒杀商品，我们希望这部分商品的 QPS 限制与其它商品不一样，高一些。那就需要配置热点参数限流的高级选项了：

流量控制 - 图13

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

  • 如果参数值是 100，则每 1 秒允许的 QPS 为 10
  • 如果参数值是 101，则每 1 秒允许的 QPS 为 15

示范案例

案例需求：给 /order/{orderId} 这个资源添加热点参数限流，规则如下：

  • 默认的热点参数规则是每 1 秒请求量不超过 2
  • 给 102 这个参数设置例外：每 1 秒请求量不超过 4
  • 给 103 这个参数设置例外：每 1 秒请求量不超过 10

注意事项：热点参数限流对默认的 Spring MVC 资源无效，需要利用 @SentinelResource 注解标记资源

标记资源，给 order-service 中的 OrderController 中的 /order/{orderId} 资源添加注解：

@SentinelResource("hot")
@GetMapping("{orderId}")
public Order queryOrderByUserId(@PathVariable("orderId") Long orderId) {
    // 根据 id 查询订单并返回
    return orderService.queryOrderById(orderId);
}

热点参数限流规则，访问该接口，可以看到我们标记的 hot 资源出现了，这里不要点击 hot 后面的按钮，页面有Bug，没有高级选项，点击左侧菜单中热点规则菜单：
流量控制 - 图14
点击新增，填写表单：
流量控制 - 图15