系统自适应熔断必须配置systemrule而非仅degraderule，因后者是静态的、不感知cpu/load等真实负载，无法应对“静默过载”；systemrule通过highestcpuusage、avgrt、maxthread等指标全局动态限流，任一超标即压低入口qps。
系统自适应熔断为什么不能只配 DegradeRule
直接配置 DegradeRule（比如异常比例 60%、RT > 1s）属于静态熔断，它不感知 CPU、Load、内存等真实负载变化。当机器已过载但接口还没报错或没超时，DegradeRule 完全不会触发——这正是服务雪崩前最危险的“静默过载”阶段。Sentinel 的系统自适应能力不在熔断规则里，而在 SystemRule，它才是专为负载兜底设计的机制。
SystemRule 的关键参数和生效逻辑
SystemRule 不是“熔断某个接口”，而是全局性地限制整个应用入口流量，让 QPS / 并发线程数与系统负载达成动态平衡。它同时监控多个指标，任一超标即限流：
-
highestSystemLoad：Linux 系统 Load 均值上限（如 5.0），仅 Linux 生效；Windows 下该字段被忽略 -
avgRt：所有入口资源的平均响应时间阈值（毫秒），持续超时会压低入口 QPS -
maxThread：当前应用总并发线程数上限，防止线程池耗尽 -
qps：入口总 QPS 上限，硬性兜底 -
highestCpuUsage：JVM 进程 CPU 使用率（0.0–1.0），如设为0.8表示 CPU 占用超 80% 就开始限流
注意：SystemRule 是“与”关系判断：只要任意一个指标持续超过阈值（默认窗口 1 秒，连续 5 次），就会自动降低入口总 QPS，不是抛出 BlockException，而是让新请求排队或直接拒绝。
如何在 Spring Boot 中配置并验证 SystemRule
必须通过编程方式注册，Dashboard 不支持 SystemRule 的可视化配置（这是常被忽略的关键点）：
public class SystemRuleInit {
static {
List<systemrule> rules = new ArrayList();
SystemRule rule = new SystemRule()
.setHighestCpuUsage(0.75) // CPU 超 75% 触发
.setAvgRt(450) // 全局平均 RT 超 450ms 触发
.setMaxThread(500); // 总线程超 500 触发
rules.add(rule);
SystemRuleManager.loadRules(rules);
}
}</systemrule>
把这个类放在 @SpringBootApplication 启动类同包或子包下，并确保它在应用启动早期执行。验证时别只看单个接口日志——要观察 Sentinel Dashboard 的「系统维度」监控页，确认 system_load、cpu_usage、rt 曲线是否实时上报，且入口 QPS 在负载升高后明显下降。
和 DegradeRule 混用时的优先级与陷阱
SystemRule 和 DegradeRule 是两套独立机制，但生效位置不同：DegradeRule 在资源入口（如 @SentinelResource 方法内）拦截，SystemRule 在网关/Filter 层统一拦截所有入口流量。这意味着：
- 当 CPU 达到 90%，
SystemRule已开始限流，此时你再调用一个被DegradeRule保护的方法，可能根本进不去——因为请求已被系统层拒绝 - 不要给
SystemRule设过于激进的qps值（如 10），否则会掩盖真实负载问题；它应作为最后防线，而非日常限流手段 - 本地开发环境默认不采集
system_load和cpu_usage，需确保生产 JVM 启动参数包含-Dsentinel.app.type=1并启用 JMX
真正起作用的永远是那个在高负载下依然能稳住入口 QPS 的 SystemRule，而不是一堆精细但脱离系统状态的 DegradeRule 配置。
