聚合接口 7 个下游「1 慢拖 6 快」：orTimeout 只挡等待不杀任务，超时预算怎么切、降级粒度怎么定、用什么监控信号提前预警？

背景

我负责一个 B 端实时运营大盘（Spring Boot 3.1 + JDK 17，Tomcat 线程池 400，单实例 8C16G），核心接口 /dashboard/overview 一次请求要并行聚合 7 个下游，返回一个统一 VO：

| 下游 | 类型 | P50 | P99 | 关键性 | |---|---|---|---|---| | 用户中心 | RPC | 15ms | 45ms | 必须 | | 订单服务 | RPC | 30ms | 80ms | 必须 | | 库存服务 | RPC | 25ms | 70ms | 必须 | | 营销中台 | RPC | 210ms | 850ms | 可降级（缺失时展示"暂无活动"） | | 优惠券 | RPC | 18ms | 55ms | 可降级 | | 搜索热度 | DB | 40ms | 120ms | 可降级 | | 风控分 | RPC | 22ms | 60ms | 必须 |

现象

• 大盘整体 P50 稳定 95ms、P99 稳定 1120ms（SLO 是 P99 ≤ 800ms，长期不达标）。
• 拆 traceId 看：7 个下游里 6 个 P99 都在 150ms 以内，只有营销中台 P99 是 850ms，它一个把整个大盘 P99 从 320ms 拉到 1120ms。
• 当前代码（简化版）：

List<CompletableFuture<Fragment>> futs = downstreams.stream()
    .map(d -> CompletableFuture.supplyAsync(() -> d.fetch()))  // 默认 commonPool
    .toList();
CompletableFuture.allOf(futs.toArray(new CompletableFuture[0]))
    .orTimeout(1200, TimeUnit.MILLISECONDS)
    .join();

• 超时后前端拿到的是 TimeoutException，整个大盘白屏，而不是"6 快 1 慢"的降级结果——orTimeout 只挡了 join，没停任务、也没做按片降级。

已尝试

1. 调大 Tomcat 线程池到 800：P99 没改善，内存 +18%；
2. 把 orTimeout(1200) 改成 orTimeout(600)：P99 降到 820ms，但超时率从 0.3% 涨到 4.2%，前端白屏更频繁；
3. 给营销中台单独加 500ms 超时（用 orTimeout 套在单个 future 上）：P99 降到 650ms，达标了，但 join() 之后那个 500ms 超时的任务还在 commonPool 里跑，JFR 里能看到 commonPool 的 queue 在慢时段堆积，怀疑任务没被真正取消；
4. 把营销中台的超时改成"缓存兜底"（超时读上一版缓存）：降级逻辑 OK，但缓存一致性靠 5 分钟 TTL，业务方不接受"5 分钟内可能看到已下线的活动"。

期望得到的答案形态

社区里 id=1377（超时预算切分）、id=1501（N 条 DB 查询的预算分配）、id=922（orTimeout 不杀任务）我都读过了，但它们要么聚焦"预算怎么切"、要么聚焦"commonPool 耗尽"，没正面回答"1 慢拖 6 快"的聚合层降级设计。想请教三个具体问题：

1. 超时预算切分：7 个下游关键性不同，超时预算该怎么切？是按"必须下游 P99 + 可降级下游 P99 的加权"切，还是按"必须下游 P99 × 1.2 + 可降级下游一律给 300ms 硬顶"切？有没有可复用的预算分配公式或经验值？
2. 降级粒度：按下游片降级（每个下游独立 orTimeout + 独立兜底）vs 按整体超时（allOf.orTimeout + 统一兜底），线上该怎么选？如果按片降级，怎么在 join() 之后把"超时的那一个"的任务真正停掉（JDK 17 没有虚拟线程的 Thread.stop，commonPool 任务没法 cancel 运行中线程）？有没有生产验证过的"超时即停"姿势（比如把任务跑在独立线程池 + 队列拒绝策略，或 Resilience4j 的 TimeLimiter + 自定义 executor）？
3. 监控信号：有没有一套在 P99 劣化之前就能预警"某个下游正在拖大盘"的指标？我现在只有整体 P99，等它爆了才知道是哪个下游慢，想提前 30 分钟看到"营销中台 P99 在爬"。可观测性上怎么落地（trace 维度分下游打点 + 分位聚合，还是 per-downstream 独立 histogram）？

参考

• id=922《CompletableFuture.orTimeout 超时了任务却还在跑》——确认了 orTimeout 不杀任务的结论；
• id=1501（N 条 DB 查询的超时预算切分）——预算切分思路，但聚焦 DB 层；
• id=1377（超时预算切分 + 重试放大系数）——预算切分与重试放大的量化方法。