看到标题中的几个关键字系统自适应限流是不是觉得高大上,这个自适应又是如何实现的呢?
从官方了解到 Sentienl 系统自适应限流是一个全局的概念,对应用入口流量统一进行统一控制,结合应用的机器负载、CPU 使用率,总体平均响应时间、入口 QPS 和并发线程数等几个维度的监控指标从而决定是否调用进行限流操作。为了有一个直观的感受,我们可以从官方的运维平台看看其系统自适应限流的操作界面:
RT、线程数、入口QPS这三个指标是可以通过采集调用信息进行统计计算的,那系统LOAD、CPU使用率是如何获取的呢?大家可以带着这个问题进入本文的学习中来。
在详细分析系统自适应实现原理之前我们先来思考一下 Sentinel 引入该机制的目的。
官方文档针对这个问题有过仔细阐述,我们先来看看官方文档对其阐述。
引入系统自适应限流的主要的目的有如下两个:
目前我们接触的限流的防护思路都是设定一个指标(阔值),例如系统的负载 load 超过某个阔值后就阻止或减少流量的继续进入,当系统负载降低到某一水平后则恢复流量的进入。通常都是被动的,其实际效果取决于阔值设置是否合理,但往往设置合理不是一件容易的事情。
那 Sentinel 提供的系统自适应是可以将设定的规则作为一个保护因子,而允许通过的流量由处理请求的能力来决定,即根据请求的响应时间、当前系统正在处理的请求速率来决定。
那 Sentinel 是如何实现的呢?接下来用源码的手段来揭晓其实现原理。
Sentinel 执行系统限流的核心入口类为 SystemSlot,该类实现简单,如下图所示:
SystemRuleManager#checkSystem从这里可以看出实现的关键在于SystemRuleManager,这里是直接调用 checkSystem 进行是否触发其限流,那我们接下来重点跟踪一下该方法的实现。
系统自适应限流检测具体由 SystemRuleManager 的 checkSystem 方法实现,接下来详细剖析其实现细节。
Step1:验证相关资源,主要包含三层验证:
Step2:从QPS为维度验证是否需要被限流,其实现关键点如下:
Step3:关于线程数、响应时间限流模式与QPS类似,就不再重复介绍。
Step4:如果当前系统的负载超过了设定的阔值的处理逻辑,这里就是自适应的核心所在,并不是超过负载就限流,而是需要根据当前系统的请求处理能力进行综合判断,具体逻辑在 checkBbr 方法中实现。关于如何获得系统负载与 checkBbr 方法稍后会详细介绍。
Step5:如果当前CPU的负载超过了设置的阔值,触发限流,那在JAVA中是如何获取CPU的使用率的呢?稍后详细介绍。
正如上面的第4步骤,根据系统 Load 的会采用 TCP BBR 算法来评估是否限流,具体实现代码如下:
SystemRuleManager#checkSystem 在 Sentinel 中估算系统的容量是以 1s 为度量长度,用该秒内通过的最大 qps 与 最小响应时间的乘积来表示,具体的计算细节:
在 Sentinel 中获取操作系统负载情况的类:SystemStatusListener,每秒采集一次。
SystemStatusListener#run原来可以通过JDK中的 com.sun.management.OperatingSystemMXBean 获取操作系统相关的信息。
温馨提示:上述只对 Linux/Unix 操作系统有效,对 windows 无效。
经过上面的分析,Sentinel 中的系统自适应其实指的是按照应用所在机器的操作系统负载,再结合应用本身的请求处理能力进行的自适应,操作系统的负载情况可以通过 top 命令输出,其示例如下:
尽管 Sentienl 的系统规则配置类型分为 LOAD、CPU、RT、线程数、入口QPS等维度进行限流,但自适应主要是针对 LOAD 这种情况的。 Sentinel 系统级别的限流规则并不是针对某一个资源,而是针对应用所有定义EntryType.IN的资源,在使用时尤其需要注意,特别是如果一个机器上部署了多个应用,可能会造成应用本身负载不高,但所在的机器由于其他应用程序导致资源负载偏高,从而触发限流。