享学课堂特邀作者：老顾
转载请声明出处！
前言
系统在生产环境运行过程中，我们经常需要监控服务器的状态，看服务器CPU、内存、IO等的使用率；主要目的就是保证服务器正常的运行，不能被某些应用搞崩溃了；而且在保证稳定的前提下，保持系统的最大吞吐量。
长期以来，系统自适应保护的思路是根据硬指标，即系统的负载 (load1) 来做系统过载保护。当系统负载高于某个阈值，就禁止或者减少流量的进入；当 load 开始好转，则恢复流量的进入。
系统规则
Sentinel的系统保护规则是从应用级别的入口流量进行控制，从单台机器的总体 Load、RT、入口 QPS 、线程数和CPU使用率五个维度监控应用数据，让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。
系统保护规则是应用整体维度的，而不是资源维度的，并且仅对入口流量生效。入口流量指的是进入应用的流量（EntryType.IN），比如 Web 服务或 Dubbo 服务端接收的请求，都属于
入口流量。
上图中系统规则支持以下的阈值类型：
-
Load（仅对 Linux/Unix-like 机器生效）：当系统 load1 超过阈值，且系统当前的并发线程数超过系统容量时才会触发系统保护。系统容量由系统的 maxQps * minRt 计算得出。设定参考值一般是 CPU cores * 2.5。
-
CPU使用率：当系统 CPU 使用率超过阈值即触发系统保护（取值范围 0.0-1.0）。
-
RT：当单台机器上所有入口流量的平均 RT 达到阈值即触发系统保护，单位是毫秒。
-
线程数：当单台机器上所有入口流量的并发线程数达到阈值即触发系统保护。
-
入口 QPS：当单台机器上所有入口流量的 QPS 达到阈值即触发系统保护。
原理
先用图来说明：
我们把系统处理请求的过程想象为一个水管，到来的请求是往这个水管灌水，当系统处理顺畅的时候，请求不需要排队，直接从水管中穿过，这个请求的RT是最短的；反之，当请求堆积的时候，那么处理请求的时间则会变为：排队时间 + 最短处理时间。
上图中我们可以总结出：
-
如果我们能够保证水管里的水量，能够让水顺畅的流动，则不会增加排队的请求；也就是说，这个时候的系统负载不会进一步恶化。
-
当保持入口的流量是水管出来的流量的最大的值的时候，可以最大利用水管的处理能力。
黑白名单控制
很多时候，我们需要根据调用方来限制资源是否通过，这时候可以使用 Sentinel 的黑白名单控制的功能。黑白名单根据资源的请求来源（origin）限制资源是否通过，若配置白名单则只有请求来源位于白名单内时才可通过；若配置黑名单则请求来源位于黑名单时不通过，其余的请求通过。
调用方信息通过 ContextUtil.enter(resourceName, origin) 方法中的 origin 参数传入。
规则配置
黑白名单规则（AuthorityRule）非常简单，主要有以下配置项：
-
resource：资源名，即限流规则的作用对象
-
limitApp：对应的黑名单/白名单，不同 origin 用 , 分隔，如 appA,appB
-
strategy：限制模式，AUTHORITY_WHITE 为白名单模式，AUTHORITY_BLACK 为黑名单模式，默认为白名单模式
配置起来比较简单，我们看看代码编写是怎么样的
示例
比如我们希望控制对资源 test 的访问设置白名单，只有来源为 appA 和 appB 的请求才可通过，则可以配置如下白名单规则：
总结
今天老顾介绍的两个知识点比较简单，但是也是比较实用的。下面老顾将深入介绍Sentinel；谢谢！！！
对本文内容感兴趣的朋友, 欢迎大家在留言区进行交流讨论!
