超时预算：微服务链路中最容易被忽略的一等公民

一个真实的雪崩场景

某电商系统在大促当天出现了奇怪的现象：下单接口 P99 从 380ms 涨到 4.2s，但每个下游服务的自身耗时监控都很"健康"——库存服务 30ms、优惠券服务 45ms、风控服务 120ms。所有单点指标正常，链路整体却崩了。

原因不复杂：下单接口给每个下游都配了 3 秒超时。当风控服务因为一次冷启动偶发抖动到 900ms 时，网关层的线程池开始堆积；堆积导致排队，排队让更多请求同时"在飞"，最终每个请求都在等一个已经注定超时的下游结果。3 秒 × 并发数 = 线程池瞬间耗尽。

这就是典型的超时配错：不是超时太短，而是每个环节各自为政，没有任何人算过整条链路的预算。

为什么"每个服务配 3 秒"是错的

超时不是单机配置，而是一笔沿着调用链向下分配的资源。假设网关承诺给用户 1 秒，那么这条链路上所有环节的时间消耗之和必须小于 1 秒，还要留出余量给网络抖动和重试。

如果每一跳都独立地填一个"感觉安全"的数字，会出现两种失败模式：

• - 预算超发：链路 5 跳，每跳 3 秒，理论最大耗时 15 秒。用户早已关掉页面，服务器还在为一个死请求燃烧资源。
• - 重试放大：A 调用 B 超时后重试 2 次，B 又调用 C 重试 2 次，一次用户请求在下游变成 9 次。超时配合重试，等于给自己制造了 9 倍流量。

核心原则：Deadline 传播，而不是 Timeout 配置

正确的做法是把"还剩多少时间"作为请求的一部分传下去，而不是让每一跳自己决定能等多久。

gRPC 原生支持这件事。客户端设置 deadline，框架会把它编码进 grpc-timeout header，服务端通过 context 拿到剩余时间：

// 网关入口：整条链路的预算上限
ctx, cancel := context.WithTimeout(r.Context(), 800*time.Millisecond)
defer cancel()

resp, err := orderClient.CreateOrder(ctx, req)

// 服务端：不重新设置超时，直接继承上游预算
func (s *OrderServer) CreateOrder(ctx context.Context, req *pb.CreateReq) (*pb.CreateResp, error) {
    // 剩余预算已包含在这里，无需再次 WithTimeout
    stock, err := s.stock.Deduct(ctx, ...)   // 下游拿到的是同一个 deadline
    if err != nil {
        return nil, err
    }
    ...
}

关键点在于：中间层不要重置 deadline。很多团队在 service 层无脑写 context.WithTimeout(ctx, 3*time.Second)，这一行就把传播链掐断了——下游拿到的是全新的 3 秒，而不是"上游只剩 200ms"。

给关键路径切分预算

有了传播还不够，还要在关键路径上主动切分。一个实用的做法是预算比例分配：

比例不是拍脑袋，而是从历史 P99 反推：风控服务 P99 是 120ms，给 240ms 意味着它有 2 倍抖动空间；库存服务 P99 只有 30ms，给 200ms 就过于宽松，可以压缩到 150ms 把余量让给风控。

切分之后，每一跳都用 context.WithTimeout(ctx, budget) 缩小自己的预算，但基数永远是上游传来的 ctx，这样剩余时间只会单调递减，不会凭空复活。

快失败：预算耗尽时立刻返回

预算耗尽后继续等待毫无意义。标准的处理是检查 ctx.Err() 并立即返回 DEADLINE_EXCEEDED，同时不要在这个节点上重试：

select {
case <-ctx.Done():
    return nil, status.Error(codes.DeadlineExceeded, "budget exhausted")
case res := <-ch:
    return res, nil
}

更进一步，可以在预算低于某个阈值（比如 100ms）时跳过非关键下游。优惠券核销失败不影响下单主流程时，直接降级返回"无优惠"，比让整个请求超时更好。

重试的正确姿势

重试必须满足三个条件，缺一不可：

1. 1. 剩余预算足够：ctx.Deadline() 减去当前时间，必须大于"单次超时 + 退避时间"，否则重试只是延长痛苦。
2. 2. 只重试幂等操作：读操作、带幂等键的写操作可以重试；扣库存这种非幂等操作必须靠幂等键保护。
3. 3. 退避带抖动：固定退避会让所有失败请求在同一时刻再次撞击下游，指数退避 + 随机抖动（jitter）才是正解。

backoff := time.Duration(1<<uint(attempt)) * 50 * time.Millisecond
backoff += time.Duration(rand.Int63n(int64(backoff / 2)))  // jitter
if deadline, ok := ctx.Deadline(); ok && time.Now().Add(backoff).After(deadline) {
    return err  // 预算不够，放弃重试
}

如何验证这套设计真的生效

配置改完不算完，需要可观测性兜底。三个必看指标：

• - 预算消耗比：elapsed / budget。持续高于 0.8 的环节就是瓶颈，即使它的绝对耗时看起来很小。
• - DEADLINE_EXCEEDED 占比：按服务、按上游调用方分别统计。突然升高通常意味着某一跳吃掉了别人的预算。
• - 重试次数分布：如果 P95 重试次数大于 0，说明超时配置偏紧或者下游确实在抖。

华为云 APM 这类链路追踪可以直接看到 span 上的剩余预算，但即使没有这类工具，在日志里打一行 deadline_remaining_ms 也足够定位问题。

小结

超时预算的本质是把有限的时间当成一笔要分配的预算，而不是给每个服务贴一个孤立的数字。三条规则背下来就够用：

1. 1. Deadline 沿链路传播，中间层绝不重置；
2. 2. 按历史 P99 给关键路径切分预算，留出余量给抖动最大的那一跳；
3. 3. 预算耗尽立即失败，重试前先算账。

回到开头那个场景：改完之后，下单接口的 P99 稳定在 420ms，风控服务还是偶尔抖到 900ms，但超时的请求会在 800ms 准时返回失败，线程池不再堆积，雪崩消失了。下游的抖动依然存在，但它不再有机会变成一场事故。