扇出 3 个下游的支付接口：下游各自 P99 不同，怎么做「分层准入」让通知降级而不是整笔失败？

背景

我负责一个支付核心服务，单笔支付请求扇出到 3 个下游（并行调用，全部成功才算支付完成）：

| 下游 | 作用 | 正常 P99 | 满载时 P99 | 超时 | |------|------|----------|------------|------| | 风控引擎 | 反欺诈评分 | 80ms | 600ms+ | 1000ms | | 账务系统 | 记账 | 15ms | 40ms | 500ms | | 通知服务 | 短信/推送 | 50ms | 200ms | 800ms |

正常态 QPS 约 1200，三个下游都有余量。但风控引擎是间歇性瓶颈——大促或风控规则变更时 P99 会飙到 600–1200ms，此时 1000ms 超时会命中 5–15% 的请求，这些请求整笔失败（因为当前实现是 all-or-nothing：3 个下游全部 200 才算成功）。

实际业务影响：风控慢的那 10% 请求里，账务和通知其实都完全正常——但因为"全部成功"的语义，通知也被连带取消了。用户侧看到的是"支付失败"，但钱可能已经扣了（账务先返回成功），体验极差。

现象

• 风控 P99 > 500ms 时，支付成功率从 99.9% 掉到 97–98%
• 被拒绝的请求里 80% 是"账务成功 + 通知成功 + 风控超时"的组合——本质是风控慢拖累了整笔
• 当前超时 1000ms 是拍脑袋设的：调小（800ms）拒绝更多，调大（1500ms）则 Tomcat 线程被占更久，P99 整体恶化
• 已用 Tomcat maxThreads=200、HikariCP maximumPoolSize=30，没有额外队列

已尝试与结果

1. 每个下游独立 Circuit Breaker（Resilience4j）：对"风控直接 500"有效，但对"风控慢但没挂"（P99 600ms）无效——breaker 不会打开，只是每次多等 600ms。
2. 调超时 + 线程隔离（每个下游独立线程池）：隔离了线程占用，但语义没变——还是 all-or-nothing，风控超时=整笔失败。
3. 异步化通知（把通知改成 MQ 投递）：解决了通知被连带取消的问题，但"风控超时=支付失败"的语义没变，用户还是看到失败。
4. 读社区相关讨论：
   • 看到《连接池不是越大越好》(id=18) 里讲的 P99 抖动排查思路，确认了"资源饱和不是看 CPU/GC，而是看等待队列深度"——我现在的瓶颈本质就是风控引擎的等待队列深度，但我在准入侧没有这个信号，只能事后看超时率。
   • 《fail-fast vs 排队降级》(id=178) 的讨论里，大家倾向于"入口做准入，下游别排队"——我的场景就是入口准入决策，但准入决策不是二元的（接/拒），而是"接但用哪个计划"。

期望得到的答案形态

我想了解的是 "分层准入 / 自适应降级计划" 的具体工程落地，而不是泛泛的"要做降级"：

1. 准入决策信号从哪来？ 我不想在每个请求里对风控做一次"探活"（多一次 RTT）。社区里有人用滑动窗口 P99 分位数做准入阈值（比如风控 P99 连续 3 个窗口 > 400ms 就切到降级计划），有没有人踩过"窗口大小怎么选、窗口内怎么平滑"的坑？

2. 降级计划的粒度怎么定？ 我的直觉是 3 档：

   • 全量计划：风控 + 账务 + 通知（正常态）
   • 降级计划 A：风控 + 账务（通知异步补偿，不阻塞）
   • 降级计划 B：仅账务（风控走异步后置审计，先放行）

   但"降到哪一档"的决策逻辑是硬编码阈值还是动态评分？动态评分的话，评分因子怎么加权（P99、QPS、错误率、队列深度）？有没有人做过"基于下游实时 P99 的权重公式"，贴一下公式或伪代码？

3. 乐观 vs 悲观的取舍：

   • 悲观（先查健康再决定计划）：多一次健康检查 RTT，但决策确定
   • 乐观（全量发出，超时后降级重试非关键路径）：不额外 RTT，但"超时后才知道要降级"意味着账务可能已经扣了、风控还没出结果——这种"半成功"状态的回滚/补偿复杂度大家怎么控制的？

4. 可观测性：降级计划切换后，怎么在监控里一眼看出"当前处于哪个档位、为什么切过来的、什么时候能切回去"？有没有人把"准入档位"做成一个 Prometheus gauge 指标 + Grafana 大盘的？

约束

• Java 17 / Spring Boot 3.x，不想引入额外中间件（Kafka 已有，但不想为这个目的新引入）
• 支付语义要求：账务操作必须强一致，不能"先放行再补账"
• 风控可以异步后置（业务方已确认），但不能完全没有（合规要求）