SpringCloud Alibaba Sentinel 流量控制规则介绍与配置

概述：流量控制（flow control）,其原理是sentinel断路器通过监控应用服务调用的QPS或调用并发线程数来实现调用控制。当QPS或线程数达到配置的阈值时，进行响应的服务降级功能，从而到达在高并发下的系统保护作用。流量控制是在高并发场景下的一种系统自我保护机制。（需要清楚的是：此处流量控制是在超出配置的阈值之后会走默认的处理方式。如果没有超出阈值，接口出现的报错之类是不会处理的）

流量控制分为 基于QPS(每秒请求数)以及基于并发线程数的方式控制。

测试环境准备：

参考：SpringCloud Alibaba Sentinel 项目基础环境搭建

一、基于并发数的流量控制介绍

并发数控制用于保护业务线程池不被慢调用耗尽。例如，当应用所依赖的下游应用由于某种原因导致服务不稳定、响应延迟增加，对于调用者来说，意味着吞吐量下降和更多的线程数占用，极端情况下甚至导致线程池耗尽。为应对太多线程占用的情况，业内有使用隔离的方案，比如通过不同业务逻辑使用不同线程池来隔离业务自身之间的资源争抢（线程池隔离）。这种隔离方案虽然隔离性比较好，但是代价就是线程数目太多，线程上下文切换的 overhead 比较大，特别是对低延时的调用有比较大的影响。Sentinel 并发控制不负责创建和管理线程池，而是简单统计当前请求上下文的线程数目（正在执行的调用数目），如果超出阈值，新的请求会被立即拒绝，效果类似于信号量隔离。并发数控制通常在调用端进行配置。

当设置的并发数线程中有执行完的线程时，则会继续处理新的请求。无持续的熔断时间间隔。

测试：在基础项目环境中我们get2 接口方法内有2秒钟的睡眠延迟，当第一个线程未处理完成时（即2秒内），其他新开启请求的线程都将被限流，只有第一个未限流的线程会成功处理，其他的都将调用失败。上图中空流模式为直接失败处理。

保持在当前线程处理完成时在进行新的请求。即间隔至少2秒再发起新的请求。

2秒内刷新多次，后面新开启的线程都会被拦截。

二、基于QPS的流量控制配置

1，直接拒绝（直接->快速失败）

直接拒绝 方式是默认的流量控制方式，当QPS超过任意规则的阈值后，新的请求就会被立即拒绝，拒绝方式为抛出FlowException。这种方式适用于对系统处理能力确切已知的情况下，比如通过压测确定了系统的准确水位时。

如上 设置单机阈值为1，即 每秒钟最多有一次请求，测试方式：

场景1：每秒钟最多只发起一次请求。均正常返回。

场景2：每秒钟发起多次请求。除第一次其他的都拦截失败。（Blocked by Sentinel (flow limiting)）

2，Warm Up（直接->预热）

即预热/冷启动方式。当系统长期处于低水位的情况下，当流量突然增加时，直接把系统拉升到高水位可能瞬间把系统压垮。通过"冷启动"，让通过的流量缓慢增加，在一定时间内逐渐增加到阈值上限，给冷系统一个预热的时间，避免冷系统被压垮。

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

配置界面：

当配置的阈值为120，预热时长为10秒时。在系统当前处于闲置状态时，突然有大量该请求访问过来时，系统初始每秒只处理 阈值的三分之一的请求，即 120/3=40的请求。然后在后面的10秒内逐渐将QPS提升至单机阈值的全量120。在第一次访问来的请求超出QPS三分之一的请求将被限流。

3，匀速排队(直接->排队等待)

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

该方式的作用如下图所示：

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

配置界面：