Feign 超时 + 重试引发雪崩：一次线上事故复盘

一、背景

在微服务架构中，Feign 作为常用的服务间调用组件，开发者往往会通过设置超时和重试机制来增强系统的"稳定性"。

然而，如果参数配置不当，尤其在高并发场景下，超时与重试机制可能会放大流量，反而成为系统雪崩的导火索。

本文结合一次真实的线上故障，从问题现象、原因分析、到防御方案进行完整复盘。

二、事故过程

一次常规的服务优化中，开发人员为 Feign 客户端配置了较短的超时和默认重试机制：

yaml 复制代码

feign:
  client:
    config:
      default:
        connectTimeout: 2000
        readTimeout: 3000
        retryer: feign.Retryer.Default

上线后，服务在高峰期出现请求大量堆积、响应时间激增、CPU 飙高的现象。

监控显示部分接口的调用量呈几何级增长，最终导致下游数据库连接耗尽，多个服务同时超时，触发级联故障。

三、根因分析

1. Feign 默认重试策略

Feign 默认使用 Retryer.Default，重试逻辑为：

最大尝试次数为 5；
重试间隔为 100ms，指数级退避；
仅在 IOException 等网络异常时触发。

源码简化如下：

java 复制代码

public class Retryer.Default implements Retryer {
    private final int maxAttempts = 5;
    private final long period = 100L;
    private final long maxPeriod = 1000L;
}

若服务调用链为：

css 复制代码

A → B → C

当 C 出现超时时，B 会重试 5 次，A 再重试 5 次。

最终单次请求可能触发 25 次下游调用，远超系统预期，导致雪崩。

2. 重试与超时叠加效应

当服务响应时间接近超时时间（例如 2~3 秒），重试次数叠加后，线程会持续阻塞。

在高并发场景下，线程池迅速被占满，连接池资源耗尽，新的请求无法调度，最终形成请求堆积与拒绝。

3. 缺乏幂等与熔断机制

业务接口未设计幂等性，重试导致重复写入与业务逻辑重复执行。

同时调用链缺乏熔断机制，异常流量未能被及时切断，从而放大影响范围。

四、改进方案

1. 禁止全局重试

除非接口天然幂等（如查询类接口），否则应显式关闭 Feign 默认重试机制：

yaml 复制代码

feign:
  client:
    config:
      default:
        retryer: feign.Retryer.NEVER_RETRY

或自定义限制次数的重试器：

typescript 复制代码

@Bean
public Retryer retryer() {
    return new Retryer.Default(100, 1000, 2);
}

2. 合理设置超时

超时应根据下游实际响应时间确定，避免过短导致频繁重试，也避免过长导致线程长期占用：

yaml 复制代码

feign:
  client:
    config:
      default:
        connectTimeout: 3000
        readTimeout: 5000

3. 增加熔断与限流保护

在 Feign 调用外层集成 Resilience4j、Sentinel 等组件，提供熔断和限流能力：

typescript 复制代码

@CircuitBreaker(name = "orderService", fallbackMethod = "fallback")
public String createOrder() {
    return orderClient.create();
}

当异常比例或超时比例达到阈值时，自动拒绝新请求，防止雪崩扩大。

4. 设计幂等机制

对于可能重复调用的接口（如扣库存、扣款、发放奖励等），必须加入请求唯一标识：

less 复制代码

@PostMapping("/deduct")
public Response deduct(@RequestHeader("requestId") String requestId) {
    if (redis.exists(requestId)) {
        return Response.ok("duplicate");
    }
    redis.set(requestId, "1", 60, TimeUnit.SECONDS);
    // 扣库存逻辑
}

保证即便发生重试，也不会重复执行。

5. 监控与告警

引入调用链监控与异常统计，如：

请求量突增监控；
调用超时与重试率统计；
线程池与连接池饱和度监控。

提前识别异常趋势，避免演变为全局性事故。

五、总结

问题	典型误区	推荐实践
重试策略	默认启用全局重试	明确关闭或自定义
超时配置	过短或过长	根据实际延迟合理设置
幂等性	无防重设计	使用唯一请求标识
熔断保护	无流控措施	引入 Resilience4j/Sentinel
监控体系	缺乏重试统计	接入调用链监控

六、经验结论

Feign 的重试是放大器，而非安全网。
若配置不当，轻易放大系统压力。
超时、重试、熔断应成体系设计。
超时防卡顿，重试防偶发失败，熔断防雪崩。
幂等性是分布式系统的底线保障。
不论任何框架，必须确保重复请求不会破坏业务一致性。

通过这次事故复盘，我们最终将全局重试关闭，并在关键链路上引入了限流与熔断机制。

此后系统稳定性明显提升，也避免了类似问题的再次发生。