Sentinel系统保护规则深度解析

以下内容为 Sentinel 的系统保护规则（SystemRule） 实现，它用于从全局系统维度对服务进行自我保护，防止因突发流量或资源耗尽导致系统雪崩。

下面我将结构化、深入浅出地解释其设计思想、核心机制和使用方式。

---

🧠 一、SystemRule 是什么？

SystemRule（系统规则） 不针对某个具体接口，而是监控整个应用的全局状态，当系统整体负载过高时，自动拒绝部分请求，保护系统不崩溃。

✅ 它监控 5 个关键指标：

指标	含义	单位	默认值（-1 表示关闭）
highestSystemLoad	系统平均负载（Linux load average）	double	-1（关闭）
highestCpuUsage	CPU 使用率	[0, 1]	-1（关闭）
qps	全局总 QPS（所有入口流量之和）	double	-1（关闭）
avgRt	全局平均响应时间	毫秒	-1（关闭）
maxThread	全局最大并发线程数	long	-1（关闭）

⚠️ 注意：只对 EntryType.IN（入口流量）生效，出口调用（如 Feign、Dubbo 调用下游）不受限。

---

🔍 二、核心类解析

1. SystemRule：规则定义类

• 继承 AbstractRule
• 包含上述 5 个阈值字段
• setter 方法中，≤ 0 的值表示"清除该阈值"
• 支持动态更新（通过 SentinelProperty）

2. SystemRuleManager：规则管理器 + 执行引擎

• 静态单例，全局唯一
• 提供 loadRules() 加载规则
• 提供 checkSystem() 方法，在每次请求进入时被调用（由 Sentinel Slot Chain 触发）
• 内部维护 5 个 volatile 阈值变量，支持多线程安全读取
• 启动一个 每秒执行一次的定时任务 （SystemStatusListener），采集系统指标

3. SystemStatusListener：系统指标采集器

• 实现 Runnable，由 ScheduledExecutorService 每秒调度
• 通过 JMX（Java Management Extensions） 获取：
  • OperatingSystemMXBean.getSystemLoadAverage() → 系统负载
  • OperatingSystemMXBean.getSystemCpuLoad() → 系统 CPU 使用率
  • getProcessCpuTime() + uptime → 进程 CPU 使用率（更适用于容器环境）
• 将最新指标存入 volatile 字段，供 checkSystem() 读取

---

⚙️ 三、checkSystem()：核心拦截逻辑

public static void checkSystem(ResourceWrapper resource, int count) throws BlockException {
    // 1. 只检查入口流量
    if (resource.getEntryType() != EntryType.IN) return;

    // 2. 检查 QPS
    if (Constants.ENTRY_NODE.passQps() + count > qps) 
        throw new SystemBlockException("qps");

    // 3. 检查线程数
    if (Constants.ENTRY_NODE.curThreadNum() > maxThread)
        throw new SystemBlockException("thread");

    // 4. 检查平均 RT
    if (Constants.ENTRY_NODE.avgRt() > maxRt)
        throw new SystemBlockException("rt");

    // 5. 检查系统负载（带 BBR 优化）
    if (load > threshold && !checkBbr(currentThread))
        throw new SystemBlockException("load");

    // 6. 检查 CPU 使用率
    if (cpuUsage > threshold)
        throw new SystemBlockException("cpu");
}

💡 Constants.ENTRY_NODE 是 Sentinel 的根节点 ，统计所有入口流量的聚合指标。

---

🧩 四、关键机制详解

✅ 1. 系统负载（Load）与 BBR 算法

Sentinel 借鉴了 TCP BBR（Bottleneck Bandwidth and RTT） 的思想：

当系统负载高时，不一定立刻熔断，而是判断当前是否处于"危险区"。

checkBbr() 逻辑：

private static boolean checkBbr(int currentThread) {
    // 计算理论最大并发 = 最大成功QPS × 最小RT / 1000
    long theoreticalMaxConcurrency = maxSuccessQps * minRt / 1000;
    
    // 如果当前线程数 > 理论最大并发，说明已过载 → 拒绝
    return !(currentThread > 1 && currentThread > theoreticalMaxConcurrency);
}

📌 意义 ：避免在"管道刚满"时误判为过载。只有当排队严重（线程数远超容量） 时才熔断。

---

✅ 2. CPU 使用率的双重采集

double systemCpuUsage = osBean.getSystemCpuLoad();      // 整机 CPU
double processCpuUsage = ...;                           // 当前 JVM 进程 CPU

currentCpuUsage = Math.max(processCpuUsage, systemCpuUsage);

🎯 为什么取 max？

• 在 物理机 上，systemCpuLoad 更准
• 在 Docker/K8s 容器 中，systemCpuLoad 可能不准（看到的是宿主机负载），而 processCpuTime 更可靠
• 取 max 保证最坏情况被捕捉

---

✅ 3. 多规则合并策略

当你配置多个 SystemRule 时：

loadSystemConf(rule) {
    highestSystemLoad = Math.min(highestSystemLoad, rule.getHighestSystemLoad());
    qps = Math.min(qps, rule.getQps());
    // ...
}

📌 取最严格的阈值（最小值）

例如：规则 A 设 QPS=100，规则 B 设 QPS=80 → 实际生效的是 80

---

🛠️ 五、如何使用？

示例：限制全局 QPS ≤ 100，线程数 ≤ 10，RT ≤ 50ms

List<SystemRule> rules = new ArrayList<>();

SystemRule rule = new SystemRule();
rule.setQps(100);          // 全局 QPS ≤ 100
rule.setMaxThread(10);     // 并发线程 ≤ 10
rule.setAvgRt(50);         // 平均 RT ≤ 50ms

SystemRuleManager.loadRules(Collections.singletonList(rule));

高级用法：结合 CPU 和 Load（仅 Linux）

SystemRule rule = new SystemRule();
rule.setHighestSystemLoad(5.0);   // load average ≤ 5
rule.setHighestCpuUsage(0.8);     // CPU ≤ 80%
SystemRuleManager.loadRules(...);

⚠️ 注意：highestSystemLoad 在 Windows 上无效（返回 -1）

---

📊 六、监控与日志

当系统负载超过阈值时，SystemStatusListener 会打印详细日志：

[INFO] Load exceeds the threshold: 
load:6.2341; cpuUsage:0.8721; qps:120.5; rt:65.3; thread:15; 
success:110.2; minRt:20.0; maxSuccess:115.0

帮助你快速定位是 CPU、线程、RT 还是 QPS 导致的问题。

---

🧪 七、性能测试建议

官方注释提到：

"To set the threshold appropriately, performance test may be needed."

✅ 建议步骤：

1. 压测系统，找到 最大稳定 QPS（maxSuccessQps）
2. 记录此时的 平均 RT、线程数、CPU、Load
3. 将阈值设为 稳定值的 70%~80%，留出安全余量

---

❓常见问题

Q：为什么设置了 QPS=100，但实际通过了 105？

A：Sentinel 注释中提到：

real passed QPS = QPS set + concurrent thread number

因为 QPS 统计有延迟，且允许少量突发（类似令牌桶），这是正常现象。

Q：SystemRule 和 DegradeRule 有什么区别？

对比项	SystemRule	DegradeRule
作用范围	全局（整个应用）	单个资源（如 /order）
触发条件	系统级指标（CPU/Load/QPS）	资源级指标（RT/异常）
目的	防系统雪崩	防慢调用/异常扩散

✅ 两者互补：SystemRule 保命，DegradeRule 精细化治理。

---

✅ 总结

Sentinel 的 SystemRule 是一个"系统级熔断器"，它：

• 🛡️ 从全局视角保护应用，防止资源耗尽
• 📈 实时采集 CPU、Load、QPS、RT、线程 5 大指标
• 🧠 引入 BBR 思想，避免误判
• 🐳 兼容容器环境，精准获取进程 CPU
• ⚙️ 支持动态配置，无需重启

💡 最佳实践 ：在生产环境中，务必配置 SystemRule 作为最后一道防线，配合 DegradeRule 和 FlowRule，构建完整的稳定性体系。

理解这些，你就掌握了 Sentinel 最高层级的自我保护能力。