Dubbo生态之深度分析sentinel的流量控制

1. 深度了解sentinel限流规则参数的含义

博客Dubbo生态之sentinel限流-CSDN博客中有dubbo集成sentinel的demo演示

在sentinel中，限流的直接表现形式就是，在执行Entry nodeA = SphU.entry(resourceName)的时候抛出FlowException异常，FlowException是BlockException的子类，可以捕捉BlockException来自定义被限流之后的逻辑。

并且，对于同一个资源或者不同资源可以分别创建多条限流规则，FlowSlot会对该资源的所有限流规则依次遍历，直到有规则触发限流或者所有规则遍历完毕。

从上篇博客的demo中我们也可以看到了一些限流规则参数的设置，下面来详细说明以下限流规则中的主要参数。

resource: 资源名，即限流规则的作用对象
count: 限流阈值
grade: 限流阈值类型(QPS或并发线程数)
limitApp: 流控针对的调用来源，若为default则不区分调用来源
strategy: 限流策略
controllerBehavior：流量控制效果(直接拒绝、Warm Up、匀速排队)

1.1 限流阈值类型grade(限流纬度)

Sentinel提供了两个纬度 : 并发线程数、QPS

也就是说，我们可以选择根据不同的维度，根据这些纬度的指标去匹配限流规则，一旦达到阈值，则直接触发流量控制。

默认情况下是根据QPS来限流的，这个属性是通过grade进行设置

1.1.1 并发线程数控制

并发数的控制是用于保护业务线程池不被调用耗尽

例如，当应用所依赖的下游应用由于某种原因导致服务不稳定、响应延迟增加，对于调用者来说，意味着吞吐量下降和更多的线程数占用，极端情况下甚至导致线程池耗尽。

为了应对太多线程占用的情况，业内有使用隔离的方案，比如通过不同业务逻辑使用不同线程池来隔离业务自身之间的资源争抢（线程池隔离）。

这种隔离方案虽然隔离性比较好，但是代价就是线程数目太多，线程上下文切换的 overhead(开销) 比较大，特别是对低延时的调用有比较大的影响。

Sentinel并发控制不负责创建和管理线程池，而是简单的统计当前请求上下文的线程数目(正在执行的调用数目),如果超出阈值，新的请求会被立即拒绝，效果类似于信号量隔离，原理如下图所示。

并发线程数的控制参数配置:

grade: RuleConstant.FLOW_GRADE_THREAD

count: 此时它的含义是并发线程数量

1.1.2 QPS流量控制

QPS，表示每秒的查询效率，和时间没有关系，内部使用了滑动窗口算法，原理如下图所示。

当QPS超过某个阈值的时候，则采取流量控制行为,Sentinel提供了四种流量控制行为。

直接拒绝(CONTROL_BEHAVIOR_DEFAULT)
Warm Up(CONTROL_BEHAVIOR_WARM_UP)
匀速排队(CONTROL_BEHAVIOR_RATE_LIMITER, 漏桶算法)
冷启动+匀速器(CONTROL_BEHAVIOR_WARM_UP_RATE_LIMITER)

1.2 流量控制行为controlBehavior

1.2.1 直接拒绝行为

直接拒绝(RuleConstant.CONTROL_BEHAVIOR_DEFAULT)方式是默认的流量控制方式，当QPS超过任意规则的阈值后，新的请求就会被立即拒绝，拒绝方式为抛出FlowException

这种方式适用于对系统能力确切一致的情况下，比如通过压测确定了系统的准确水位时。

1.2.2 Warm Up

Warm Up(RuleConstant.CONTROL_BEHAVIOR_WARM_UP)方式，即预热/冷启动方式。当系统长期处于低水位的情况下，当流量突然增加时，直接把系统拉升到高水位可能瞬间把系统压垮。

通过‘冷启动’，让通过的流量缓慢增加，在一定时间内逐渐增加到阈值上限，给冷系统一个预热的时间，避免冷系统被压垮。

以下都会随着系统访问量增加逐步预热来提升性能

缓存预热
数据库连接池初始化

如下图所示，当前系统所能够处理的最大并发数是480，首先在最下面的标记位置，系统一直处于空闲状态，接着请求量突然直线升高，这个时候系统并不是直接将QPS拉到最大值，而是在一定的时间内逐步增加阈值，而中间这段时间就是一个系统逐步预热的过程

属性设置:

controlBehavior: RuleConstant.CONTROL_BEHAVIOR_WARM_UP

warmUpPeriodSec：预热时间，默认60s

1.2.3 匀速排队

匀速排队方式(RuleConstant.CONTROL_BEHAVIOR_RATE_LIMITER)方式会严格控制请求通过的间隔时间，也即是让请求以均匀的速度通过，其实对应的就是漏桶算法

当请求数量远远大于阈值时，这些请求就会排队等待，这个等待时间可以设置，如果超过等待时间，那这个请求就会被拒绝。

如下图所示，假设QPS=5，表示请求每200ms才能通过1个，多出的请求排队等待，超过最大排队时间则直接拒绝。

属性设置:

controlBehavior: RuleConstant.CONTROL_BEHAVIOR_RATE_LIMITER

maxQueueingTimeMs：排队等待时间，表示每一次请求最长等待时间，默认是500ms

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

所以，这里等待时间大一点, 可以保证让所有请求都能正常通过; 假设这里设置的排队等待时间过小的话, 导致排队等待的请求超时而抛出异常 BlockException, 最终结果可能是这100个并发请求中只有一个请求或几个才能正常通过, 所以使用这种模式得根据访问资源的耗时时间决定排队等待时间。

1.3 基于调用关系的流量控制strategy

在分布式架构中，一个请求会包含调用方和被调用方，Sentinel还提供了服务调用关系的流量控制策略，所谓的调用关系，就是根据不同的调用纬度来触发流量控制。

根据调用方限流(STRATEGY_DIRECT)
根据调用链路入口限流(STRATEGY_CHAIN)
具有关系的资源流量控制(STRATEGY_RELATE)

1.3.1 根据调用方限流

顾名思义，假设有两个服务分别是A和B，都想某一个服务C发起请求调用，这个时候我们希望对来自服务B的请求进行限流，那就可以采用调用方限流策略，具体配置如下:

设置FlowRule的strategy为STRATEGY_DIRECT

设置FlowRule的LimitApp，表示指定调用方，这个字段有三种选项：

default ，表示不区分调用者，任何调用者的请求都会进行流量统计。

${some_origin_name} ，针对某个特定的调用者，只有这个调用者的请求才会进行流量控制

other ，表示针对除了 ${some_origin_name} 以外的其他调用方的流量进行流量控制。假设资源 NodeA 配置了一条针对调用者 caller1 的限流规则，接着又配置了一条调用者为 other 的规则，那么任意来自非 caller1 的。对NodeA的调用，请求并发数都不能超过 other 这条规则定义的阈值。

1.3.2 根据调用链路入口限流

一个被限流的保护方法，可能来自于不同的调用链路，比如针对资源NodeA,入口Entrance1和Entrance2的请求都调用到了资源NodeA,Sentinel允许只根据某个入口的统计信息对资源限流。

设置方式:

设置FlowRule中的strategy=STRATEGY_CHAIN

设置FlowRule中的refResource为 Entrance1 来表示只有从入口 Entrance1 的调用才会进行流量控制

1.3.3 具有关系的资源流量控制

当两个资源之间具有资源争抢或者依赖关系的时候，这两个资源便具有了关联。

比如对数据库同一个字段的读操作和写操作存在争抢，读的速度过高会影响写的速度，写的速度过高会影响读的速度。

如果放任读写操作争抢资源，则争抢本身带来的开销会降低整体的吞吐量。

可使用关联限流来避免具有关联关系的资源之间过度的争抢，举例来说，read_db和write_db这两个资源分别代表数据库读写，我们可以给read_db设置限流规则来达到写优先的目的。

设置方式

设置FlowRule中的strategy=STRATEGY_RELATE

设置FlowRule中的refResource为 write_db 表示设置关联资源

通过这样的设置后，如果write_db资源超过阈值时，就会对read_db资源进行限流

2.Sentinel中的熔断机制的应用

熔断是对系统服务器的一种保护机制，如下图所示

分析:APP容器依赖于下面的几个服务，当访问量比较高的情况下并且此时有一个服务异常或者调用时间特别慢的情况下，那么一个后端依赖节点的延迟响应就可能导致所有服务器上的所有资源在数秒内直接饱和。一旦出现这个问题，就会导致系统资源被快速消耗，从而导致服务宕机等问题。

那么熔断是如何解决这个问题呢?

Sentinel 熔断降级会在调用链路中某个资源出现不稳定状态时（例如调用超时或异常比例升高），对这个资源的调用进行限制，让请求快速失败，避免影响到其它的资源而导致级联错误。当资源被降级后，在接下来的降级时间窗口之内，对该资源的调用都自动熔断

思考: 熔断是根据什么规则来判定资源是否稳定的呢？

慢调用比例(SLOW_REQUEST_RATIO)
异常比例(ERROR_RATIO)
异常数(ERROR_COUNT)

这些纬度，在sentinel中提供了DegradeRule对象来实现规则设置，核心属性如下:

resource 资源名称
count 阈值，[异常比例/异常模式下的对应阈值，慢调用比例模式下慢调用临界RT]
grade,熔断模式，根据RT降级，根据异常比例、根据异常数量
timeWindow，熔断时间，单位为秒

2.1 慢调用比例(SLOW_REQUEST_RATIO)

在一定请求次数中，一段时间内，如果有一定比例的请求响应时间大于某一个阈值，则认为目标服务异常，则在接下来的指定时间内，请求都会被自动熔断。当经过熔断时长后，熔断器会进入到探测恢复状态，若接下来的一个请求响应时间小于设置的慢调用 RT 则结束熔断，若大于设置的慢调用 RT 则会再次被熔断。

假设有一个场景，如果1s内连续发送10个请求，在1分钟以内，其中20%的请求平均响应时间都超过3s，则触发熔断，熔断时间为5s，针对这种情况的设置如下:

1. grade=CircuitBreakerStrategy.SLOW_REQUEST_RATIO，（熔断模式）

2. count=3000，最大的响应时间，单位为(毫秒)

3. TimeWindow=5 （单位为s）

4. minRequestAmount=5，最小请求数量，请求数量小于这个值，即时异常比例超出阈值也不会熔断，默认是5次。

5. slowRatioThreshold=0.2，慢调用比例阈值，仅仅在慢调用比例模式下有效。

6. statIntervalMs=1000*60，统计时长为60秒，默认为1秒

DegradeRule rule = new DegradeRule(RESOURCE_KEY)
rule.setGrade(CircuitBreakerStrategy.SLOW_REQUEST_RATIO.getType())
// Max allowed response time
rule.setCount(3000)
// Retry timeout (in second)
rule.setTimeWindow(5)
// Circuit breaker opens when slow request ratio > 20%
rule.setSlowRatioThreshold(0.2)
rule.setMinRequestAmount(10)
rule.setStatIntervalMs(60000);

2.2 异常比例(ERROR_RATIO)

当资源的每秒请求量 >= 5, 并且每秒异常总数占通过量的比值超过阈值时，则触发熔断，配置方式如下:

1. grade=CircuitBreakerStrategy.ERROR_RATIO

2. count（异常比例），范围[0.0 , 1.0],代表0%~100%

3. TimeWindow=5 （单位为s）

4. minRequestAmount，最小请求数量，请求数量小于这个值，即时异常比例超出阈值也不会熔断，默认是5次。