SpringCloud学习笔记 - 流控规则 - Sentinel

1. Sentinel流控规则简介

这里的流控指的是“流量控制”进一步解释说明

• 资源名唯一名称默认请求路径。

• 针对来源Sentinel可以针对调用者进行限流填写微服务名默认default不区分来源。

• 阈值类型/单机阈值

  • QPS(每秒钟的请求数量)︰当调用该API的QPS达到阈值的时候进行限流。
  • 线程数当调用该API的线程数达到阈值的时候进行限流。

• 是否集群不需要集群

• 流控模式

  • 直接API达到限流条件时直接限流
  • 关联当关联的资源达到阈值时就限流当前资源
  • 链路只记录指定链路上的流量指定资源从入口资源进来的流量如果达到阈值就进行限流【API级别的针对来源】。

• 流控效果

  • 快速失败直接失败抛出异常
  • Warm up根据Code Factor的值冷加载因子默认3从阈值/code Factor经过预热时长才达到设置的QPS阈值。
  • 排队等待匀速排队让请求以匀速通过阈值类型必须设置为QPS否则无效。

2. Sentinel流控规则介绍

2.1. 模式一QPS直接快速失败

规则设置 QPS -> 直接 -> 快速失败 sentinel的默认设置

配置说明 以上设置表示是对/testA进行访问流量监控1秒钟内允许最多查询1次若超过次数1则直接->快速失败抛出默认错误。

测试流控效果 可以在浏览器快速多次访问请求地址http://localhost:8401/testA返回页面 Blocked by Sentinel (flow limiting)访问量下降后自动恢复访问。

2.2. 模式二并发线程数直接失败

线程数当调用该API的线程数达到阈值的时候进行限流。可以用JMeter进行并发线程测试

2.3. 模式三QPS关联快速失败

流控模式-关联当前资源可以将一个服务访问接口作为关联资源当被关联的资源达到预定的阈值时对自身进行限流。这样设计的目的是为了在testA/B在争抢资源时保证B可以正常运行。

1. 设置testA的流控规则将testB设置为testA的关联资源。
以下设置表示testB为testA的关联资源当关联资源testB的QPS每秒的访问量大于1时testA就会进行流控效果为快速失败。

2. 使用Postman进行并发测试密集访问testB

2.1. 新建一个多线程集合并添加testB请求。

2.2. 请求添加完成后为请求集合添加一个访问迭代器循环调用testB请求。

3. 启动postman循环调用此时再访问/testA发现服务中断了。

3. Sentinel流控-链路

NodeSelectorSlot 中记录了资源之间的调用链路这些资源通过调用关系相互之间构成一棵调用树。这棵树的根节点是一个名字为 machine-root 的虚拟节点调用链的入口都是这个虚节点的子节点。
一棵典型的调用树如下图所示

上图中来自入口 Entrance1 和 Entrance2 的请求都调用到了资源 NodeASentinel 允许只根据某个入口的统计信息对资源限流。比如我们可以设置 FlowRule.strategy 为 RuleConstant.CHAIN同时设置 FlowRule.ref_identity 为 Entrance1 来表示只有从入口 Entrance1 的调用才会记录到 NodeA 的限流统计当中而对来自 Entrance2 的调用漠不关心。调用链的入口是通过 API 方法 ContextUtil.enter(name) 定义的。

4. Sentinel流控-预热

Warm UpRuleConstant.CONTROL_BEHAVIOR_WARM_UP方式即预热/冷启动方式。当系统长期处于低水位的情况下当流量突然增加时直接把系统拉升到高水位可能瞬间把系统压垮。通过"冷启动"让通过的流量缓慢增加在一定时间内逐渐增加到阈值上限给冷系统一个预热的时间避免冷系统被压垮。详细文档可以参考 流量控制 - Warm Up 文档具体的例子可以参见 WarmUpFlowDemo。

通常冷启动的过程系统允许通过的 QPS 曲线如下图所示

默认coldFactor为3即请求QPS 从 threshold / 3开始经预热时长逐渐升至设定的QPS阈值。
源码可以查看 com.alibaba.csp.sentinel.slots.block.flow.controller.WarmUpController

流控规则测试QPS-直接-WarmUp

以上配置表示
系统在开始的时候会将单机阈值控制在310 设置的单机阈值/3 默认的冷却因子等经过预热时长5秒后再将单机阈值提高到10。当前5秒每秒的请求大于3时系统会直接抛出异常后5秒则变为10.

5. Sentinel流控-排队等待

匀速排队RuleConstant.CONTROL_BEHAVIOR_RATE_LIMITER方式会严格控制请求通过的间隔时间也即是让请求以均匀的速度通过对应的是漏桶算法。详细文档可以参考 流量控制 - 匀速器模式具体的例子可以参见 PaceFlowDemo。

这种方式主要用于处理间隔性突发的流量例如消息队列。想象一下这样的场景在某一秒有大量的请求到来而接下来的几秒则处于空闲状态我们希望系统能够在接下来的空闲期间逐渐处理这些请求而不是在第一秒直接拒绝多余的请求。

5.1. 模式一QPS直接排队等待

匀速排队让请求以均匀的速度通过阀值类型必须设成QPS否则无效。

以上设置表示/testB每秒允许1次请求超过的话就排队等待等待的超时时间为20000毫秒。

5.2. 使用postman进行测试

postman压测设置
因为portman不能进行并发测试我们这里只测试下排队等待的匀速通过情况。超时请求失败可以使用jmeter进行并发请求测试。
设置请求集合的迭代请求为20次每100毫秒请求一次。也就是说20次请求会在2秒内执行完成。

5.3. 启动迭代请求观察后台打印

我们可以看到本应失败的请求在排队等待策略下全部已1秒一次的匀速方式成功访问。

注意匀速排队模式暂时不支持 QPS > 1000 的场景。