你在开发群里一定见过这样一幕线上服务一抖动A 系统说是 B 系统的问题B 系统说是 C 系统超时了C 系统说自己根本没收到请求。为了追一条调用链几个人拉群打电话确认“你调了我吗”“你传了个啥参数”“你重试了几次”。最后查出来是 A 系统 Feign 调用失败后无脑重试把下游 C 的数据库连接池打满了而 B 和 C 的兜底逻辑把异常吞掉只返回了一个“看起来很正常”的默认值。这不就是“荡秋千拉郑恺当垫脚石追踪局靠打电话作弊还是郑恺承担了所有”吗业务上的混乱还能靠综艺效果一笑了之放到分布式系统里就是真实的线上故障。重试机制把压力像荡秋千一样甩给下游链路追踪缺位导致只能靠人工打电话确认调用关系最后所有问题都堆积到兜底逻辑上兜底逻辑成了“承担所有”的最后防线。本文就从这三个痛点出发结合 Spring Boot OpenFeign Resilience4j Micrometer Tracing 的微服务场景讲清楚调用链追踪怎么做、重试为什么不能乱配、兜底逻辑到底该怎么写。全文包含完整可运行的代码示例、配置说明和排查思路适合正在负责微服务质量治理、接口稳定性或者被“重试风暴”折磨过的后端开发者。1. 背景分布式调用中的三个核心痛点1.1 重试是把双刃剑服务调用失败时最简单粗暴的恢复手段就是重试。一次不行两次两次不行三次。这在网络上确实能解决一部分临时抖动问题比如数据库连接池短暂打满、网络闪断、GC 停顿导致的超时。但重试有一个被很多人忽略的问题重试会把压力放大 N 倍。假设上游服务 A 在 1 秒内收到 100 个请求每个请求调用下游服务 B 时都会失败并重试 3 次。那么 B 在这 1 秒内实际承载的请求量就从 100 变成了 400。如果 A 部署了 5 个实例这个数字还要再乘以 5。B 本来只是轻微过载被这么一放大直接雪崩。这就是“荡秋千拉垫脚石”的分布式版本调用方为了自己不被甩出去拼命把压力往下游甩下游就成了那个垫脚石。1.2 没有追踪就只能靠“打电话”微服务架构下一个用户请求往往要经过网关、认证服务、订单服务、库存服务、支付服务等多个节点。任何一个节点出问题都需要回答一个基本问题这条请求到底走到了哪一步如果没有统一的 traceId 贯穿全链路排查问题就只能靠人工。A 系统看日志发现调了 BB 系统看日志发现自己也调了 C然后去问 C 系统“你有没有收到这笔请求”。这种“打电话式排查”不仅慢而且非常容易出错——你根本不知道对方查的那条日志和你手上的是不是同一次请求。链路追踪要解决的就是给每一次请求发一个全局唯一的身份证号并且让这个号码在服务间调用时自动传递下去。这样所有日志都可以按 traceId 拉出来还原完整的调用链路。1.3 兜底逻辑不能掩盖问题为了防止依赖服务异常导致主业务完全不可用我们通常会给远程调用设置 fallback 兜底。比如查库存失败默认返回一个库存充足查用户信息失败默认返回一个匿名用户。兜底逻辑的初衷是保护用户体验但很多团队把它用成了“藏问题”的工具。异常被 catch 住log 里没有原始堆栈调用方看到的是一个平平无奇的默认值。等用户反馈“为什么我下单成功了却一直不发贷”再回头查才发现库存服务已经挂了两个小时兜底逻辑在这两个小时里无声地返回了几万次“库存充足”。郑恺承担了所有的悲剧在于综艺里郑恺被拉去当垫脚石是可以被观众看见的而代码里的兜底逻辑如果没有任何监控和告警它扛下了所有问题团队却毫无感知。2. 环境准备与版本说明本文示例以 Spring Boot 3.x Spring Cloud 微服务环境为主涉及以下核心组件组件作用Spring Boot提供 Web 服务和自动装配能力OpenFeign声明式 HTTP 客户端用于服务间调用Resilience4j提供重试、熔断、限流、超时控制能力Micrometer Tracing接入调用链追踪自动生成和传递 traceIdLogback日志框架将 traceId 打印到日志中Zipkin可选链路追踪可视化展示平台版本说明Spring Boot 3.x 对应的 Spring Cloud 版本是 2022.0.x 及以后Spring Cloud OpenFeign 4.xMicrometer Tracing 1.x。Spring Boot 2.7.x 及以前的版本使用方式略有差异尤其是 Tracing 组件的坐标和 API 改动较大。实际项目中请以你自己的 Spring Boot 版本为准本文重点演示配置思路和代码写法不要把版本号直接照搬。项目整体结构建议如下trace-demo ├── gateway-service # 网关服务可选 ├── order-service # 订单服务作为调用方 ├── inventory-service # 库存服务作为被调用方 └── user-service # 用户服务作为被调用方为了演示方便本文用order-service调用inventory-service为例说明链路追踪、重试和兜底逻辑的完整落地方式。3. 核心概念原理解析在写代码之前需要先理解几个关键概念。这些概念直接决定后续代码的写法。3.1 traceId 与 spanId调用链追踪有两个核心概念traceId一次完整请求的全局唯一标识。从入口开始生成在整个调用链中保持不变。spanId一次服务调用或一个操作步骤的标识。同一 traceId 下可能有多个 spanId代表调用链中的不同节点。打个比方traceId 是一条地铁线路的编号spanId 是这条线路上的不同站点。排查问题时先按 traceId 找到整条线路再按 spanId 逐个站点分析耗时和错误。3.2 MDC 机制MDCMapped Diagnostic Context是日志框架提供的一种线程上下文容器。我们可以把 traceId 写入 MDC然后在日志输出格式中引用它。这样每行日志都会自动带上 traceId不用手动拼接。在 Spring Boot 3.x 中Micrometer Tracing 会自动把 traceId 和 spanId 写入 MDC字段名通常是traceId和spanId。我们需要做的只是在 logback 配置中把它们加进输出模式。!-- 文件路径src/main/resources/logback-spring.xml -- configuration appender nameCONSOLE classch.qos.logback.core.ConsoleAppender encoder pattern%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] [%X{traceId}] [%X{spanId}] %-5level %logger{36} - %msg%n/pattern /encoder /appender root levelINFO appender-ref refCONSOLE/ /root /configuration这里有一个容易被忽略的问题traceId 默认只在请求处理线程中存在。如果代码里使用Async开启了新线程或者使用线程池异步执行任务MDC 中的 traceId 不会自动传递到子线程需要在代码中手动处理。3.3 OpenFeign 的重试机制OpenFeign 本身的 Java 接口Retryer提供了重试能力但默认实现是Retryer.NEVER_RETRY也就是不重试。很多人以为配置了 OpenFeign 就自动拥有重试能力这是不对的。实际项目中常见的重试配置有两层OpenFeign 层通过自定义Retryer实现。Resilience4j 层通过Retry注解或RetryConfig实现。两层可以配置但要注意不要叠加重试次数。比如 OpenFeign 重试 3 次Resilience4j 又重试 3 次实际请求数就是 1 3 9 13 次远超预期。更推荐的方式是用 Resilience4j 统一控制重试策略OpenFeign 保持默认不重试。这样重试逻辑集中在一处方便配置和排查。3.4 全局兜底与局部兜底兜底逻辑按作用范围可以分为两类局部兜底在 Feign Client 的 fallback 中实现只影响当前这个接口的调用。全局兜底在RestControllerAdvice中统一处理异常影响整个服务的对外接口。两者不是替代关系。Feign fallback 负责处理远程调用失败全局异常处理器负责处理请求参数错误、业务异常等。真正的线上事故往往发生在fallback 返回了默认值但调用方代码没有意识到这个默认值代表“依赖服务异常”从而继续执行业务逻辑最终产生错误结果。4. 完整实战服务调用链路追踪 重试控制 兜底降级下面进入代码实战。示例以order-service调用inventory-service查询库存为场景完整覆盖三个能力全链路 traceId 自动传递。Resilience4j 配置合理的重试策略。Feign fallback 兜底降级。4.1 创建 Maven 项目并添加依赖order-service的pom.xml关键依赖如下!-- 文件路径order-service/pom.xml -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency !-- OpenFeign 服务调用 -- dependency groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-starter-openfeign/artifactId /dependency !-- Resilience4j 重试与熔断 -- dependency groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-starter-circuitbreaker-resilience4j/artifactId /dependency !-- 调用链追踪 -- dependency groupIdio.micrometer/groupId artifactIdmicrometer-tracing-bridge-brave/artifactId /dependency !-- Zipkin 上报可选本地调试可以先不接 -- dependency groupIdio.zipkin.reporter2/groupId artifactIdzipkin-reporter-brave/artifactId /dependencyinventory-service只需要 Web 依赖即可作为被调用方。为了演示 traceId 传递效果inventory-service的日志配置同样需要加上traceId字段。4.2 启动类开启 Feign 与 Tracing// 文件路径order-service/src/main/java/com/example/order/OrderServiceApplication.java package com.example.order; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.cloud.openfeign.EnableFeignClients; SpringBootApplication EnableFeignClients public class OrderServiceApplication { public static void main(String[] args) { SpringApplication.run(OrderServiceApplication.class, args); } }Micrometer Tracing 在 Spring Boot 3.x 中会自动装配不需要额外注解。如果你使用的是 Spring Boot 2.x 的 Sleuth才需要单独引入spring-cloud-starter-sleuth。4.3 配置文件重试策略与超时控制order-service的application.yml中加入 Resilience4j 配置# 文件路径order-service/src/main/resources/application.yml server: port: 8081 spring: application: name: order-service # Resilience4j 重试配置 resilience4j: retry: instances: inventoryRetry: maxAttempts: 3 waitDuration: 500ms retryExceptions: - java.io.IOException - feign.FeignException$ServiceUnavailable # 超时控制 timelimiter: instances: inventoryRetry: timeoutDuration: 3s这里有几个关键点需要说明maxAttempts最大尝试次数包含第一次调用。配置为 3 表示最多调 3 次。waitDuration重试间隔。这个值不能太小否则重试会在大压力下变成“加速崩溃”。retryExceptions指定哪些异常需要重试。这里只配置了 IOException 和 503 服务不可用业务异常不重试。特别注意不要配置Exception.class为 retryException。如果所有异常都重试遇到参数错误、数据校验失败这类不可恢复的问题时重试只会白白增加压力。inventory-service的application.yml保持简单# 文件路径inventory-service/src/main/resources/application.yml server: port: 8082 spring: application: name: inventory-service为了模拟不稳定场景可以在inventory-service的接口中人为加入随机失败逻辑方便验证重试和兜底效果。4.4 编写 Feign Clientorder-service中创建InventoryClient// 文件路径order-service/src/main/java/com/example/order/client/InventoryClient.java package com.example.order.client; import com.example.order.fallback.InventoryClientFallback; import org.springframework.cloud.openfeign.FeignClient; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestParam; FeignClient( name inventory-service, url ${inventory.service.url:http://localhost:8082}, fallbackFactory InventoryClientFallbackFactory.class ) public interface InventoryClient { GetMapping(/inventory/stock) Integer getStock(RequestParam(skuId) String skuId); }注意这里使用了fallbackFactory而不是fallback。两者的区别是fallback只能拿到默认返回值拿不到具体异常原因。fallbackFactory可以拿到导致降级的异常对象便于记录日志和区分失败类型。4.5 编写兜底降级逻辑// 文件路径order-service/src/main/java/com/example/order/client/InventoryClientFallbackFactory.java package com.example.order.client; import com.example.order.fallback.InventoryClientFallback; import org.slf4j.Logger; import org.slf4j.LoggerFactory; import org.springframework.cloud.openfeign.FallbackFactory; import org.springframework.stereotype.Component; Component public class InventoryClientFallbackFactory implements FallbackFactoryInventoryClient { private static final Logger log LoggerFactory.getLogger(InventoryClientFallbackFactory.class); Override public InventoryClient create(Throwable cause) { return new InventoryClient() { Override public Integer getStock(String skuId) { // 兜底日志必须记录原始异常不能只记一句话 log.error([兜底降级] 查询库存失败skuId{}异常信息{}, skuId, cause.getMessage(), cause); // 返回一个合理的默认值库存为0宁可少卖不能超卖 return 0; } }; } }这里有一个很多团队都会犯的错误fallback 里只打印cause.getMessage()不打印完整堆栈。如果异常发生在第三方 SDK 内部getMessage()往往只有一个模糊的总结无法定位具体问题。正确做法是把cause对象整个传入日志方法让日志记录完整堆栈。另外兜底返回的默认值一定要谨慎。库存场景返回 0 是相对安全的选择——最多是用户看到无货不会造成超卖。如果业务允许也可以返回一个业务默认对象但必须确保默认值不会触发后续的错误操作。4.6 调用方 Service 集成重试注解在order-service中创建一个 Service通过Retry注解把重试策略应用到 Feign 调用上// 文件路径order-service/src/main/java/com/example/order/service/OrderService.java package com.example.order.service; import com.example.order.client.InventoryClient; import io.github.resilience4j.retry.annotation.Retry; import org.slf4j.Logger; import org.slf4j.LoggerFactory; import org.springframework.stereotype.Service; Service public class OrderService { private static final Logger log LoggerFactory.getLogger(OrderService.class); private final InventoryClient inventoryClient; public OrderService(InventoryClient inventoryClient) { this.inventoryClient inventoryClient; } Retry(name inventoryRetry) public Integer queryStock(String skuId) { Integer stock inventoryClient.getStock(skuId); log.info([库存查询] skuId{}剩余库存{}, skuId, stock); return stock; } }Retry注解中的name必须对应application.yml中resilience4j.retry.instances下的配置项。如果名称对不上启动时不会报错但运行时 Resilience4j 找不到对应配置会使用默认策略重试次数和间隔可能不符合预期。4.7 编写 Controller// 文件路径order-service/src/main/java/com/example/order/controller/OrderController.java package com.example.order.controller; import com.example.order.service.OrderService; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestParam; import org.springframework.web.bind.annotation.RestController; RestController public class OrderController { private final OrderService orderService; public OrderController(OrderService orderService) { this.orderService orderService; } GetMapping(/order/stock) public String queryStock(RequestParam(skuId) String skuId) { Integer stock orderService.queryStock(skuId); return 商品 skuId 剩余库存 stock; } }4.8 inventory-service 模拟不稳定接口为了观察重试和兜底效果在inventory-service中模拟随机失败// 文件路径inventory-service/src/main/java/com/example/inventory/controller/InventoryController.java package com.example.inventory.controller; import org.slf4j.Logger; import org.slf4j.LoggerFactory; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestParam; import org.springframework.web.bind.annotation.RestController; import java.util.concurrent.ThreadLocalRandom; RestController public class InventoryController { private static final Logger log LoggerFactory.getLogger(InventoryController.class); GetMapping(/inventory/stock) public Integer getStock(RequestParam(skuId) String skuId) throws InterruptedException { // 模拟 50% 概率失败方便观察重试 if (ThreadLocalRandom.current().nextInt(100) 50) { log.warn([库存服务] 模拟查询超时skuId{}, skuId); Thread.sleep(2000); throw new RuntimeException(库存服务内部异常); } log.info([库存服务] 查询成功skuId{}stock100, skuId); return 100; } }这里模拟的方式是 50% 概率失败并且失败时让线程休眠 2 秒。这样可以观察两个效果Resilience4j 的重试是否按配置执行了 3 次。超时控制是否能在 3 秒内终止调用。4.9 运行与验证启动inventory-service端口 8082和order-service端口 8081然后多次请求curl http://localhost:8081/order/stock?skuIdSKU001正常情况下会交替出现两种结果第一种库存服务成功返回商品 SKU001 剩余库存100第二种库存服务连续失败重试 3 次后 fallback 生效返回商品 SKU001 剩余库存0此时打开order-service的控制台日志可以看到类似下面的输出2025-06-01 10:15:23.456 [http-nio-8081-exec-1] [traceIdabc123] [spanIddef456] INFO c.e.order.service.OrderService - [库存查询] skuIdSKU001剩余库存0 2025-06-01 10:15:23.457 [http-nio-8081-exec-1] [traceIdabc123] [spanIddef456] ERROR c.e.order.client.InventoryClientFallbackFactory - [兜底降级] 查询库存失败skuIdSKU001异常信息库存服务内部异常再打开inventory-service的控制台日志可以看到同一条 traceId 出现了 3 次调用记录2025-06-01 10:15:23.000 [http-nio-8082-exec-1] [traceIdabc123] [spanId999001] WARN c.e.inventory.controller.InventoryController - [库存服务] 模拟查询超时skuIdSKU001 2025-06-01 10:15:23.500 [http-nio-8082-exec-2] [traceIdabc123] [spanId999002] WARN c.e.inventory.controller.InventoryController - [库存服务] 模拟查询超时skuIdSKU001 2025-06-01 10:15:24.000 [http-nio-8082-exec-3] [traceIdabc123] [spanId999003] WARN c.e.inventory.controller.InventoryController - [库存服务] 模拟查询超时skuIdSKU001两个服务的日志通过traceIdabc123关联在一起。这就是全链路追踪的价值不需要打电话不需要问别人只要拿到一个 traceId整条调用链上的日志都能拉出来。4.10 观察 Zipkin 链路数据可选如果本地启动了 Zipkin 服务order-service和inventory-service都会上报请求链路数据。在 Zipkin Web 界面输入 traceId可以看到一个完整的调用链路图包含每个服务节点的调用顺序、耗时和状态。Zipkin 的启动方式这里不展开说明。常用的方式是通过 Docker 启动一个单机版docker run -d -p 9411:9411 openzipkin/zipkin然后在application.yml中加入spring: zipkin: base-url: http://localhost:9411 sleuth: sampling: probability: 1.0注意sampling.probability在测试环境可以配置为 1.0代表 100% 采样。生产环境建议调低到 0.1 或 0.01避免链路数据量过大造成存储压力。5. 常见问题与排查思路在实际项目中以下问题是出现频率最高的。5.1 traceId 一直没有出现在日志中问题现象常见原因解决思路配置了 MDC 模式但日志中 traceId 为空没有引入 Micrometer Tracing 依赖检查 pom.xml 是否引入了micrometer-tracing-bridge-brave只有入口服务有 traceId下游服务没有服务间调用没有经过自动透传组件确认 Feign 调用是否生效HTTP 客户端是否被代理异步线程中的日志没有 traceId子线程没有继承 MDC 上下文使用ThreadPoolTaskExecutor的TaskDecorator传递 MDC异步线程传递 MDC 是高频坑点。如果项目中使用了Async需要在线程池配置中添加 MDC 传递逻辑import org.slf4j.MDC; import org.springframework.core.task.TaskDecorator; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor; import java.util.Map; Configuration public class AsyncConfig { Bean(name customExecutor) public ThreadPoolTaskExecutor customExecutor() { ThreadPoolTaskExecutor executor new ThreadPoolTaskExecutor(); executor.setCorePoolSize(5); executor.setMaxPoolSize(10); executor.setQueueCapacity(100); executor.setTaskDecorator(new MdcTaskDecorator()); executor.initialize(); return executor; } /** * 将主线程的 MDC 上下文复制到异步线程中 */ static class MdcTaskDecorator implements TaskDecorator { Override public Runnable decorate(Runnable runnable) { MapString, String contextMap MDC.getCopyOfContextMap(); return () - { try { if (contextMap ! null) { MDC.setContextMap(contextMap); } runnable.run(); } finally { MDC.clear(); } }; } } }5.2 重试次数远超配置值问题现象常见原因解决思路配置 maxAttempts3但日志显示调用次数超过 3 次OpenFeign 和 Resilience4j 都在重试检查 Feign 是否自定义了 Retryer取消其一重试没有生效一次失败后直接返回异常类型不在 retryExceptions 列表中确认 Feign 抛出的异常是FeignException还是自定义异常重试导致下游压力飙升重试间隔过短没有退避策略增加waitDuration或配置指数退避Resilience4j 的retryExceptions是一个非常容易踩坑的地方。OpenFeign 调用失败时抛出的异常通常是FeignException$ServiceUnavailable对应 503或者FeignException$BadRequest对应 400并不是一个统一的FeignException父类。配置时要注意针对子类进行配置不要简单写feign.FeignException。5.3 fallback 兜底静默吞异常问题现象常见原因解决思路依赖服务挂了调用方日志只有一条 INFO兜底逻辑没有打印原始异常使用 fallbackFactory 获取 cause下游持续失败上游一直返回默认值fallback 没有和告警联动在 fallback 中增加指标埋点或告警通知默认值导致错误业务结果默认值选择不当盘点业务默认值安全性不安全时直接抛错这条需要重点强调fallback 兜底降级不是让你掩盖问题而是给你争取处理时间。在写下return 0或者return new User()之前先问自己三个问题这个默认值对用户是合理的吗运维团队能第一时间收到报警吗依赖服务恢复后数据一致性如何保证如果三个问题有一个回答不了fallback 写法就需要重新设计。5.4 Feign Resilience4j 版本不兼容Spring Cloud 的组件版本管理比较严格。Feign、Resilience4j、Micrometer Tracing 三者同时使用时经常出现启动报错或注解不生效的情况。遇到这种情况先检查 Spring Boot 与 Spring Cloud 的版本对应关系再检查spring-cloud-starter-circuitbreaker-resilience4j与spring-cloud-starter-openfeign是否来自同一套 BOM 管理。不建议在 Maven 中手动指定 Resilience4j 的io.github.resilience4j:resilience4j-spring-boot2或resilience4j-spring-boot3依赖因为 Spring Cloud 自带的 starter 已经完成整合重复引入容易出现 Bean 冲突。6. 最佳实践与工程建议6.1 重试策略设计规范重试不是越多越好也不是越快越好。推荐按以下原则设计超时必须优先于重试。先配置 TimeLimiter 超时时间再配置重试次数。否则一个重试周期可能长达几十秒调用方早就等崩溃了。重试要搭配退避策略。固定间隔适合低压力场景高并发场景推荐指数退避或随机退避避免重试请求在同一时刻轰炸下游。对非幂等接口不要盲目重试。下单、支付、转账这类接口重试可能导致重复扣款、重复下单。如果业务不能保证幂等宁可失败也不要重试。重试次数建议控制在 23 次。超过 3 次后继续重试对成功率提升有限反而会显著增加下游压力。6.2 链路追踪落地规范入口处必须生成 traceId。网关是所有请求的统一入口确保在网关层完成 traceId 生成而不是让每个服务各自生成。HTTP 调用必须自动透传 traceId。OpenFeign 和 RestTemplate 在 Spring Cloud 环境下会自动处理但使用原生 HttpClient 或者第三方 SDK 时需要手动从 MDC 取出 traceId 放到请求头中。日志中必须包含 traceId 和 spanId。没有 traceId 的日志在微服务环境下基本等于不可用日志。关键但耗时较长的业务节点可以手动添加 Baggage 字段把用户 ID、订单 ID 等业务标识写入追踪上下文方便检索。6.3 兜底降级设计规范fallback 必须记录原始异常堆栈。这是排查问题的基础不能省。fallback 返回值必须是业务安全的默认值。如果找不到安全默认值建议直接抛出一个业务异常让上层逻辑感知失败而不是悄悄返回一个错误结果。fallback 中要增加监控指标。可以使用 Micrometer 的 Counter 记录降级次数配置 Prometheus 告警当某个接口降级次数在短时间内超过阈值时立即通知值班人员。兜底逻辑中禁止执行耗时操作。fallback 本身就是因为下游已经不稳定才触发的如果 fallback 里再去调用数据库、Redis 或其他远程服务可能引发二次故障。6.4 指标埋点与告警建议在以下三个位置埋点// 在 fallback 中记录降级指标 import io.micrometer.core.instrument.MeterRegistry; Component public class FallbackMetrics { private final MeterRegistry meterRegistry; public FallbackMetrics(MeterRegistry meterRegistry) { this.meterRegistry meterRegistry; } public void recordFallback(String serviceName, String methodName) { meterRegistry.counter(service.fallback.total, service, serviceName, method, methodName).increment(); } }然后在InventoryClientFallbackFactory中调用指标记录方法private final FallbackMetrics fallbackMetrics; public InventoryClientFallbackFactory(FallbackMetrics fallbackMetrics) { this.fallbackMetrics fallbackMetrics; } Override public InventoryClient create(Throwable cause) { return new InventoryClient() { Override public Integer getStock(String skuId) { log.error([兜底降级] 查询库存失败skuId{}异常信息{}, skuId, cause.getMessage(), cause); fallbackMetrics.recordFallback(inventory-service, getStock); return 0; } }; }将service.fallback.total指标接入 Prometheus设置类似“5 分钟内降级次数超过 50 次”的告警规则。这样即便 fallback 逻辑扛下了所有问题监控系统也能第一时间通知到人。7. 写在最后的几点忠告回到文章开头那个场景如果你们的线上系统还在靠“打电话”追踪调用链如果重试次数还是随手填的 5 次 10 次如果兜底逻辑里只有一行return null那么下一次故障来临时你们还会陷入“谁承担了所有”的困境。技术上的解决思路其实并不复杂通过 traceId 还原完整调用链通过合理的重试控制避免“垫脚石”式的压力传导通过带着告警的 fallback 兜住意外失败。难的是把这些规范真正落到每一行代码、每一条配置里而不是等故障发生了再临阵磨枪。建议你先用本文的示例把链路追踪的日志效果跑出来然后从自己项目里找一个经常出问题的 Feign 调用按文中方案逐步接入重试策略和 fallback 监控。跑通一个接口之后再推广到其他接口。等整个链路都清晰了你会发现排查问题不再需要拉群打电话打开日志按 traceId 一搜问题出在哪一步、耗时多久、失败原因是什么一目了然。