高并发链路超时预算（deadline）逐层传递时如何避免"每层各留余量"导致总超时远超前端 SLA？

【背景】 我负责一个 B 端交易网关（JDK 17 + Spring Boot 3.2，Tomcat max-threads=400），对外 P99 SLA 是 800ms。一个典型请求链路：网关 → 订单服务 → 库存服务 → MySQL + Redis。每一层都是独立进程，用 Feign/OkHttp 互调。

【现象】 各层超时配置如下：

• 网关层：整体请求超时 800ms
• 网关→订单服务：connect 100ms + read 500ms
• 订单服务→库存服务：connect 80ms + read 400ms
• 库存服务→MySQL：HikariCP connectionTimeout 3000ms，socketTimeout 2000ms
• 库存服务→Redis：lettuce timeout 1000ms

单压每一段都没问题，但全链路压到 1500 QPS 时，P99 经常打到 2s+，超时请求的 trace 里能看到"订单服务收到请求时，网关已经只剩 320ms 预算，但订单服务内部给下游配的 read 超时是 400ms——它根本不知道自己只剩 320ms"。

【已尝试的排查】

1. 把每层 read 超时按"前端 SLA ÷ 层数"均分（800/4=200ms），结果 P50 从 120ms 飙到 350ms——200ms 对 DB 慢查询段太紧，正常波动就超时了。
2. 尝试在网关层用 gRPC deadline 透传（metadata 里塞 deadline 时间戳），但下游是 REST，没有统一拦截器，改起来侵入性大。
3. 查了 Resilience4j 的 TimeLimiter，发现它是"本地超时"，不感知上游剩余预算。

【期望得到的答案形态】

• 有没有一个可落地的 deadline propagation 方案：上游在 header 里塞"剩余预算"，下游据此动态调整自己的超时？具体 header 格式、拦截器写法、异常处理（预算耗尽时是快速失败还是降级）？
• 对于"均分预算"vs"动态剩余预算"，在高并发下各自的 P99 表现差异有多大？有没有实测数据或理论模型？
• 如果链路中有"必须等 DB 返回"的段（不能降级），预算分配策略怎么定？

补充：不要求一定要用 gRPC，REST + 自定义 header 的方案也可以。重点是"每层知道自己还剩多少时间"这个机制怎么落地。