一、背景
在微服务架构中，Feign 作为常用的服务间调用组件，开发者往往会通过设置超时和重试机制来增强系统的“稳定性”。
然而，如果参数配置不当，尤其在高并发场景下，超时与重试机制可能会放大流量，反而成为系统雪崩的导火索。
本文结合一次真实的线上故障，从问题现象、原因分析、到防御方案进行完整复盘。
二、事故过程
一次常规的服务优化中，开发人员为 Feign 客户端配置了较短的超时和默认重试机制：
feign:
client:
config:
default:
connectTimeout: 2000
readTimeout: 3000
retryer: feign.Retryer.Default
上线后，服务在高峰期出现请求大量堆积、响应时间激增、CPU 飙高的现象。
监控显示部分接口的调用量呈几何级增长，最终导致下游数据库连接耗尽，多个服务同时超时，触发级联故障。
三、根因分析
1. Feign 默认重试策略
Feign 默认使用 Retryer.Default，重试逻辑为：
- 最大尝试次数为 5；
- 重试间隔为 100ms，指数级退避；
- 仅在
IOException等网络异常时触发。
源码简化如下：
public class Retryer.Default implements Retryer {
private final int maxAttempts = 5;
private final long period = 100L;
private final long maxPeriod = 1000L;
}
若服务调用链为：
A → B → C
当 C 出现超时时，B 会重试 5 次，A 再重试 5 次。
最终单次请求可能触发 25 次下游调用，远超系统预期，导致雪崩。
2. 重试与超时叠加效应
当服务响应时间接近超时时间（例如 2~3 秒），重试次数叠加后，线程会持续阻塞。
在高并发场景下，线程池迅速被占满，连接池资源耗尽，新的请求无法调度，最终形成请求堆积与拒绝。
3. 缺乏幂等与熔断机制
业务接口未设计幂等性，重试导致重复写入与业务逻辑重复执行。
同时调用链缺乏熔断机制，异常流量未能被及时切断，从而放大影响范围。
四、改进方案
1. 禁止全局重试
除非接口天然幂等（如查询类接口），否则应显式关闭 Feign 默认重试机制：
feign:
client:
config:
default:
retryer: feign.Retryer.NEVER_RETRY
或自定义限制次数的重试器：
@Bean
public Retryer retryer() {
return new Retryer.Default(100, 1000, 2);
}
2. 合理设置超时
超时应根据下游实际响应时间确定，避免过短导致频繁重试，也避免过长导致线程长期占用：
feign:
client:
config:
default:
connectTimeout: 3000
readTimeout: 5000
3. 增加熔断与限流保护
在 Feign 调用外层集成 Resilience4j、Sentinel 等组件，提供熔断和限流能力：
@CircuitBreaker(name = \"orderService\", fallbackMethod = \"fallback\")
public String createOrder() {
return orderClient.create();
}
当异常比例或超时比例达到阈值时，自动拒绝新请求，防止雪崩扩大。
4. 设计幂等机制
对于可能重复调用的接口（如扣库存、扣款、发放奖励等），必须加入请求唯一标识：
@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 的重试是放大器，而非安全网。
若配置不当，轻易放大系统压力。 - 超时、重试、熔断应成体系设计。
超时防卡顿，重试防偶发失败，熔断防雪崩。 - 幂等性是分布式系统的底线保障。
不论任何框架，必须确保重复请求不会破坏业务一致性。
通过这次事故复盘，我们最终将全局重试关闭，并在关键链路上引入了限流与熔断机制。
此后系统稳定性明显提升，也避免了类似问题的再次发生。
