Sentinel 系统自适应限流原理剖析与实战指导

看到标题中的几个关键字系统自适应限流是不是觉得高大上,这个自适应又是如何实现的呢?

1、Sentinel 系统自适应概述

从官方了解到 Sentienl 系统自适应限流是一个全局的概念,对应用入口流量统一进行统一控制,结合应用的机器负载、CPU 使用率,总体平均响应时间、入口 QPS 和并发线程数等几个维度的监控指标从而决定是否调用进行限流操作。为了有一个直观的感受,我们可以从官方的运维平台看看其系统自适应限流的操作界面:
Sentinel 系统自适应限流原理剖析与实战指导_第1张图片
RT、线程数、入口QPS这三个指标是可以通过采集调用信息进行统计计算的,那系统LOAD、CPU使用率是如何获取的呢?大家可以带着这个问题进入本文的学习中来。

在详细分析系统自适应实现原理之前我们先来思考一下 Sentinel 引入该机制的目的。

官方文档针对这个问题有过仔细阐述,我们先来看看官方文档对其阐述。

引入系统自适应限流的主要的目的有如下两个:

  • 保证系统不被拖垮
  • 在系统稳定的前提下保证系统的吞吐量。

目前我们接触的限流的防护思路都是设定一个指标(阔值),例如系统的负载 load 超过某个阔值后就阻止或减少流量的继续进入,当系统负载降低到某一水平后则恢复流量的进入。通常都是被动的,其实际效果取决与阔值设置是否合理,但往往设置合理不是一件容易的事情。

那 Sentinel 提供的系统自适应是可以将设定的规则作为一个保护因子,而允许通过的流量由处理请求的能力来决定,即根据请求的响应时间、当前系统正在处理的请求速率来决定。

那 Sentinel 是如何实现的呢?接下来用源码的手段来揭晓其实现原理。

2、系统自适应限流原理

Sentinel 执行系统限流的核心入口类为 SystemSlot,该类实现简单,如下图所示:
Sentinel 系统自适应限流原理剖析与实战指导_第2张图片
从这里可以看出实现的关键在于SystemRuleManager,这里是直接调用 checkSystem 进行是否触发其限流,那我们接下来重点跟踪一下该方法的实现。

2.1 自适应限流检测流程

系统自适应限流检测具体由 SystemRuleManager 的 checkSystem 方法实现,接下来详细剖析其实现细节。
Sentinel 系统自适应限流原理剖析与实战指导_第3张图片
Step1:验证相关资源,主要包含三层验证:

  • 如果资源名称为空,则直接跳过,这个是容错机制。
  • 如果系统自适应开关为打开,直接放行,该开关初始化时为 false,在加载到一条系统自适应配置规则时该状态会设置为 true,具体在 loadSystemConf 中。
  • 如果资源的类型不是入口流量(EntryType.IN),则直接放行。
    Sentinel 系统自适应限流原理剖析与实战指导_第4张图片
    Step2:从QPS为维度验证是否需要被限流,其实现关键点如下:
  • 当前的qps,如果 ENTRY_NODE 为空则返回0,否则返回该统计节点的成功 qps,那 ENTRY_NODE 统计节点是“何许人也”,原来是 Sentinel 特定定义了一个资源,其名称为__total_inbound_traffic__,用来采集所有入口调用的信息,当资源进入类型为 ENTRY_TYPE_IN 时,会自动采集信息,其具体统计信息在 StatisticSlot 的 entry 方法中被调用,其截图如下:
    Sentinel 系统自适应限流原理剖析与实战指导_第5张图片
  • 如果当前调用的 QPS 大于设定的QPS,即触发限流,那这个 qps 又是在什么时候被设置的呢?也是在加载系统限流规则时被设置,如果一个应用同一个限流点(LOAD、QPS)设置了多条规则,最小值生效。
    Sentinel 系统自适应限流原理剖析与实战指导_第6张图片
    Step3:关于线程数、响应时间限流模式与QPS类似,就不再重复介绍。
    Sentinel 系统自适应限流原理剖析与实战指导_第7张图片
    Step4:如果当前系统的负载超过了设定的阔值的处理逻辑,这里就是自适应的核心所在,并不是超过负载就限流,而是需要根据当前系统的请求处理能力进行综合判断,具体逻辑在 checkBbr 方法中实现。关于如何获得系统负载与 checkBbr 方法稍后会详细介绍。
    Sentinel 系统自适应限流原理剖析与实战指导_第8张图片
    Step5:如果当前CPU的负载超过了设置的阔值,触发限流,那在JAVA中是如何获取CPU的使用率的呢?稍后详细介绍。

2.2 根据系统负载自适应算法详解

正如上面的第4步骤,根据系统 Load 的会采用 TCP BBR 算法来评估是否限流,具体实现代码如下:
SystemRuleManager#checkSystem
Sentinel 系统自适应限流原理剖析与实战指导_第9张图片
在 Sentinel 中估算系统的容量是以 1s 为度量长度,用该秒内通过的最大 qps 与 最小响应时间的乘积来表示,具体的计算细节:

  • maxSuccessQps 的计算取当前采样窗口的最大值乘以1s内滑动窗口的个数,这里其实并不是十分准确。
  • minRt 最小响应时间取自当前采样窗口中的最小响应时间。
    故得出了上述计算公式,除以1000是因为 minRt 的时间单位是毫秒,统一为秒。从这里可以看出根据系统负载做限流,最终的判断依据是线程数量。

2.3 JAVA如何获得操作系统负载情况

在 Sentinel 中获取操作系统负载情况的类是:SystemStatusListener,每秒采集一次。
SystemStatusListener#run
Sentinel 系统自适应限流原理剖析与实战指导_第10张图片
原来可以通过JDK中的 com.sun.management.OperatingSystemMXBean 获取操作系统相关的信息。
温馨提示:上述只对 Linux/Unix 操作系统有效,对 windows 无效。

3、实践思考

经过上面的分析,Sentinel 中的系统自适应其实指的是按照应用所在机器的操作系统负载,再结合应用本身的请求处理能力进行的自适应,操作系统的负载情况可以通过 top 命令输出,其示例如下:
在这里插入图片描述
尽管 Sentienl 的系统规则配置类型分为 LOAD、CPU、RT、线程数、入口QPS等维度进行限流,但自适应主要是针对 LOAD 这种情况的。
Sentinel 系统级别的限流规则并不是针对某一个资源,而是针对应用所有定义EntryType.IN的资源,在使用时尤其需要注意,特别是如果一个机器上部署了多个应用,可能会造成应用本身负载不高,但所在的机器由于其他应用程序导致资源负载偏高,从而触发限流。


好了,本文就介绍到这里了,您的点赞是对我持续输出高质量文章最大的鼓励。

欢迎加笔者微信号(dingwpmz),加群探讨,笔者优质专栏目录:
1、源码分析RocketMQ专栏(40篇+)
2、源码分析Sentinel专栏(12篇+)
3、源码分析Dubbo专栏(28篇+)
4、源码分析Mybatis专栏
5、源码分析Netty专栏(18篇+)
6、源码分析JUC专栏
7、源码分析Elasticjob专栏
8、Elasticsearch专栏(20篇+)
9、源码分析MyCat专栏

你可能感兴趣的:(sentinel,sentinel,自适应,实践)