熔断、降级与限流：系统扛压时为什么不能硬撑

一个系统在低压状态下能稳定运行，并不意味着它在高峰、异常或者下游故障时也能稳定运行。很多线上事故的共同点并不是功能写错了，而是系统在超出承受范围后还在“硬撑”，结果把局部问题拖成了整体雪崩。

所以到了服务治理这一层，系统设计的重点就不再只是“平时能跑”，而是“当压力上来或者依赖异常时，如何优雅地失败，而不是失控地崩掉”。

熔断、降级与限流，本质上都在做同一件事：当系统已经不适合继续按原路径处理请求时，主动收缩能力边界，用可控损失换整体稳定。

为什么系统不能只靠硬件扩容解决问题

扩容当然重要，但它并不能解决所有风险。

有些问题来自瞬时流量突刺，有些问题来自下游依赖超时，有些问题来自内部资源争用，还有些问题来自某个热点接口被异常放大。即使你有更多机器，如果请求模式本身已经失控，或者某个依赖已经明显异常，继续放量只会把故障传播得更快。

所以系统稳定性不能只靠“资源更多一点”，还要靠“边界更清楚一点”。

限流最直接的作用，是防止请求量超过系统当前可承受范围。

它保护的不只是 CPU 和内存，更是在保护线程池、连接池、数据库、下游依赖以及整个调用链的可恢复空间。如果没有限流，系统可能在极短时间内被流量淹没，来不及自我恢复，就已经进入不可用状态。

从这个角度看，限流不是在“拒绝用户”，而是在“保住系统还能服务更多用户”。

熔断常常发生在下游依赖持续异常时。

如果某个依赖已经连续超时、错误率很高，而上游还在不停地继续打过去，那其实是在浪费资源，也会让故障恢复更慢。熔断的意义就在于：当系统观察到某个依赖已经明显不健康时，主动暂时切断调用，避免更多请求继续堆进去。

所以熔断不是消极放弃，而是一种主动隔离故障、等待恢复的策略。

降级的本质，是在系统资源紧张或依赖异常时，保核心、舍非核心。

并不是所有能力都必须在高压时完整保留。某些推荐功能、统计功能、非关键展示或者次要写入，在高峰期完全可以临时简化、延迟甚至跳过。只要核心链路还在，系统就仍然具备对外服务能力。

所以降级的关键，不是“什么都少做一点”，而是提前识别核心能力和非核心能力，在必要时有计划地让出资源。

因为它们针对的是同一类问题的不同阶段。

限流更像入口处的第一道边界，防止不合理流量直接冲进来。熔断更像依赖异常时的局部隔离，避免坏节点持续拖垮调用方。降级则是在系统整体承压时，对能力进行优先级重排，尽量保住核心主路径。

它们组合起来，才能形成比较完整的抗压策略。

一个常见误区是把这些能力理解成“出了问题再补”。但如果不在平时设计阶段就想清楚核心链路、可牺牲链路和系统容量边界，真到事故发生时，往往已经没有足够时间优雅处理。

另一个误区是限流、熔断、降级都做了，但阈值和策略完全拍脑袋，最终导致误伤正常流量或者保护不住关键依赖。

选你现在最熟悉的一个系统，试着回答下面几个问题。

只要把这些问题想清楚，你对系统稳定性的理解就会比“服务还能跑”再往前走一大步。

熔断、降级与限流，并不是为了让系统在异常时“看起来没那么糟”，而是为了真正建立可控的失败机制。限流守住入口边界，熔断隔离异常依赖，降级保住核心能力。一个成熟系统的稳定性，不只是建立在高峰时处理更多请求的能力上，更建立在压力来临时知道该放弃什么、保护什么。