解读

国内互联网生产环境普遍采用“网关→聚合层→业务域→基础域”这类纵深 8～12 级的微服务调用。若每一级都把超时设为 1 s，链路端到端理论超时 10 s，但实际情况是：

1. 每一级 1 s 是“单机超时”，不是“链路累计超时”；
2. 下游一旦慢 1 s，上游线程池/连接池瞬间被占满，重试流量再叠加，雪崩在 3～5 s 内就能从底部蔓延到顶部；
3. 国内主流注册中心（Nacos、Consul、Eureka）默认 30 s 才摘除节点，无法快速止血；
4. 面试时只回答“减少超时”或“加熔断”会被认为太泛，必须给出量化公式、参数推导和配套验证手段。

知识点

1. 超时类型：连接超时（connectTimeout）、读超时（readTimeout）、业务超时（bizTimeout）、链路超时（deadline）。
2. 超时传递：OpenTracing/SkyWalking 的 baggage、Dubbo 的 attachment、Spring Cloud 的 X-Timeout-Deadline。
3. 超时预算公式：T_budget = P99.9(入口) – Δ，Δ 含序列化、GC、网络抖动，通常取 200 ms；每级超时 T_i = T_budget × weight_i，weight_i 按该服务 P99 历史占比分配。
4. 重试策略：只在“链路最上游”做 1 次指数退避重试（backoff=0.2×2^n），下游严禁重试；重试路由到不同单元（可用区）。
5. 快速失败：熔断阈值 50% 或 P99>300 ms 持续 5 个 bucket（1 s 一个 bucket），熔断 5 s 后放 3 个探针请求。
6. 资源隔离：
   • 线程池：按“接口+重要等级”拆池，核心线程=CPU×2，队列=0，拒绝策略抛异常不拖尾；
   • 连接池：maxIdle=maxActive=CPU×4，超时 borrowMaxWait=50 ms。
7. 验证方法：
   • 影子表全链路压测：用 ChaosBlade 注入 3 s 延迟，观察 99 线是否突破 500 ms；
   • 红蓝军演练：在晚高峰切 20% 流量到“故障集群”，验证熔断、兜底、降级是否 30 s 内恢复。

答案

1. 先定入口 SLA：网关 99 线 500 ms，成功率≥99.9%，由此倒推链路总预算 500 ms。
2. 用过去 7 天监控数据计算每级服务 P99 占比，得出权重：
   网关 10%、A 15%、B 12%、C 8%、D 8%、E 10%、F 12%、G 10%、H 8%、I 7%，总和 100%。
   每级超时 = 500 ms × 权重，例如 A=75 ms、B=60 ms、C=40 ms……并向下取整到 5 ms 的整数倍。
3. 在框架层（Dubbo 3 或 Spring Cloud 2021）统一注入“链路剩余时间”：
   入口设置 deadline=500 ms，每级用当前时间戳减去入口时间，得到剩余时间；若剩余时间<20 ms 直接抛 FastFailException，不再调用下游。
4. 重试与熔断：
   • 只在最上游网关做 1 次重试，退避 200 ms、400 ms 两档；
   • 每级内置 Sentinel 熔断，规则：慢调用比例>50% 且最小请求数≥5 时熔断 5 s；
   • 熔断期间返回兜底缓存或默认值，保证“可降级”接口成功率 100%。
5. 资源隔离：
   • 核心服务用独立线程池，非核心走共享池；
   • 连接池超时 50 ms，拿不到连接立即失败，防止排队。
6. 上线前验证：
   • 用 Gatling 模拟 1.5 万并发，在链路第 5 级注入 400 ms 延迟，结果入口 99 线 480 ms、成功率 99.92%，满足 SLA；
   • 故障演练摘掉第 7 级 50% 节点，熔断 3 s 后自动恢复，入口成功率保持 99.95%。
7. 上线后监控：
   • Prometheus 每 5 s 采集一次“剩余时间<0 的请求数”，若 QPS>5 立即告警；
   • 每周跑一次全链路压测，动态调整权重，确保超时策略随业务迭代持续有效。

拓展思考

1. 跨地域双活场景下，专线 RTT 增加 30 ms，超时预算需重新分配，可把权重模型改成“RTT+P99”双因子线性回归，自动输出新超时表。
2. Service Mesh 采用 Envoy 时，可用“outlier detection”代替应用层熔断，但需把 consecutive_5xx 改为 consecutive_gateway_failure=2，并调小 interval=1 s，才能与上游 500 ms 超时匹配。
3. 对异步消息链路（Kafka/RocketMQ）而言，超时策略应转为“重试 Topic+死信队列”，消费端只负责幂等，不阻塞上游线程，此时雪崩风险从“线程池”转移到“消息堆积”，需要监控消费延迟而非调用超时。