从网关再到各个后端服务，如何设置 RPC 的超时时间，要考虑哪些问题？
- 标签：后端、场景题
🏛 业务架构师
这道题是超时治理的全链路版本，我的核心框架是：全链路超时预算（timeout budget）——网关 > 聚合服务 > 基础服务，逐层递减，预算要在设计时分配好而不是事后补。
分层设置原则
网关超时 3s
└─ 聚合服务 A（预留自身逻辑 200ms + 余量）
├─ 下游 B：500ms（B 的 P99 是 300ms）
└─ 下游 C：800ms（含一次重试）
└─ 数据库：聚合服务自己的超时必须小于网关给它的剩余时间- 自上而下分配：用户能接受的总时长（如 3s）是硬约束，往每层分配预算
- 自下而上校验：每层的 P99 × 重试次数 + 串行依赖数，不能超过上级预算，超了就要并行化或砍依赖
要考虑的关键问题
- 超时一致性：上游超时 ≤ 下游超时会导致上游放弃后下游还在空跑，浪费连接池和线程池——大促容量里这部分"僵尸处理"能吃掉 20% 资源
- 重试策略收敛：每层都重试 = 指数级放大（2 层各重试 2 次就是 9 倍请求）；原则是重试只放在一层（通常网关或入口层），只重试幂等接口，配重试预算熔断
- 超时后的动作：读类接口返回兜底数据（缓存旧值/默认文案），写类接口返回明确失败 + 幂等键让用户安全重试，支付类转异步查询结果
- 动态化：超时配置进配置中心，大促前统一收紧（快速失败保容量），平日放宽（保体验）
业务视角收尾：超时治理的收益直接体现在转化率上——用户 3 秒等不到结果就流失，而层层空跑的处理把本可以服务正常请求的容量烧掉了。我做大促容量评审时，超时预算表和限流阈值表是必查项，这两个配置错了，扩容多少台机器都救不回来。
🏗 系统架构师
这题比 28 题更进一步：要答"整条链路的超时预算分配体系"，我按四层讲。
1. 全局预算倒推：先定用户侧 SLA，比如 P99 < 1s。网关整体超时 1s，是全链路预算的"天花板"，超了就直接断开返回降级结果，避免请求无意义堆积拖垮线程/连接资源。
2. 逐层递减分配：网关(950ms) → 聚合服务 A(800ms) → 下游 B(600ms)、C(500ms 并行) → DB/缓存(100ms 级)。原则是每一层超时 = max(下游并行调用超时) + 自身耗时 + 20% 余量，保证超时永远从最深处先触发，上层收到的是下游明确的超时错误而不是自己先掐断。
3. 串并行与重试预算：串行调用超时累加，所以串行层级不能深；并行调用取 max。重试只给幂等的读接口，且"超时 × (重试次数+1) ≤ 上游预算"，比如留给下游 600ms、单次 300ms，最多重试 1 次。网关层对非幂等 POST 不自动重试。
4. 三个必须考虑的问题：
- 超时兜底资源释放：超时后上层放弃，但下层可能还在跑，线程、连接照样占用——所以要配熔断，连续超时就快速失败，而不是每个请求都等满超时
- 区别对待慢依赖：DB、Redis、第三方 HTTP、文件 IO 的超时特性完全不同，不能共用一组配置；第三方接口还要单独设"配额池"隔离，防止第三方抖动耗尽全局连接
- 可观测与动态调整：所有超时进配置中心可热更，按 P999 耗时变化季度性 review；超时率、熔断次数上监控大盘
一句话：自上而下定预算，自下而上定超时，中间用熔断和重试预算把放大效应控住。
💻 全栈开发专家
这题的关键词是超时预算逐层递减 + 防重试放大。我按一个请求的路径从外到内规划。
预算分配（示例）
用户可容忍 3s
└─ 网关总超时 3s
└─ 聚合服务 2.5s（留 500ms 给自身逻辑）
├─ RPC-A 800ms（含 1 次重试：500×2=1s 不行，改为 800 无重试）
├─ RPC-B 800ms
└─ DB 500ms（事务里绝不远程调用）铁律：父超时 > 所有子调用超时之和的并行耗时，串行调用的子超时之和必须小于父超时，否则父先断开，子调用全在做无用功（资源已经花了，结果没人要）。
必须考虑的问题
- 重试放大：上游 1 次重试 = 下游 2 倍流量，层层重试指数放大直接雪崩。我通常只允许最底层重试，且失败率超阈值自动熔断（Resilience4j）。
- 超时透传：上游把 deadline 剩余时间传下去（gRPC 的 deadline、Dubbo 隐式传参），下游发现没预算直接快速失败，别排队半天。
- 读超时 vs 连接超时分开配：连接超时给短（200ms，连不上就是挂了），读超时按 P99 定。
- 兜底：每个下游配降级策略（缓存旧值/默认值），超时不能变成用户可见的报错。
踩过的坑 网关 3s、聚合 2.9s 看似没问题，但聚合里串行了 3 个各 1s 的 RPC——预算根本不够，压测必炸。上线前一定用故障演练（ChaosBlade 注入延迟）验证整条链路的超时行为。