限流、熔断、降级有什么区别？
简化版
限流因“流量超过预算”而拒绝一部分请求，熔断因“依赖近期不健康”而暂时停止调用，降级则定义“原能力不可用时提供什么替代结果”。 三者分别解决容量、故障隔离和业务兜底，可以串联使用，但触发信号、作用对象和返回语义不能混为一谈。
详细版
限流通常在入口或调用前依据 QPS、并发与配额做准入；健康系统也可能触发。熔断器根据失败率、慢调用率和最小样本数在 CLOSED/OPEN/HALF_OPEN 间切换，主要避免继续冲击故障依赖。降级是业务策略，可由限流、熔断、人工开关或资源水位触发。
例如推荐服务容量 1000 QPS：入口令牌桶只允许最多 1000 次请求进入依赖调用，超额请求按契约快速失败或走本地榜单；依赖错误率连续超过 50% 后熔断，短路请求再执行明确的降级策略。支付写请求可以限流和熔断，但不能用“支付成功”作降级结果，只能明确失败或返回处理中。
完整版教学
一、三者回答三个不同问题
限流问“现在还能接多少”，熔断问“这个依赖还值得调用吗”，降级问“不能提供原结果时怎么办”。若只用“都是保护系统”概括，就无法解释规则该放在哪里、看什么指标以及用户最终得到什么。
记忆钩子：流量太多用限流，依赖太坏用熔断，功能保不全用降级。
二、限流是容量准入
令牌桶、滑动窗口和并发上限都属于限流。它可以按用户、租户、接口或全局配额实施，即使下游完全健康，只要超过购买配额或安全容量也会拒绝。限流结果应明确 429/资源繁忙，或者进入受控排队。
capacity = 1000 QPS
incoming = 1400 QPS
允许约 1000，拒绝/排队约 400三、熔断是基于历史的短路
熔断需要一个观测窗口。最近 10 秒至少 100 次请求且失败率超过 50%，可 OPEN 30 秒；之后只放 5 个半开探测。没有最小请求数会因偶发失败误触发，没有半开限额会在恢复瞬间再次冲垮依赖。
熔断拒绝的是“本来允许尝试但当前判断成功概率太低”的调用，与租户配额无关。
四、降级定义业务结果
降级可能返回缓存、静态榜单、裁剪字段、只读模式或明确不可用。它不一定由故障触发，大促前也可主动关闭非核心功能以释放资源。关键是替代结果不伪造余额、库存、支付等核心事实，并让调用方知道数据质量变化。
| 机制 | 主要信号 | 直接动作 | 是否需要业务语义 |
|---|---|---|---|
| 限流 | QPS、并发、配额 | 拒绝/排队 | 部分需要 |
| 熔断 | 失败率、慢调用 | 暂停调用 | 异常分类需要 |
| 降级 | 故障、过载、人工 | 返回替代结果 | 强依赖业务语义 |
五、三者怎样串联
请求 -> 身份/配额限流 -> 并发限流 -> 熔断判断 -> 调用依赖
| | |
+------拒绝-------+------短路----+
-> 降级策略/明确失败顺序不是全球唯一，但必须确定且可解释。被入口限流的请求不应计入下游失败率；熔断短路也不应伪装成下游真实调用失败。降级可以承接前两者，却不代表所有拒绝都必须返回成功。
六、数字场景看协作效果
推荐依赖稳定容量 800 QPS，突发流量 1200 QPS。限流先将超出的 400 QPS 明确拒绝，剩余 800 QPS 中依赖因数据库故障出现 60% 失败，熔断后停止继续消耗连接，并让后续短路请求走本地榜单。完全打开后，看板可同时显示约 400 QPS 限流拒绝、熔断状态 OPEN 和约 800 QPS fallback；三类指标不能统一记为成功。若产品要求被限流请求也走榜单，则 fallback 会覆盖约 1200 QPS，必须据实际契约统计。
支付场景同样数字下，fallback 只能是明确失败或可查询的处理中状态。这说明治理组件相同，降级语义仍由业务决定。
七、常见误区与追问
- 误区：熔断就是错误率限流。 熔断有状态和恢复探测，限流是准入预算。
- 误区：降级一定返回 HTTP 200。 核心结果未知时应诚实失败或返回处理中。
- 误区：配置限流后不会雪崩。 慢调用在限额内仍可能耗尽线程，需要并发隔离和超时。
- 误区：所有拒绝都计入熔断窗口。 本地配额拒绝没有反映下游健康度。
- 追问：先限流还是先熔断？ 按治理链确定；通常先处理本地准入，再判断目标依赖状态。
- 追问：健康依赖会被降级吗？ 会，主动大促降级可释放非核心资源。
- 追问：三者如何监控？ 分别看允许/拒绝、状态/探测、fallback 类型/业务影响。
八、加强记忆
用“量、病、替”区分三者：限流管请求量，熔断判断依赖是否生病，降级提供替代行为。答题时依次说触发信号、执行动作、恢复方式和用户语义，再用一条请求链说明统计不能互相污染，就能避免概念混淆。