API限流、熔断、降级，三件事别再当成一回事

系统一到高峰期，接口变慢、超时、报错就会一起冒出来。这时候很多人会听到三个词：限流、熔断、降级。它们都和系统稳定性有关，但解决的问题其实并不一样。要是把这三个概念混着用，方案就很容易做偏：本来该保护系统入口，结果却去改页面展示；本来该快速切断故障依赖，结果还在让请求硬扛。

想把这三个词分清，可以把系统想象成一家很忙的餐厅。限流像门口控客流，熔断像发现后厨起火后先暂停接单，降级则是高峰时先把复杂菜品临时下架，保证核心服务还能继续运转。

限流是在入口控制节奏

限流的目标，是防止请求量在短时间内把系统直接冲垮。比如某个热门接口平时每秒只处理几百次请求，但活动开始后一瞬间涌进几万请求，如果不做限制，数据库、缓存、应用线程都可能被打满。限流就是提前规定阈值，超出的请求排队、拒绝或稍后再试。

常见做法包括固定窗口、滑动窗口、漏桶、令牌桶等算法。对业务方来说，不一定非要背算法名，关键是理解：限流发生在流量进入系统之前或刚进入时，本质是在保护整体容量，避免所有人一起把服务拖死。

熔断是在故障时及时止损

熔断更多是针对“下游依赖已经有问题”的场景。比如你的订单服务要调用支付接口、库存接口、短信接口，如果其中一个依赖连续超时或错误率飙升，再继续不断重试，只会把上游线程也耗尽，故障层层放大。熔断的作用，就是在检测到异常达到阈值后，暂时停止这条调用链，直接返回失败或兜底结果。

它像电路里的保险丝，问题严重到一定程度时先断开，防止整条线路烧掉。等过一段时间再尝试半开恢复，如果依赖正常了再放量恢复。这种机制特别适合微服务、第三方接口调用、支付链路、消息投递等对外部依赖很强的系统。

降级是在资源紧张时保核心

降级的重点不一定是完全报错，而是“先牺牲次要体验，保住核心功能”。比如大促期间商品详情页的推荐模块先关闭，评论统计延后显示，个性化排序暂时退回默认排序；又或者视频站在高峰时先降低清晰度，保证能播。这些都属于降级。

降级并不是失败，而是一种主动取舍。资源有限时，与其所有功能都卡死，不如优先保证下单、支付、登录、核心查询这些关键路径正常。它更多体现的是业务策略，而不仅仅是技术动作。

三者之间到底怎么配合

限流防的是“请求太多”，熔断防的是“依赖故障拖垮自己”，降级防的是“资源不够时全线崩盘”。它们常常会一起出现，但出手时机不同。系统刚遭遇洪峰流量时，先靠限流守住入口；某个依赖服务已经明显异常时，用熔断切断故障传播；整体资源紧张又必须保住主流程时，再通过降级牺牲次要能力。

一个成熟系统通常不会只靠一种手段。比如秒杀系统先对接口做限流，再给订单服务和支付服务做熔断保护，最后把推荐、埋点、消息提醒这些非核心能力临时降级。这样系统即使顶不住全部压力，也不会一下子全面瘫痪。

最常见的误区

第一个误区是把限流当成万能性能优化。限流只能控量，不能解决代码本身慢的问题。第二个误区是熔断后没有兜底逻辑，结果用户看到的只是大片报错。第三个误区是降级方案只停留在PPT里，平时不演练，真出事时根本没人知道该关哪些功能。

还有一种情况也很常见：接口本来只是短暂抖动，却因为阈值设置太激进，熔断频繁触发，反而把正常请求挡在外面。所以这些策略不是配上就完事，而是要结合真实流量和故障场景不断调。

最后用一句话记住

限流是挡洪水，熔断是断故障，降级是保主线。三者都不是为了“让系统永远不出问题”，而是为了在问题出现时，把损失控制在可接受范围内。

如果你在做接口平台、微服务系统、电商活动页或高并发业务，把这三个概念真正分清，比单纯堆框架名词更重要。真正稳定的系统，不是没有波动，而是遇到波动时知道该先挡哪里、断哪里、保哪里。