Sentinel系统保护规则深度解析

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

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

🧠 一、SystemRule 是什么？

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

✅ 它监控 5 个关键指标：

⚠️ 注意：只对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()：核心拦截逻辑

publicstaticvoidcheckSystem(ResourceWrapperresource,intcount)throwsBlockException{// 1. 只检查入口流量if(resource.getEntryType()!=EntryType.IN)return;// 2. 检查 QPSif(Constants.ENTRY_NODE.passQps()+count>qps)thrownewSystemBlockException("qps");// 3. 检查线程数if(Constants.ENTRY_NODE.curThreadNum()>maxThread)thrownewSystemBlockException("thread");// 4. 检查平均 RTif(Constants.ENTRY_NODE.avgRt()>maxRt)thrownewSystemBlockException("rt");// 5. 检查系统负载（带 BBR 优化）if(load>threshold&&!checkBbr(currentThread))thrownewSystemBlockException("load");// 6. 检查 CPU 使用率if(cpuUsage>threshold)thrownewSystemBlockException("cpu");}

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

🧩 四、关键机制详解

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

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

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

checkBbr()逻辑：

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

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

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

doublesystemCpuUsage=osBean.getSystemCpuLoad();// 整机 CPUdoubleprocessCpuUsage=...;// 当前 JVM 进程 CPUcurrentCpuUsage=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=newArrayList<>();SystemRulerule=newSystemRule();rule.setQps(100);// 全局 QPS ≤ 100rule.setMaxThread(10);// 并发线程 ≤ 10rule.setAvgRt(50);// 平均 RT ≤ 50msSystemRuleManager.loadRules(Collections.singletonList(rule));

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

SystemRulerule=newSystemRule();rule.setHighestSystemLoad(5.0);// load average ≤ 5rule.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 精细化治理。

✅ 总结

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

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

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

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