服务过载时你更倾向 fail-fast 直接拒绝，还是排队降级「保住一部分」？

【背景】 最近翻了社区几篇帖子——连接池调参、超时重试、线程池从 200 拉到 2000 雪崩的复盘——发现大家聊的都是「单点怎么调」，但有个更上游的问题很少被正面讨论：当系统整体过载（不是某个组件慢，而是入口流量超过承载力），你的第一反应是快速拒绝，还是尽量把请求「接住」？

我自己在做高并发后端这 8 年，见过两种团队，风格完全相反：

做法 A：fail-fast 派。 入口限流 + 快速拒绝，宁可丢 20% 请求，也要保证留下来的 P99 不抖。理由很硬：排队本身就是延迟放大器，队列越长 P99 越差，而且过载时下游（DB、RPC）的恢复时间被排队请求持续拖住，雪崩半径更大。这类团队通常有明确的容量数字，超限就是超限，不装。

做法 B：排队缓冲派。 用有界队列 + 优先级 + 部分降级（比如非核心字段跳过、缓存兜底），目标是「过载时 95% 的请求还能拿到 80 分的答案」。理由也很硬：用户侧一次 503 的体感损失，往往比一次 500ms 的慢响应大得多；B 端客户更怕「失败」不怕「慢」。

我的倾向：偏 A，但有边界条件——fail-fast 的前提是拒绝是「可预期的、有补偿的」。如果拒绝之后没有重试通道、没有降级页面、没有客户端退避策略，那 fail-fast 只是把故障甩给用户，本质上还是失败，而且更难排查。真正的分歧点我觉得不在「拒不拒」，而在：拒绝策略是放在入口网关、应用层、还是业务语义层？ 越靠业务语义层（比如「这个用户的第 N 次刷新允许降级，第一次必须真查」），效果越好，但实现成本也越高。

【想听大家聊】

1. 你们线上的过载保护实际做在哪一层？网关 / 应用限流 / 业务降级，各占多少权重？
2. 有没有「fail-fast 反而放大故障」的真实案例？（比如客户端不做退避，拒绝后打得更凶）
3. 排队派的同学：你们的队列上限怎么定的？是按 P99 目标反推，还是拍脑袋？
4. 如果只能留一个指标来监控「系统是否快过载了」，你选什么？（我个人的选择是：队列等待时间的 P99，而不是 CPU 或 QPS，聊聊看）