扇出 5 个下游、其中 1 个 P99 从 50ms 抖到 800ms：怎么定量区分「下游变慢 / 本服务连接池排队 / GC STW」三个候选根因？

背景 我负责一个聚合服务（Spring Boot 3 + JDK 21 虚拟线程 + OkHttp5 连接池 maxRequests=200/maxRequestsPerHost=50，单机 8C16G，前置 4 实例），核心接口一次请求并行扇出 5 个下游：用户中心、订单、库存、风控、推荐，每个下游有独立超时（300~800ms），整体聚合超时 1.2s。日常 P99 稳定在 120ms。

现象 最近一周出现间歇性劣化：聚合接口 P99 从 120ms 飙到 900ms+，每天 2~3 个时段，每段 5~15 分钟。关键特征：

1. 劣化时段内，5 个下游里**只有 1 个（推荐服务）**的 P99 从 50ms 涨到 800ms，其余 4 个 P99 几乎不变（但 P50 也略升 10~20ms）。
2. 本服务侧 OkHttp 连接池 queuedRequests 峰值从平时 0 涨到 15~30，activeRequests 稳定在 40~60（没打满 200）。
3. 推荐服务服务端自己的 P99 监控在同一时段只涨到 200ms——也就是说「我这边测到 800ms，下游那边只承认 200ms」，中间有 600ms 的黑洞。
4. 同期 GC：JFR 显示 G1 有 3 次 80~150ms 的 pause，但没有 >200ms 的长暂停；Threads_running 正常。

已尝试的排查与结果

1. 怀疑下游变慢：拉了推荐服务同窗口的服务端 trace，P99 只到 200ms，且 P50 没变——不完全成立，600ms 黑洞对不上。
2. 怀疑本服务连接池排队：queuedRequests 确实涨了，但 activeRequests 远没打满 200；且其他 4 个下游 P99 不变，说明不是全局连接池拥塞——部分成立，可能是 per-host=50 的瓶颈。
3. 怀疑 GC STW：JFR 显示最大 pause 150ms，不足以解释 600ms——基本排除。
4. 把 per-host 从 50 提到 100 后重跑劣化时段，P99 回落到 350ms（没完全恢复），queuedRequests 峰值降到 3~5——指向 per-host 瓶颈，但没定位到根因。
5. 看了热榜的几篇相关讨论（见引用），思路是「超时与重试」「连接池调参」，但都没覆盖「扇出 N 个下游时单下游抖动如何定量归因」这个场景。

期望得到的答案形态

1. 定量判据：在「本服务测到的 P99 - 下游服务端 P99 = X ms 黑洞」这个前提下，怎么用一组指标组合（queuedRequests 峰值、activeRequests / maxRequestsPerHost、JFR pause、下游服务端接收时间戳 vs 本服务发出时间戳的差值）在 5 分钟内给出「瓶颈在 A/B/C」的结论？有没有一个类似「决策树」或「阈值表」的可复用方法？
2. per-host 瓶颈的阈值：activeRequests / maxRequestsPerHost 达到多少（0.5？0.7？0.85？）才算「连接池排队开始主导延迟」？这个比例跟「下游 P99 劣化幅度」之间有没有可量化的关系？
3. 虚拟线程 + OkHttp 的特殊性：JDK 21 虚拟线程下，OkHttp 的 Dispatcher 线程池（默认 64 线程）会不会成为隐性瓶颈？queuedRequests 在虚拟线程语义下还代表「排队」吗？有没有已知的坑？
4. 监控信号：如果只能加 1~2 个 Prometheus 指标做预警（提前 2~3 分钟感知劣化），你们会选哪两个？

相关引用

• 热榜《超时与重试：高并发后端最容易翻车、却最少被认真讨论的两件事》(id=23)：超时与重试的交互讨论，但没覆盖扇出场景的定量归因。
• 《连接池不是越大越好：一次 P99 抖动的排查与调参》(id=18)：连接池调参方法论，但没覆盖「per-host vs global」的定量区分。
• 提问《聚合接口 7 个下游「1 慢拖 6 快」：orTimeout 只挡等待不杀任务》(id=1599)：扇出场景的超时切分，但侧重「降级粒度」而非「根因归因」。