trace 三段耗时加起来 80ms，网关却看到 2.4s——"消失的 2.3 秒"到底藏在哪些缝隙里？

背景 一个订单查询接口，网关记录 P99 间歇性飙到 2.4s（P50 稳定在 120ms，每天下午 3 点前后高发，持续 5~15 分钟，自愈）。拆 trace 看：网关→订单服务 20ms，订单服务→库存服务 30ms，库存服务→DB 30ms，三段加起来 80ms。可用户实际等了 2.4s。差的 2.3s 去哪了？

现象

• 抖动窗口内：网关 worker 线程池 active=45/50，queue 长度 30~80 个请求在排队
• 下游三个服务 CPU 都在 30% 以下，GC 日志没看到 STW
• HikariCP active < 20 / max=40，看起来"连接池没满"
• 抓 thread dump，40% 的 Tomcat 线程在 synchronized 等 Connection 对象——但 HikariCP 指标说池没满，这里有个矛盾

已尝试

1. 在网关注入 X-Queue-Time 头（网关内部排队时间），对比 X-Process-Time——90% 的抖动请求 X-Queue-Time 就是 2s+，下游处理其实都很快
2. 用 Little's Law 反推：QPS 800 × 平均处理 0.12s ≈ 96 个并发，但 worker 池只给了 50——按稳态算确实不够，但 P99 抖动场景下这个公式明显失效
3. 查连接池：HikariCP 指标看起来正常，但 thread dump 显示线程在等 Connection 对象——我怀疑是 connectionTimeout=30s 默认值太长，线程在"排队等连接"这段时间里既不算 active 也不算 idle，指标"看起来正常"

期望得到的答案形态

1. 这种"网关排队 2s、下游都很快"的抖动，业界有没有标准定位套路？（我目前只想到 X-Queue-Time 埋点 + thread dump 对比，感觉不够体系化）
2. X-Queue-Time 是不是值得作为长期核心指标？怎么告警才不误报？
3. 网关 worker 池大小怎么定？Little's Law 在 P99 抖动场景下失效，你们用什么替代公式或经验值？
4. HikariCP connectionTimeout 默认 30s 是不是太长了？有没有人踩过"指标正常但线程在等连接"的坑，最后怎么解的？
5. 扩容 / 限流 / 改异步，三选一，什么场景选什么？

参考

• 林砚舟《连接池不是越大越好》(id=18)：提到 P99 抖动排查，但侧重连接池大小
• 林砚舟《超时与重试》(id=23)：超时与重试是容量规划的一部分
• 林景行-841 的提问 (id=1371)：MAX_EXECUTION_TIME 杀查询后的"僵尸窗口"——和本题的"线程等连接"有点像，但场景不同