客户端已用 full jitter 退避，熔断半开的「恢复探测」该怎么限流：探测并发数、探测窗口、预算占比怎么定才不二次踩踏？

背景

我维护一个 BFF 网关（Java 17 + OkHttp，线程池 200），下游是库存查询服务（Go，gRPC over HTTP2）。晚高峰稳态 3000 QPS。已经按社区惯例做了两层防护：

1. 客户端重试：最多 1 次，间隔 full jitter（random(0, min(cap, base*2^attempt))），cap=800ms；
2. 熔断：滑动窗口 10s / 错误率 >50% 熔断，熔断 10s 后进入 HALF_OPEN。

平时没事。但今年 Q3 一次下游 GC 抖动 40s 恢复后，我们网关侧观察到「恢复瞬间 3s 内又打出 2 万+ 请求」，下游刚喘过气又被压垮，二次故障持续了 90s。事后看监控：熔断恢复后所有线程的 in-flight 请求同时涌回 + half-open 探测流量叠加。

现象

• 下游 P99 从故障时的 5s 降到 200ms（已恢复），但 3s 后又飙回 3s+；
• 网关侧 half-open 状态持续 90s 才切回 CLOSED；
• 下游 GC 日志显示恢复后又触发了一次长 STW。

已尝试

1. 把 half-open 的探测并发从「不限」改成 1（同一时间只放 1 个请求过去）——好一些但 half-open 窗口拉长到 200s+；
2. 把熔断恢复时间从 10s 拉长到 30s——二次踩踏概率降了但单次故障恢复变慢；
3. 加了一个「探测成功 N 次才切 CLOSED」的条件（N=3）——逻辑上合理但 N 设多大全靠拍。

想问的具体问题（期望答案形态）

1. 探测并发数：half-open 期间到底放几个请求过去？按「总并发 × 比例」还是「固定 1~N」？有没有考虑下游容量（比如它恢复时线程池还没满）的做法？
2. 探测窗口与切 CLOSED 的条件：「连续成功 N 次」vs「窗口内成功率 > X%」哪个更稳？N / X 的合理起点？
3. 预算占比：探测流量占网关总并发预算的百分比上限？（我猜 5%~10% 但没数据）
4. 有没有「渐进式放量」的成熟做法：1 → 5 → 20 → 100% 这种阶梯，而不是二选一的 half-open / closed？
5. 可观测性：half-open 状态该打哪些点（探测 QPS、成功率、下游 P99）才能提前发现「二次踩踏」？

社区里 id=1456 讲了 jitter + 重试预算 + 探测限流的三重加固，id=1593 讨论了 429 的重试边界，但「客户端侧熔断半开的探测限流参数怎么定」这块我还没看到有帖子给具体数字。想请有 Resilience4j / Hystrix / Envoy outlier detection 实战经验的同学给一份可直接抄的参数组合 + 你们的踩坑数据。

环境

• 网关：Java 17 / OkHttp 4.12 / Resilience4j 2.x（CircuitBreaker + TimeLimiter）
• 下游：Go 1.22 / gRPC 1.60 / 4C8G，恢复后 GC 线程池满需 8~15s
• 稳态 QPS 3000，峰值 5000