引言

大促压测到第 8 分钟，订单服务调用库存服务开始超时。运维的第一反应是调超时时间——把 Feign 的 readTimeout 从 3 秒调到 10 秒，结果更糟了：原本 3 秒失败的请求变成 10 秒失败，线程池被占满，订单服务自己也被上游超时拖垮，整条链路雪崩。调回来想加重试，又发现库存扣减接口不是幂等的——重试一次多扣一遍库存。

这三种痛——超时设多少、重试敢不敢做、调用链断了怎么定位——是微服务调用链治理的核心三问。本文用 OpenFeign + Sentinel + OpenTelemetry 三件套一次配齐，附完整配置和踩坑清单。

一、超时与重试：不是设个数就完事

1.1 超时双层模型

客户端发请求 ──connectTimeout(2s)──→ 建连成功 ──readTimeout(5s)──→ 收到响应
         │                                      │
         │ 连不上                                │ 连上了但响应慢
         ▼                                      ▼
    连接超时（网络不可达/队列满）         读取超时（下游处理慢/GC/锁等待）

1.2 完整配置

spring:
  cloud:
    openfeign:
      client:
        config:
          default:                    # 全局默认
            connect-timeout: 2000     # 连接超时 2s
            read-timeout: 5000        # 读取超时 5s
          stock-service:              # 针对特定服务覆盖
            read-timeout: 3000        # 库存服务要求更快
          payment-service:
            read-timeout: 10000       # 支付允许更慢（银行网关）
      circuitbreaker:                # 开启熔断器集成
        enabled: true
        group:
          enabled: true               # 按服务分组（同服务共享熔断器）

# Sentinel 配置
circuitbreaker:
  sentinel:
    enabled: true
    default-rule:                    # 默认熔断规则
      strategy: EXCEPTION_RATIO      # 异常比例策略
      threshold: 0.5                 # 失败率 > 50% 触发
      retry-on-timeout: true         # 超时计入失败
      min-request-count: 5           # 最少 5 个请求才统计
      stat-window: 1000              # 1 秒滑动窗口
      open-duration: 10000          # 熔断打开持续 10s

1.3 Retryer 配置：只对幂等接口开

@Configuration
public class FeignRetryConfig {

    /**
     * 重试器：最多 3 次，初始间隔 100ms，最大间隔 1s，指数退避
     * 注意：Feign 默认的 Retryer.NEVER_RETRY 不重试
     */
    @Bean
    public Retryer feignRetryer() {
        return new Retryer.Default(100, 1000, 3);
    }
}

/**
 * 幂等标记注解：只有标注了 @Idempotent 的 Feign 接口才允许重试
 */
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface Idempotent {
}

@FeignClient(name = "stock-service", fallback = StockClientFallback.class)
public interface StockClient {

    /** 查询接口：天然幂等，重试安全 */
    @Idempotent
    @GetMapping("/stock/{skuId}")
    StockVO getStock(@PathVariable Long skuId);

    /** 扣减接口：非幂等（除非有幂等键），默认不重试 */
    @PostMapping("/stock/deduct")
    R deduct(@RequestBody DeductReq req);
}

1.4 超时与重试的四个坑

二、熔断降级：Sentinel + Feign

2.1 为什么需要熔断

正常：调用方 → 库存服务（正常响应 50ms）
异常：调用方 → 库存服务（响应 5s，因为 DB 慢查询）
   ↓ 调用方线程池被慢请求占满
   ↓ 调用方自己也不可用了
   ↓ 整条链路雪崩

熔断介入：
   异常 → 失败率 > 50% → 熔断器打开（10s 内快速失败，不打下游）
   → 10s 后半开试探 → 成功率恢复 → 关闭熔断
   → 雪崩被阻断在"库存服务"这一跳

2.2 Sentinel 集成 Feign

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
</dependency>

feign:
  sentinel:
    enabled: true              # 开启 Sentinel 对 Feign 的适配

spring:
  cloud:
    sentinel:
      transport:
        dashboard: sentinel-dashboard:8080   # 控制台地址
        port: 8719                             # 客户端与控制台通信端口
      eager: true                              # 饥饿加载（启动即注册资源）

/**
 * Fallback 类：熔断/降级时的兜底逻辑
 * 注意：必须实现 Feign 接口的所有方法，每个方法提供降级返回
 */
@Component
public class StockClientFallback implements StockClient {

    @Override
    public StockVO getStock(Long skuId) {
        // 查询降级：返回缓存/默认值
        return cacheService.getStockFromCache(skuId);
    }

    @Override
    public R deduct(DeductReq req) {
        // 写操作降级：不能假成功！走异步补偿
        mqSender.send(new DeductCompensation(req));  // 发 MQ 延迟重试
        return R.fail("STOCK_DEGRADE", "库存服务暂不可用，已加入补偿队列");
    }
}

2.3 熔断规则配置

@Configuration
public class SentinelRuleConfig {

    @PostConstruct
    public void initRules() {
        // 库存服务熔断规则
        DegradeRule stockRule = new DegradeRule("GET:stock-service:/stock/{skuId}")
                .setGrade(CircuitBreakerStrategy.ERROR_RATIO.getType())  // 异常比例
                .setCount(0.5)              // 阈值 50%
                .setTimeWindow(10)           // 熔断持续时间 10s
                .setMinRequestAmount(5)      // 最小请求数
                .setStatIntervalMs(1000);    // 统计窗口 1s

        // 支付服务熔断规则（更宽松，支付不允许轻易熔断）
        DegradeRule payRule = new DegradeRule("POST:payment-service:/pay")
                .setGrade(CircuitBreakerStrategy.ERROR_RATIO.getType())
                .setCount(0.8)              // 80% 才熔断
                .setTimeWindow(30)           // 熔断 30s
                .setMinRequestAmount(10);

        DegradeRuleManager.loadRules(List.of(stockRule, payRule));
    }
}

2.4 降级策略分层

最危险的降级错误：写接口假成功。扣库存失败返回"成功" → 订单创建成功 → 发货时发现没库存 → 资损。写操作的降级永远是"转入补偿"，不是"假装成功"。

三、调用链追踪：Feign 拦截器透传 TraceId

3.1 问题：Feign 调用链断在哪

用户请求 → 订单服务（traceId=abc123）
         → Feign 调库存服务（traceId 丢了！库存服务日志里没有 abc123）
         → 库存服务调用日志和订单日志对不上

Feign 默认不透传 traceId——HTTP 请求头里没有 traceparent 或 X-Trace-Id，下游服务拿不到上游的 traceId，链路在 Feign 这一跳断开。

3.2 Feign 拦截器：透传 TraceId

/**
 * Feign 请求拦截器：自动注入 traceId 到请求头
 * 配合 OpenTelemetry / Spring Cloud Sleuth 的 MDC 使用
 */
@Component
public class TraceIdFeignInterceptor implements RequestInterceptor {

    @Override
    public void apply(RequestTemplate template) {
        // 从 MDC（SLF4J 日志上下文）取当前 traceId
        String traceId = MDC.get("traceId");
        String spanId = MDC.get("spanId");

        if (StringUtils.isNotBlank(traceId)) {
            // W3C Trace Context 标准头（OpenTelemetry 推荐格式）
            template.header("traceparent", "00-" + traceId + "-" + spanId + "-01");
            // 兼容旧系统
            template.header("X-Trace-Id", traceId);
        }

        // 透传 baggage（业务上下文：租户ID、用户ID等）
        String tenantId = MDC.get("tenantId");
        if (tenantId != null) {
            template.header("X-Tenant-Id", tenantId);
        }
    }
}

3.3 下游服务：从请求头恢复 traceId 到 MDC

/**
 * 下游服务的 Filter：从请求头恢复 traceId 写入 MDC
 * 配合 logback 的 %X{traceId} 在日志中打印 traceId
 */
@Component
public class TraceIdFilter extends OncePerRequestFilter {

    @Override
    protected void doFilterInternal(HttpServletRequest req, HttpServletResponse resp,
                                    FilterChain chain) throws ServletException, IOException {
        String traceId = extractTraceId(req);  // traceparent 或 X-Trace-Id
        if (traceId == null) {
            traceId = UUID.randomUUID().toString().replace("-", "");  // 没有就生成
        }

        MDC.put("traceId", traceId);
        MDC.put("spanId", generateSpanId());
        resp.setHeader("X-Trace-Id", traceId);  // 响应头返回，前端可查

        try {
            chain.doFilter(req, resp);
        } finally {
            MDC.clear();   // 请求结束清理，防止线程池复用泄漏
        }
    }

    private String extractTraceId(HttpServletRequest req) {
        // 优先 W3C traceparent 格式
        String tp = req.getHeader("traceparent");
        if (tp != null && tp.startsWith("00-")) {
            return tp.split("-")[1];  // 00-{traceId}-{spanId}-01
        }
        return req.getHeader("X-Trace-Id");
    }
}

3.4 logback 配置：日志里打 traceId

<!-- logback-spring.xml -->
<pattern>
  %d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] [%X{traceId},%X{spanId}] %-5level %logger{36} - %msg%n
</pattern>
<!-- 日志输出示例：
  2025-09-12 14:23:01.234 [http-nio-8080-exec-1] [abc123def456,a1b2c3] INFO  StockController - 扣减库存 skuId=1001
-->

3.5 全链路追踪效果

用户请求 traceId=abc123
  → 订单服务日志：[abc123] 订单创建 userId=1
    → Feign 调库存服务（traceId 透传）
      → 库存服务日志：[abc123] 扣减库存 skuId=1001
        → 库存服务 Feign 调商品服务（traceId 继续透传）
          → 商品服务日志：[abc123] 查询商品 skuId=1001

在 Loki/ELK 里搜索 traceId=abc123 → 一次性拉出全链路日志
在 Jaeger/Tempo 里搜索 traceId=abc123 → 可视化调用树 + 各段耗时

3.6 OpenTelemetry 自动注入（免手写拦截器）

<!-- 引入 OpenTelemetry 后，Feign 拦截器可自动注入 traceId -->
<dependency>
    <groupId>io.opentelemetry.instrumentation</groupId>
    <artifactId>opentelemetry-spring-boot-starter</artifactId>
</dependency>

otel:
  exporter:
    otlp:
      endpoint: http://otel-collector:4317    # 发到 OTel Collector
  traces:
    exporter: otlp
  service:
    name: order-service                        # 服务名

OpenTelemetry 自动织入的覆盖范围：HTTP 客户端（Feign/RestTemplate）、Servlet Filter、JDBC、Kafka、Redis——不需要手写拦截器，自动透传 traceId。上面手写拦截器的方案是"理解原理"的版本，生产推荐直接用 OpenTelemetry 自动织入。

四、常见问题

4.1 超时设多少才合理？

口诀：上游超时 < 下游超时 < 下游实际处理时间。链路上每一跳的超时要比下一跳短——网关 3s < Feign 5s < 下游 DB 查询 8s。如果反了（网关 5s > Feign 3s），网关还没超时 Feign 就超时了，用户看到的是网关的 504 而不是 Feign 的超时信息，排障走弯路。整条链路的超时从外到内递增，每一层给内层留足时间。

4.2 重试和熔断冲突了怎么办？

重试是"同一个请求再试一次"，熔断是"别再打了"——两者必须配合：熔断器打开时不重试（快速失败），半开试探时只发一个请求。配置纪律：重试间隔用指数退避（100ms→200ms→400ms），重试次数 ≤ 3，且熔断器的统计窗口要把重试请求也计入失败率——否则重试放大了流量但熔断器不知道，雪崩依然发生。Sentinel + Feign 的组合默认满足这个纪律，但手写 Retryer 要自己确保。

4.3 Fallback 和 Retry 哪个先生效？

执行顺序：Feign 调用 → 失败 → Retryer 重试（最多 3 次）→ 全部失败 → Sentinel 熔断判断 → 熔断器已打开则直接走 Fallback。重试在熔断之前——每次重试的失败都喂给熔断器的统计窗口，失败率到 50% 后熔断器打开，后续请求直接走 Fallback 不再发 Feign 调用。所以重试是"单个请求的自救"，熔断是"全局的保护"，两层独立但数据打通。

4.4 Feign 拦截器的执行顺序怎么控制？

多个拦截器共存时用 @Order 控制顺序：TraceId 拦截器应该最先执行（保证后续拦截器也能拿到 traceId），日志拦截器最后执行（记录最终请求头）。Spring Cloud OpenFeign 默认按 Bean 注册顺序执行，不确定就显式加 @Order。典型顺序：TraceId → 鉴权 → 业务参数 → 日志记录。

4.5 熔断器打开了，半开探测失败了怎么办？

半开探测失败 → 熔断器重新打开 → 再等一个 open-duration 周期 → 再半开探测。熔断器不会卡在半开状态，探测失败会回到打开态。Sentinel 的半开探测是"放一个请求过去看结果"，如果那个请求正好命中下游的尾部延迟，探测失败是误判——可以配置半开探测的"最少成功数"（如连续 2 个成功才关闭），降低误判概率。

4.6 OpenTelemetry 和手写拦截器能共存吗？

能但不建议。OpenTelemetry 自动织入已经覆盖了 Feign 的 RequestInterceptor 链路，手写拦截器会和它重复注入 traceId（两个 traceparent 头，下游解析歧义）。推荐做法：引入 OpenTelemetry 后删掉手写拦截器，只在需要透传业务 baggage（如 tenantId）时补充自定义 interceptor，且只透传 OpenTelemetry 不管的字段。让专业的工具做专业的事。

五、总结

三层治理速查卡

┌─────────────────┬──────────────────────────────────────────────┐
│ 层次             │ 关键配置                                      │
├─────────────────┼──────────────────────────────────────────────┤
│ 超时重试         │ connectTimeout=2s, readTimeout=3~5s          │
│                 │ Retryer(100ms, 1s, 3) 只对幂等接口开          │
│                 │ 超时层级：网关 < Feign < 下游处理              │
│ 熔断降级         │ Sentinel: 失败率>50%, 熔断10s, 半开探测        │
│                 │ 查询→缓存, 写→MQ补偿, 核心交易→快速失败+告警    │
│ 链路追踪         │ Feign拦截器透传 traceparent                   │
│                 │ 下游 Filter 恢复 traceId → MDC               │
│                 │ OpenTelemetry 自动织入（生产推荐）             │
└─────────────────┴──────────────────────────────────────────────┘

一句话

微服务调用链治理的三道防线：超时设合理不是设长（上游超时必须短于下游，给下游留时间不给自己埋雷），重试只对幂等接口开（非幂等重试等于复制副作用），熔断是全局保护不是单个请求的自救（重试喂统计，50% 触发，Fallback 是兜底不是假成功）。链路追踪的穿线是 traceId——Feign 拦截器透传 traceparent 头，下游 Filter 恢复到 MDC，一个 ID 在 Loki/Jaeger 里拉出全链路日志和调用树。但最佳实践不是手写拦截器，而是引入 OpenTelemetry 让 HTTP/Feign/JDBC/Kafka 自动织入——把"看得见"交给工具，把"治理得了"留给规则。

给团队的建议

互动话题：你们的 Feign 超时设多少？重试敢不敢开？traceId 是手写拦截器还是 OpenTelemetry 自动织入？评论区聊聊。

参考资料

• Spring Cloud OpenFeign 官方文档
• Sentinel 官方文档（Feign 集成）
• OpenTelemetry Java Agent 文档
• W3C Trace Context 规范
• Feign Retryer 源码
• Spring Cloud Alibaba Sentinel 集成