第二节: 流量控制简介及案例演示

大家好，欢迎来到IT知识分享网。

流量控制

在学习流量控制之前，我们先了解一下什么是簇点链路，和一些专业术语。

QPS

每秒查询率（QPS，Queries-per-second）是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准.

PV

​ 页面浏览量，通常是衡量一个网络新闻频道或网站甚至一条网络新闻的主要指标。网页浏览数是评价网站流量最常用的指标之一，简称为PV。监测网站PV的变化趋势和分析其变化原因是很多站长定期要做的工作。

​ Page Views中的Page一般是指普通的html网页，也包含php、jsp等动态产生的html内容。来自浏览器的一次html内容请求会被看作一个PV，逐渐累计成为PV总数。

下来我们课外补充点知识：

根据QPS推算PV

根据QPS,PV推算服务器数量

峰值机器数量

峰值时间QPS / 单台机器的QPS

簇点链路

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

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

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

这里我们学习流控模式，以后我们将一一介绍各个模式。

1. 流量控制简介

​ 流量控制在网络传输中是一个常用的概念，它用于调整网络包的发送数据。在网络传输时，任意时间到来的请求往往是随机不可控的，而系统的处理能力是有限的。我们需要根据系统的处理能力对流量进行控制。

​ 举个生活中最容易理解的例子：上下班高峰期时会有大量的汽车行驶。假设没有交管部门，A路段上只能流畅的行驶500辆汽车，我们暂定为最大容纳量。一旦超过这个值，A道路必定发生堵塞，甚至车祸。为了解决这个问题，我们需要对A路段进行疏导，如：委派交警，分流等，这些都是限流的手段。

2. 流控模式

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

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

2.1 关联模式

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

配置规则：

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

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

需求说明：

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

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

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

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

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

4）在Jmeter测试

但限流的目标是/order/query，我们在浏览器访问，可以发现：

确实被限流了。

2.2 链路模式

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

配置示例：

例如有两条请求链路：

• /test1 –> /common
• /test2 –> /common

实战案例

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

步骤：

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

实现：

1）添加查询商品方法

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

public void queryGoods(){ 
    System.err.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.err.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的资源，QPS阈值为2，超出则被限流。

6）Jmeter测试

可以看到这里200个用户，50秒内发完，QPS为4，超过了我们设定的阈值2

运行的结果：

完全不受影响。

每次只有2个通过。

2.3. 流控效果

在流控的高级选项中，存在流控效果选项：

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

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

2.3.1. warm up

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

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

案例

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

1）配置流控规则：

2）Jmeter测试

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

案例

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

1）添加流控规则

2）Jmeter测试

QPS为15，已经超过了我们设定的10。

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

QPS非常平滑，一致保持在10，但是超出的请求没有被拒绝，而是放入队列。因此响应时间（等待时间）会越来越长。

2.3.3. 总结

流控效果有哪些？

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

2.4. 热点参数限流

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

2.4.1. 全局参数限流

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

2.4.2. 热点参数限流

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

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

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

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

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

2.4.4. 案例

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

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

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

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

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

1）标记资源

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

2）热点参数限流规则

这里不要点击hot后面的按钮，页面有BUG

点击左侧菜单中热点规则菜单：

点击新增，填写表单：

3）Jmeter测试

选择《热点参数限流 QPS1》：

这里发起请求的QPS为5.

包含3个http请求：

普通参数，QPS阈值为2

运行结果：

运行结果：