流量控制(flow control),其原理是监控应用流量的 QPS 或并发线程数等指标,当达到指定的阈值时对流量进行控制,以避免被瞬时的流量高峰冲垮,从而保障应用的高可用性。
QPS :每秒查询率(Query Per Second)
-
资源名:一般是我们的请求路径;
-
针对来源:来自于哪个应用,default,代表不区分调用来源;
-
阈值类型:分为QPS或线程数;
-
当 QPS 超过某个阈值的时候,则采取措施进行流量控制。流量控制的效果包括以下几种:直接拒绝、Warm Up、匀速排队
-
并发数控制用于保护业务线程池不被慢调用耗尽。例如,当应用所依赖的下游应用由于某种原因导致服务不稳定、响应延迟增加,对于调用者来说,意味着吞吐量下降和更多的线程数占用,极端情况下甚至导致线程池耗尽。为应对太多线程占用的情况,业内有使用隔离的方案,比如通过不同业务逻辑使用不同线程池来隔离业务自身之间的资源争抢(线程池隔离)。这种隔离方案虽然隔离性比较好,但是代价就是线程数目太多,线程上下文切换的 overhead 比较大,特别是对低延时的调用有比较大的影响。Sentinel 并发控制不负责创建和管理线程池,而是简单统计当前请求上下文的线程数目(正在执行的调用数目),如果超出阈值,新的请求会被立即拒绝,效果类似于信号量隔离。并发数控制通常在调用端进行配置。
-
-
单机阈值:单个节点的QPS或线程数阈值;
-
是否集群:被请求的服务是否集群部署;
1、流控模式
1.1、直接
就是直接对该资源进行控制;
- 当/test接口qps达到阀值2时接口会被限流
1.2、关联
关联某一个资源(/test1),被关联的资源/test1达到阈值2,则限制当前资源/test的访问;
-
如果/test1未设置限流方案则/test1不受影响
-
如果资源/test1未达到阈值2,则/test不受影响
1.3、链路
记录指定链路上的流量;
1.3.1、链路指的是簇点链路中url的上一级资源名如图
- 配置如图
- 如果配置的是连接地址上级路径是不生效的
- 如下图所示配置也是无效的
2、流控效果
2.1、快速失败
达到阀值直接限制;
2.2、Warm Up
即预热/冷启动方式。当系统长期处于低水位的情况下,当流量突然增加时,直接把系统拉升到高水位可能瞬间把系统压垮。通过"冷启动",让通过的流量缓慢增加,在一定时间内逐渐增加到阈值上限,给冷系统一个预热的时间,避免冷系统被压垮。官方说明
-
根据coldFactor(冷却因子默认为3)的值,从阈值/coldFactor,经过预热的时长,才达到设置的QPS阈值,比如设置QPS阈值为100,那么100/3 =33,用33作为最初的阈值,然后在10秒到达100后再开始限流,有一个缓冲效果;
-
冷却因子可以通过配置文件修改 “spring.cloud.sentinel.flow.coldFactor”
-
可以使用JMeter测试下,之后关注实时监控
2.3、排队等待
方式会严格控制请求通过的间隔时间,也即是让请求以均匀的速度通过,对应的是漏桶算法
它的中心思想是,以固定的间隔时间让请求通过。当请求到来的时候,如果当前请求距离上个通过的请求通过的时间间隔不小于预设值,则让当前请求通过;否则,计算当前请求的预期通过时间,如果该请求的预期通过时间小于规则预设的 timeout 时间,则该请求会等待直到预设时间到来通过(排队等待处理);若预期的通过时间超出最大排队时长,则直接拒接这个请求。
-
这种方式适合用于请求以突刺状来到,这个时候我们不希望一下子把所有的请求都通过,这样可能会把系统压垮;同时我们也期待系统以稳定的速度,逐步处理这些请求,以起到“削峰填谷”的效果,而不是拒绝所有请求。
-
注意:匀速排队模式暂时不支持 QPS > 1000 的场景。
-
如图 JMeter调用接口200次 3秒内请求完成
2.4、线上环境模式选择
线上更适合Warm Up(预热)和排队等待模式
-
Warm Up:慢慢达到阈值,有个缓冲区,这个场景主要用于启动需要额外开销的场景,例如建立数据库连接等。
-
排队等待:这种方式适合用于请求以突刺状来到,这个时候我们不希望一下子把所有的请求都通过,这样可能会把系统压垮;同时我们也期待系统以稳定的速度,逐步处理这些请求,以起到“削峰填谷”的效果,而不是拒绝所有请求。
!!!!SpringCloudAlibaba项目集成代码示例!!!