这篇文章将为大家详细讲解有关如何进行实战和剖析Sentinel 系统自适应限流，文章内容质量较高，因此小编分享给大家做个参考，希望大家阅读完这篇文章后对相关知识有一定的了解。
从官方了解到 Sentienl 系统自适应限流是一个全局的概念，对应用入口流量统一进行统一控制，结合应用的机器负载、CPU 使用率，总体平均响应时间、入口 QPS 和并发线程数等几个维度的监控指标从而决定是否调用进行限流操作。为了有一个直观的感受，我们可以从官方的运维平台看看其系统自适应限流的操作界面：
在详细分析系统自适应实现原理之前我们先来思考一下 Sentinel 引入该机制的目的。
官方文档针对这个问题有过仔细阐述，我们先来看看官方文档对其阐述。
引入系统自适应限流的主要的目的有如下两个：
保证系统不被拖垮
在系统稳定的前提下保证系统的吞吐量。
目前我们接触的限流的防护思路都是设定一个指标（阔值），例如系统的负载 load 超过某个阔值后就阻止或减少流量的继续进入，当系统负载降低到某一水平后则恢复流量的进入。通常都是被动的，其实际效果取决于阔值设置是否合理，但往往设置合理不是一件容易的事情。
那 Sentinel 提供的系统自适应是可以将设定的规则作为一个保护因子，而允许通过的流量由处理请求的能力来决定，即根据请求的响应时间、当前系统正在处理的请求速率来决定。
那 Sentinel 是如何实现的呢？接下来用源码的手段来揭晓其实现原理。
Sentinel 执行系统限流的核心入口类为 SystemSlot，该类实现简单，如下图所示：
系统自适应限流检测具体由 SystemRuleManager 的 checkSystem 方法实现，接下来详细剖析其实现细节。
如果资源名称为空，则直接跳过，这个是容错机制。
如果系统自适应开关为打开，直接放行，该开关初始化时为 false，在加载到一条系统自适应配置规则时该状态会设置为 true，具体在 loadSystemConf 中。
如果资源的类型不是入口流量(EntryType.IN),则直接放行。
Step2：从QPS为维度验证是否需要被限流，其实现关键点如下：
当前的qps，如果 ENTRY_NODE 为空则返回0，否则返回该统计节点的成功 qps，那 ENTRY_NODE 统计节点是“何许人也”，原来是 Sentinel 特定定义了一个资源，其名称为total_inbound_traffic，用来采集所有入口调用的信息，当资源进入类型为 ENTRY_TYPE_IN 时，会自动采集信息，其具体统计信息在 StatisticSlot 的 entry 方法中被调用，其截图如下：
如果当前调用的 QPS 大于设定的QPS，即触发限流，那这个 qps 又是在什么时候被设置的呢？也是在加载系统限流规则时被设置，如果一个应用同一个限流点（LOAD、QPS)设置了多条规则，最小值生效。
Step3：关于线程数、响应时间限流模式与QPS类似，就不再重复介绍。
Step4：如果当前系统的负载超过了设定的阔值的处理逻辑，这里就是自适应的核心所在，并不是超过负载就限流，而是需要根据当前系统的请求处理能力进行综合判断，具体逻辑在 checkBbr 方法中实现。关于如何获得系统负载与 checkBbr 方法稍后会详细介绍。
Step5：如果当前CPU的负载超过了设置的阔值，触发限流，那在JAVA中是如何获取CPU的使用率的呢？稍后详细介绍。
正如上面的第4步骤，根据系统 Load 的会采用 TCP BBR 算法来评估是否限流，具体实现代码如下：
maxSuccessQps 的计算取当前采样窗口的最大值乘以1s内滑动窗口的个数，这里其实并不是十分准确。
minRt 最小响应时间取自当前采样窗口中的最小响应时间。
故得出了上述计算公式，除以1000是因为 minRt 的时间单位是毫秒，统一为秒。从这里可以看出根据系统负载做限流，最终的判断依据是线程数量。
在 Sentinel 中获取操作系统负载情况的类：SystemStatusListener，每秒采集一次。
温馨提示：上述只对 Linux/Unix 操作系统有效，对 windows 无效。
经过上面的分析，Sentinel 中的系统自适应其实指的是按照应用所在机器的操作系统负载，再结合应用本身的请求处理能力进行的自适应，操作系统的负载情况可以通过 top 命令输出，其示例如下：
关于如何进行实战和剖析Sentinel 系统自适应限流就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
