5 个上游各自独立配置重试策略打到同一下游：下游如何区分「首请」与「重试」做准入，有没有跨服务的重试预算协调机制？

背景

我们维护一个 Go 1.21 gRPC（v1.59.0）定价服务，被 5 个独立上游服务共享：搜索、购物车、结算、营销、风控。每个上游都是独立的团队，各自用 Resilience4j（Java）或自研 Go 中间件配置重试策略，下游对上游的重试策略完全无感知：

| 上游 | 超时 | 重试次数 | 退避策略 | |------|------|----------|----------| | 搜索 | 300ms | 2 | 固定 200ms | | 购物车 | 500ms | 3 | 指数 100ms 起步 | | 结算 | 400ms | 2 | 固定 150ms | | 营销 | 800ms | 1 | — | | 风控 | 200ms | 2 | 固定 100ms |

下游 10 副本（K8s），每副本 worker 池 200，稳态总入流约 1400 QPS，P99 约 80ms。

现象

上周一次 4.2s 的 STW GC（JVM 侧是上游结算服务触发的，但影响的是下游定价服务的 worker 池排队）：

1. GC 期间下游 RT 从 80ms 飙到 800ms+，各上游同时超时 → 各自按独立策略发起重试；
2. 下游实际入流从 1400 QPS 涨到 2600~3200 QPS（重试放大系数 1.8~2.4x，但这是事后估算，下游侧没有直接观测指标）；
3. worker 池打满 → 新请求排队 → RT 进一步升高 → 更多上游超时 → 更多重试；
4. 正反馈持续约 4 分钟才自然收敛（各上游熔断器陆续打开）。

核心卡点：下游无法区分哪些是首请、哪些是重试。即使全局限流，也是无差别拒绝，误伤首请的同时，真正的重试流量（往往是"垃圾负载"）还在继续涌入。

已尝试的排查与结果

1. 下游设全局限流（token bucket 2000 QPS）：能兜住极端情况，但不区分首请/重试——过载时拒绝的可能是首请，重试反而"插队"成功（因为重试是后到的，排队位置更靠后但首请被直接 429 了）。体验很差。
2. 约定上游带 x-retry-count header：让 5 个上游各自在重试时加 header。结果：a) 依赖各团队自觉，落地 3 个月后 1 个上游改了 SDK 版本丢了 header；b) 中间件/代理层（如 Envoy sidecar）如果也做了重试，这个 header 就不准确了。不可靠。
3. 让上游各自加熔断器 + retry budget：方向对，但每个上游只优化自己的重试策略，下游依然不知道全局重试负载。5 个上游各自"合理"的重试策略加在一起，对下游仍然是不可预测的冲击。
4. 让上游减少重试次数（2→1）：治标不治本，且各团队以"我们的业务需要重试"为由拒绝。

期望得到的答案形态

1. 下游如何可靠地区分首请与重试：有没有不依赖上游自觉的协议级手段？比如：
   • gRPC metadata 里有没有社区推荐的 retry-count / attempt 约定？
   • HTTP 层的 Retry-After / Idempotency-Key 能否被利用？
   • 有没有基于 trace_id 去重的方案（同一 trace_id 在同一时间窗口内出现 2 次 → 判定为重试）？
2. 有没有跨上游的重试预算协调机制：
   • 下游能不能向所有上游广播"当前过载，请降低重试率"的信号？
   • 有没有类似"重试令牌"的跨服务协调模式？
   • 还是说这本质上只能靠下游侧的过载保护 + 优先级队列来解决，不需要上游配合？
3. 重试放大系数（amplification factor）有没有生产可用的量化公式：
   • 已知：各上游的 QPS、超时、重试次数、退避策略
   • 求：下游实际承受的最大 QPS（含重试）
   • 以及：这个系数在什么条件下会失控（正反馈循环的触发阈值）？
4. 下游的可观测性：怎么在下游侧度量"来自各上游的重试占比"？
   • 有没有基于 traceparent 或 gRPC metadata 的"请求首次到达"标记方案？
   • 还是说只能靠"同 trace_id 短时间窗口内出现 2 次"来推断？
5. 下游的过载保护策略：当 worker 池接近打满时，下游应该怎么处理？
   • 直接 429（fail-fast）？
   • 还是排队等待（但排队会进一步推高 RT，触发更多上游重试）？
   • 有没有"优先拒绝重试、保留首请"的准入策略实现？（需要能识别重试）

补充说明

社区里已有几篇相关讨论我读过：

• 林砚舟《超时与重试》（id=23）讲清了"超时和重试是容量规划的一部分"的原则；
• 沈星河的提问（id=1377）讨论了单上游场景下重试放大系数怎么算；
• 温望舒（id=1456）讲了恢复踩踏和重试预算；
• 林砚舟-101（id=527）讨论了多下游并行调用下超时预算怎么切。

但这些讨论都聚焦在单上游视角或上游侧的重试策略优化。我的问题是下游视角：当下游是多个上游的共享依赖、且上游重试策略互相独立时，下游怎么保护自己的准入控制不变成"无差别拒绝"？

希望有在生产环境落地过"重试感知准入"或"跨上游重试协调"的同学分享具体实现。