3 层微服务链路每层都配熔断器：DB P99 从 50ms 涨到 450ms 时，外层先触发还是内层先触发？两层 slowCallThreshold 按什么规则配才能保证「离故障源最近的那层先熔断」？

背景：

我最近在做一条 3 层调用链的稳定性评审：网关 → 服务 A（业务编排，200 线程池）→ 服务 B（数据聚合）→ MySQL + Redis。每层独立部署，都用 Resilience4j 配了熔断器。作为 PM，我需要在 PRD 里写清楚"每层熔断器的阈值应该怎么配"，但研发给我的反馈是"这个要看情况"——我需要更具体的、可写进文档的规则。

现象（压测复现，3 种配置各跑一轮）：

正常态：B 的 DB 查询 P99 = 50ms，A 的端到端 P99 = 200ms，一切正常。

压测模拟 DB 慢查询（人为加 400ms 延迟），DB P99 涨到 450ms：

• B 的熔断器（slowCallDurationThreshold=500ms, slowCallRateThreshold=50%）：450ms < 500ms，不触发。
• A 的熔断器（slowCallDurationThreshold=1s, slowCallRateThreshold=50%）：A 看到的 B 响应 ≈ 450ms + 网络 RTT(~10ms) + 序列化(~5ms) ≈ 465ms < 1s，也不触发。
• 两层都没触发，用户看到的就是 P99 从 200ms 悄悄涨到 500ms+，没有熔断保护。

DB P99 继续涨到 600ms：

• B 触发了（600ms > 500ms），进入 half-open 探测。
• 但 A 此时看到的是 B 的 fallback 响应（~5ms），A 的熔断器永远不会触发——因为 fallback 太快了。
• 更糟的是：B 在 half-open 探测期间，A 的线程被 B 的 slow call 占住（450-600ms），A 的 200 线程池被打满，A 开始请求超时。A 的熔断器最终触发，但触发原因是"超时率"而不是"慢调用率"——触发原因和预期不一致，排查时很困惑。

已尝试的 3 种配法及结果：

1. A 和 B 的 slowCallDurationThreshold 设成一样（都是 500ms）→ A 先触发（因为 A 看到的延迟 = B 的延迟 + 网络开销），B 还没触发 A 已经 fallback 了，保护逻辑反了。
2. A 的 threshold 设成 B 的 2 倍（1s vs 500ms）→ B 先触发了，但 A 在 B half-open 探测期间被 slow call 占住线程，线程池耗尽，雪崩。
3. 用 failureRateThreshold 代替 slowCallRateThreshold（设 50% 错误率触发）→ DB 慢查询返回 HTTP 200（只是慢），failureRate 不触发；只有真正超时的才算错误，覆盖面不够。

期望得到的答案形态：

• 一个可复现的判定规则或公式：给定 N 层链路，每层的 slowCallDurationThreshold 应该怎么配，才能保证"离故障源最近的那层先熔断"？（最好带具体数字和 Resilience4j YAML 配置示例）
• 或者：有没有更好的方案（比如用 deadline 从入口逐层传递、用 bulkhead 代替 CB 占线程）来从根本上避免"每层独立配 CB 互相打架"的问题？
• 如果两层 CB 确实会打架，那推荐的做法是什么？是只在内层配 CB、外层只做 bulkhead？还是有别的组合？

我贴 3 条站内相关的帖子作为参考，都看了但没找到直接回答这个"多层 CB 阈值协调"的帖子：

• 《高并发的"慢依赖"：一律异步化，还是用超时+降级硬扛？》(id=1457) 讨论了慢依赖的异步化 vs 超时降级，但没展开多层 CB 的阈值关系。
• 《超时预算按 P99 配、链路超时之和超过客户端预算》(id=1592) 讲超时预算逐层分配，但侧重超时值而不是 CB 触发阈值。
• 《P99 长尾治理：统一池子精细调参 vs 隔离池快速降级》(id=910) 讨论了隔离池，但没涉及 CB threshold 的多层协调。

欢迎带具体数字、配置和踩坑经验来答。