降级

【背景】 最近热榜上有两篇帖子我反复看了几遍：一篇讲超时重试配错把流量放大成雪崩，一篇讲 Kafka offset TTL 导致的静默丢消息。两件事表面上不相关，但我把它们放在一起看，发现背后是同一个问题——当你的某个依赖（下游服务、DB、

背景 Java 17 + Spring Boot，订单履约链路是 4 跳纯串行：网关(800ms SLO) → 订单服务 → 库存服务 → 风控服务 → 结算服务（最后一跳落 MySQL，一条事务内含 3 条 DML + 1 条查询，P50

【背景】 一个很日常、但每次聊起来都会吵起来的场景：服务 A 依赖下游风控 / 鉴权 / 计费，下游抖了或超时了，A 是「放行 + 事后补录」（fail-open），还是「拦截 + 事后人工放行」（fail-close）？ 我踩过的两个坑，

先声明我的底色：8 年数据工程，日常和高并发、时延、吞吐打交道，所以我对"把慢依赖异步掉"这件事，既用过、也被坑过。今天想抛一个我观察下来争议最大、却很少有人把判断标准说清楚的争点：一个同步链路里出现"慢依赖"（DB 慢查询、RPC 抖动、

背景 我负责一个支付核心服务，单笔支付请求扇出到 3 个下游（并行调用，全部成功才算支付完成）： | 下游 | 作用 | 正常 P99 | 满载时 P99 | 超时 | |------|------|----------|---------

先给一个真实案例打底。 去年帮一个电商团队复盘：大促前压测，核心下单接口 P50 稳定 45ms，P99 偶尔飙到 900ms+。团队第一次方案是「加线程池」——从 200 拉到 800，结果 P99 不但没降，峰值时反而飙到 2.3s，伴

【背景】 社区这阵子聊限流、熔断、超时、并发模型都很热闹，但我发现「降级」这个词大家挂在嘴边，真要画边界时却最含糊。上个月我帮一个支付聚合接口做容量评审，QPS 6000，核心依赖两个下游：风控（P99 平时 40ms，抖动能到 800ms

«结论先行：我们以为"功能上线"的判据是主路径 100% 通过，但真正出事故的几乎全是降级路径——因为降级路径平时不跑，代码在腐化，验收单上也没人验证它。这篇文章给一份可以直接抄进验收单的"降级链路验收清单"，并附上我踩过的 4 个坑。»