一文让你搞懂 sentinel 流量控制_sentinel 网关流量控制-优快云博客

本文链接：https://blog.youkuaiyun.com/weixin_46209120/article/details/132080865

1.雪崩问题及解决方案

1.1.雪崩问题

微服务中，服务间调用关系错综复杂，一个微服务往往依赖于多个其它微服务。在同一调用链路的多个服务提供者中，如果其中一个服务提供者 D 发生了故障，那么依赖于服务 D 的业务就都会被阻塞。此时，其它不依赖于服务 D 的业务似乎不受影响。

但是，依赖服务 D 的业务请求被阻塞，用户得不到响应，则tomcat的这个线程不会释放，于是越来越多的用户请求到来，越来越多的线程会被阻塞。

服务器支持的线程和并发数有限，请求一直阻塞，会导致服务器资源耗尽，从而导致所有其它服务都不可用，那么当前服务也就不可用了。而依赖于当前服务的其它服务随着时间的推移，最终也都会变的不可用，形成级联失败，雪崩就发生了

1.2.解决雪崩问题的常见方式

1.2.1.超时处理

设定超时时间，请求超过一定时间没有响应就返回服务超时或异常信息，不会无休止等待，可以有效的防止其拖垮服务。

1.2.2.仓壁模式

仓壁模式来源于船舱的设计：

船舱都会被隔板分离为多个独立空间，当船体破损时，只会导致部分空间进水，将故障控制在一定范围内，避免整个船体都被淹没。

于此类似，我们可以限定每个业务能使用的线程数，避免耗尽整个tomcat的资源，因此也叫线程隔离。

1.2.2.断路器

断路器模式：由断路器统计业务执行的异常比例，如果超出阈值则会熔断该业务，拦截访问该业务的一切请求。

如下图，当发现访问服务D的请求异常比例过高时，认为服务D有导致雪崩的风险，会拦截访问服务D的一切请求，形成熔断，在实际的业务场景中熔断常会配合降级一起使用，尽可能的提高用户的体验感。

1.2.4.限流

流量控制：限制业务访问的QPS，避免服务因流量的突增而故障，流量控制网关层也是可以实现的，不过比起网关，sentinel控制的粒度会更细

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

2.流量控制

2.1.簇点链路

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

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

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

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

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

2.1.1.示例

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

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

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

当我手速快一点的时候，就会报以上的问题，sentinel 流量限制。

这里还可以用Jmeter测试，不懂的Jmeter测试的，可以移步下面这篇文章。

2.2.流控模式

直接: 当前资源请求数量达到阈值时,对当前资源做限流
关联: 统计与当前资源相关的另一个资源，触发阈值时，对当前资源限流
链路: 多条链路访问同一个资源,同一个资源达到阈值时,我们可以对其中的某条链路做限流

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

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

2.2.1.关联模式

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

举个例子，我们有一个两个接口共用一个资源，两个接口分别为修改库存数和查询库存数。资源则为库存总数。

当 /update 接口访问量触发阈值时，就会对 /select 接口进行限流，避免影响 /update 的接口，因为很多时候，比起查询，写的操作是更为重要的，所以我们需要优化保证写入没有问题。

我们在OrderController添加两个接口来示例：

场景：在秒杀商品时用户下单后需要修改库存数量，同时有其他用户在查询库存。查询和修改操作会并发的执行，产生竞争。业务需求是优先更新库存的业务，因此当修改库存业务触发阈值时，需要对查询库存业务进行限流。

模拟库存更新和库存查询：

@GetMapping("/update")
    public String update() {
    return "更新库存成功";
}

@GetMapping("/select")
    public String select() {
    return "查询库存成功";
}

重启服务，分别访问一下我们新增的两个接口

查看sentinel控制台的簇点链路：

新增一个流控规则

我们配置流控规则时，是需要对哪个接口做流控，就在哪个接口上配置，这里是需要对查询的接口做流量控制，所以需要在查询的接口上增加流控规则

以上配置好后，当关联资源到达阈值5时,就会对当前查询的资源进行限流

使用jmeter配合浏览器测试

我们这里模拟访问/update资源，在100秒里1000个线程访问/update，也就是说这个接口每秒需要处理10个请求，因此QPS为10，而我们上面配置的阈值是5，那么selcet资源这时候肯定是被限流了的，因为/update的请求超过了 5 这个阈值了

以上jmeter脚本有需要的小伙伴可以去我网盘下载：TODO

我们启动，让jmeter跑起来

再到浏览器里访问 /select 资源，可以发现，这里是直接访问不了的，不管你怎么刷新，只要jmeter中的请求保持在每秒 5 个以上，那么 /selcet 资源就会一直被限流

关联模式的使用场景

1.两个资源存在竞争关系

2.两个资源一个优先级高，一个优先级低

2.2.2.链路模式

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

例如有两条请求链路：

/order/query --> /goods
/order/save--> /goods

如果希望统计从/order/query进入到/goods的请求流量过大时，能够被限制，则可以这样配置：

案例演示

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

步骤：

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

1）添加查询商品方法

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

public void queryGoods(){
    System.out.println("查询商品");
}

2）查询订单时，查询商品

在order-service的OrderController中，修改/order/query端点的业务逻辑：

@GetMapping("/query")
public String queryOrder() {
    // 查询商品
    orderService.queryGoods();
    // 查询订单
    System.out.println("查询订单");
    return "查询订单成功";
}

3）新增订单，查询商品

在order-service的OrderController中，修改/order/save端点，模拟新增订单：

@GetMapping("/save")
public String saveOrder() {
    // 查询商品
    orderService.queryGoods();
    // 查询订单
    System.err.println("新增订单");
    return "新增订单成功";
}

4）给查询商品添加资源标记

默认情况下，OrderService中的方法是不被Sentinel监控的，需要我们自己通过注解来标记要监控的方法。

给OrderService的queryGoods方法添加@SentinelResource注解：

@SentinelResource("goods")
public void queryGoods(){
   System.out.println("查询商品");
}

链路模式中，是对不同来源的两个链路做监控。但是sentinel默认会给进入SpringMVC的所有请求设置同一个root资源，会导致链路模式失效。

我们需要关闭这种对SpringMVC的资源聚合，修改order-service服务的application.yml文件：

spring:
  cloud:
    sentinel:
      web-context-unify: false # 关闭context整合

重启服务，访问/order/query和/order/save

可以查看到sentinel的簇点链路规则中，出现了新的资源：

5）添加流控规则

点击/order/query下的goods资源后面的流控按钮，在弹出的表单中填写下面信息：

只统计从/order/query进入/goods的资源，QPS阈值为2，超出则被限流。

6）Jmeter测试

可以看到这里模拟200个用户线程，50秒内请求完，也就是每秒处理4个请求，QPS为4，超过了我们设定的阈值2

我们这里配置两个请求，一个是query，一个是save

访问/order/save，运行的结果完全不受影响。

访问/order/query，运行结果，每次只有2个通过。

所以这里的限流就是起到效果的。

以上就是我们演示的sentinel三种流控模式

•直接：对当前资源限流

•关联：高优先级资源触发阈值，对低优先级资源限流。

•链路：阈值统计时，只统计从指定资源进入当前资源的请求，是对请求来源的限流

2.3.流控效果

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

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

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

2.3.1.warm up 预热模式

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

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

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

案例

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

1）配置流控规则：

2）Jmeter测试

20秒内执行200个线程，也就是一秒10个，QPS为10

刚刚启动时，大部分请求失败，成功的只有3个，说明QPS被限定在3：

随着时间推移，成功比例越来越高：

一段时间后：

证明这里的流控效果设置是起到作用的，可以对预热阶段的服务器起到保护。

2.3.2.排队等待

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

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

工作原理

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

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

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

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

假如第1秒同时接收到10个请求，但第2秒没有接收到请求，此时因为我们设置了阈值为5的原因，第一秒只能处理5个请求，而多出来的5个请求将会在第二秒的时候全部处理掉。

案例演示

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

1）添加流控规则

直接编辑这个我们前面讲的预热规则改为排队规则，这里的超时时间是毫秒为单位

阈值为5，也就是每秒能处理5个请求，如果我们第一秒来了30个请求，如果这时候为直接规则的话，这里只会处理前5个请求，后面25个都会抛异常。

而换成我们排队规则后，前面的请求只要是还没超时的它都可以处理，只有到了后面部分请求，超过了5秒钟的等待时长，才会失败

2）Jmeter测试

设置10秒跑完80个请求，这里QPS为8，已经超过了我们设定的5。

如果是之前的快速失败、warmup模式，超出的3个请求应该会直接报错。

但是我们看看队列模式的运行结果，前面的请求有部分是超过阈值的也执行成功了，只有后面的部分超时了的才会请求失败。

2.3.3.小结

流控效果有哪些？

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

2.4.热点参数限流

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

在前面限流案例的配置中，所有资源的QPS都限定为固定的一个值

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

这里对long类型参数限流，每1秒相同参数的QPS不能超过5，有两个例外：

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

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

案例演示

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

•默认的热点参数规则是每1秒请求量不超过2

•给102这个参数设置例外：每1秒请求量不超过4

•给103这个参数设置例外：每1秒请求量不超过10

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

1）标记资源

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

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

重启 order-service 服务，访问/order/102 接口，刷新sentinel控制台，可以看到 hot 了