一个接口被打爆，全站跟着挂？限流、熔断、降级三种保护方案对比

企业系统的事故经常是这样发生的：某个第三方接口响应变慢，调用它的请求堆积，线程池占满，整个系统被拖垮——起因只是一个边缘功能，代价是全线瘫痪。又或者大促流量超预期十倍，数据库被打满，所有用户一起报错。保护系统的三板斧是：限流（拦住过多请求）、熔断（故障时暂时切断调用）、降级（保核心舍边缘）。这篇文章把三种机制的原理和组合用法讲清楚。

一、三种机制的真实面目

限流。 给接口设定"每秒最多处理多少请求"（QPS 阈值），超出的请求直接拒绝或排队等待。它保护的是"系统不被流量压垮"。常见算法有固定窗口、滑动窗口、令牌桶——工程上不用纠结细节，记住一点：限流值要根据压测结果定，拍脑袋定的阈值不是保护，是掩耳盗铃。

熔断。 调用下游服务（第三方接口、内部微服务）时，持续监控失败率和响应时间，一旦超过阈值（比如 1 分钟内失败率超 50%），自动"跳闸"：后续请求不再实际调用，直接快速失败，过一段时间后试探恢复。它保护的是"不被下游的故障传染"——对方的接口挂了，你的系统只是这个功能不可用，而不是跟着一起死。

降级。 系统压力过载或依赖故障时，主动关掉非核心功能，把资源让给核心链路：大促时关掉"猜你喜欢"推荐保住下单支付，报表高峰期把实时统计换成昨日缓存。它回答的问题是"保什么、舍什么"——这需要业务上提前想清楚，技术只是执行。

二、按场景对号入座

对外提供接口（开放 API、供应商门户）： 限流是标配，按调用方分配配额，防止单一方把系统打爆。某物流客户的开放接口上线限流后，一家大客户的异常重试脚本（每秒 200 次）被稳稳拦在门外，此前这种脚本每月都会制造一次"神秘宕机"。

依赖第三方接口（支付、短信、物流查询、电商平台）： 熔断是标配。第三方接口的稳定性你控制不了，能控制的是"它挂了别拖死我"。配合降级：短信通道熔断后自动切换备用通道，物流查询熔断后返回"查询中，请稍后"。

流量有明显峰谷的系统（电商、抢单、定时活动）： 三件套组合使用——入口限流保总量、下游熔断防传染、预案降级保核心。关键是降级预案要提前写好、提前演练，凌晨两点现想"关哪个功能"是灾难的开始。

三、落地时的三个要点

阈值从压测来，不从感觉来。 上线前用压测工具摸清系统的真实承载力，限流值设为承载力的 70%-80%。没压测过的系统，阈值写的是多少都没意义。

被限流和熔断的请求，要返回明确的响应。 "系统繁忙，请稍后重试"加上明确的状态码，让调用方知道是"被保护了"而不是"系统坏了"。前端要有对应的友好提示，别让终端用户看到一串异常堆栈。

保护动作要可观测。 限流了多少请求、熔断触发了几次、降级开启了多久，全部进监控告警。保护机制启动意味着系统在承压，这是运维最需要知道的时刻——别让它静默发生。

写在最后

限流、熔断、降级的本质，是承认"流量会超预期、下游会出故障"这个现实，然后提前设计好"最坏情况下的活法"：限流保不被压垮、熔断保不被传染、降级保核心不死。三者组合使用，配上压测得来的阈值和可观测的告警，系统才能在意外面前"优雅地受损"，而不是"整齐地瘫痪"。