从一次线上雪崩说起：微服务熔断与降级的工程化落地

事故复盘：一个 800ms 的慢查询如何放大成全局故障

去年双十一前压测，我们的订单服务在 QPS 只有日常三倍时就整体雪崩了。事后看监控，起因非常简单：商品详情服务有一个未加索引的查询，P99 从 30ms 涨到 800ms。真正致命的是放大器效应——订单服务对商品服务的调用超时设置是 30 秒，重试 3 次，线程池核心线程数 200。当 800ms 的延迟遇到 30 秒超时，200 个线程在 10 秒内被占满，订单服务开始拒绝所有请求，紧接着购物车、支付回调接连超时，一条链路拖垮了整个交易域。

这次事故让我重新审视了一个老问题：超时、重试、熔断、限流这四个东西，必须作为一个整体设计，任何单点优化都会被其他三个抵消。

一、超时不是越长越安全

很多人把超时当成"给足对方时间"的善意，实际上超时是调用方愿意为这次请求付出的最大成本。它应该由上游的 SLA 反推，而不是由下游的平均耗时决定。

经验公式：

超时预算 = 入口 SLA 剩余预算 × 0.6 / 该链路剩余串行调用数

如果网关对用户的承诺是 1 秒，订单服务已经花了 50ms，后面还有 3 个串行依赖，那么单次下游调用的超时不应该超过 (1000-50)×0.6/3 ≈ 190ms。剩下的 40% 留给 GC、网络抖动和序列化。

Go 里一个常见的写法问题：

// 反例：每一层都重新给一个"足够大"的超时
ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
defer cancel()

正确做法是让超时沿着 ctx 向下传递，子调用只能更短，不能更长：

func (s *OrderService) Create(ctx context.Context) error {
    // 入口已经带了 deadline，这里只做"不超过剩余时间"的裁剪
    ctx, cancel := context.WithTimeout(ctx, 200*time.Millisecond)
    defer cancel()

    item, err := s.itemClient.Get(ctx, req.ItemID)
    if err != nil {
        return err
    }
    ...
}

二、重试是雪崩的加速器，不是稳定性的补丁

重试的前提是故障是瞬时的、且失败请求对下游没有成本。这两个前提在过载场景下都不成立：下游已经慢了，你再重试三次，等于把流量放大四倍。

我们最终采用的规则是三条：

1. 只对幂等且错误类型可判定为瞬时的请求重试（连接重置、503、明确的超时）；

2. 重试必须带指数退避 + 抖动，且总重试次数不超过 1 次（同步链路）；

3. 重试预算与熔断共享：如果熔断器已经半开，禁止重试，让流量快速失败。

RetryPolicy policy = RetryPolicy.builder()
    .maxAttempts(2)                       // 首次 + 1 次重试
    .backoff(Duration.ofMillis(50), 2.0)  // 指数退避
    .jitter(0.3)                          // 30% 抖动，避免重试风暴同步
    .retryOn(t -> t instanceof SocketTimeoutException || isRetryableStatus(t))
    .build();

三、熔断器的三个参数决定了它是保护还是误伤

熔断器不是"打开就完事"，参数配错会变成二次故障源。我们踩过的坑集中在三点：

1. 统计窗口太短，用抖动当成了故障

滑动窗口 10 秒时，一次 GC 停顿就能把失败率推过阈值，熔断器反复开合，形成"熔断抖动"。后来改成 基于请求量的最小样本数：窗口内请求数少于 20 个时，无论失败率多高都不触发熔断。

2. 半开状态只放一个请求，恢复太慢

Resilience4j 默认半开时放行 permittedNumberOfCallsInHalfOpenState=10，但如果下游是慢启动的（比如刚扩容的实例 JIT 还没热），10 个请求全失败又立刻回到打开状态。我们把半开探测改成渐进放量：半开阶段按 10% → 30% → 60% → 100% 四档放行，每档观察 5 秒。

3. 熔断粒度选错，一个接口拖垮整台机器

按服务级熔断是最常见的错误。商品服务的"详情查询"挂了，不代表"库存扣减"也挂了。我们最终按 method + 关键参数维度 建立熔断器，比如 item.get:skuType=normal 与 item.get:skuType=presale 分开统计，故障隔离粒度从"整个商品服务不可用"缩小到"预售详情不可用"。

四、降级要有"业务可接受"的兜底，而不是返回 null

熔断打开后返回什么，比什么时候打开更重要。返回 null 会把异常抛给上游，等于没降级。我们给每个核心读接口定义了三级兜底：

关键点是 L1 本地缓存必须带 TTL 且容量受限。我们最初用无过期的本地 Map 做兜底，结果下游恢复后上游还在返回半小时前的价格，引发了一次客诉。

LoadingCache<String, ItemView> fallback = Caffeine.newBuilder()
    .maximumSize(10_000)
    .expireAfterWrite(Duration.ofSeconds(5))
    .recordStats()
    .build(key -> staticItemRepository.getOrDefault(key));

五、限流要放在最外层，并且区分"保护自己"和"保护下游"

我们后来把限流拆成两层：

• 入口限流（网关层）：按租户 + 接口维度做令牌桶，目的是保护自己不被单个调用方打满；
• 出口限流（客户端层）：每个下游依赖一个并发信号量，目的是保护下游，同时天然形成"快速失败"——信号量拿不到直接降级，不占用线程。

出口限流用信号量而不是令牌桶，是因为并发数比 QPS 更能反映对下游的压力。一个 200ms 的接口，QPS 500 和并发 100 是同一件事，但下游扩容时并发模型更稳定。

Semaphore bulkhead = new Semaphore(50);   // 单实例对下游的最大并发

if (!bulkhead.tryAcquire(10, TimeUnit.MILLISECONDS)) {
    return fallbackSupplier.get();        // 直接降级，不排队
}
try {
    return remote.call();
} finally {
    bulkhead.release();
}

注意 tryAcquire 的等待时间必须很短（10ms 量级）。排队等待会把"下游慢"转换成"自己线程堆积"，这正是我们第一次事故的成因。

六、可观测性：没有指标的自愈等于赌博

熔断、降级、限流都是自动决策，自动决策的前提是可观测。我们要求的三个最小指标集：

1. 每个依赖的 RT 分位 + 错误率 + 熔断状态，按 method 维度下钻；

2. 降级命中率：降级不是无感操作，必须能看到"这个接口今天有 12% 的请求走了兜底"；

3. 线程池/信号量饱和度：排队长度、活跃线程数、拒绝数。

告警规则里最容易漏的一条是降级持续时长。单次降级是正常保护，连续降级 5 分钟以上意味着下游真的挂了，必须升级为 P1。

七、复盘结论：稳定性是设计出来的，不是配置出来的

回到那次雪崩，真正的修复不是把超时从 30 秒改成 200ms，而是建立了四条工程约束：

• 超时从入口 SLA 反推，沿链路递减，禁止"每层都设 30 秒"；
• 同步链路最多重试 1 次，重试与熔断共享预算；
• 熔断按 method + 关键参数维度建立，带最小样本数和渐进半开；
• 降级必须给出业务可接受的兜底数据，且本地缓存有 TTL 和容量上限。

这套东西落地后，同样的慢查询再次出现时，故障半径被限制在"预售商品详情返回 5 秒前的缓存"，订单主链路完全无感。微服务的稳定性从来不是靠某个组件的开关，而是靠超时、重试、熔断、限流、降级这五件事在同一个预算模型下协同工作。