/tags/baggage/ Recent content in baggage on Hugo -- gohugo.io en Mon, 13 Apr 2026 02:00:00 +0800 /posts/shared-http-client-tracing-2026/ Mon, 13 Apr 2026 02:00:00 +0800 /posts/shared-http-client-tracing-2026/ 本文代码背景来自开源项目 meirongdev/shop。 如果你看过上一篇 Java 项目怎么做 contract testing：一次 Spring Cloud Contract 实践，那篇文章讨论的是"接口兼容性边界"；这一篇讨论的是"调用链可观测性边界"。 Tracing 断链时，该换客户端还是换设计？ 在一个典型的 Spring Boot 3.5 微服务架构里，当 tracing 断链时，很多团队的第一反应是换一个更优雅的 HTTP 客户端抽象方式，比如用 @HttpExchange 替代手写 RestClient，或者抽一个公共客户端。但这往往不是问题的核心。 实际请求通常会经过： api-gateway -> buyer-bff / seller-bff -> order-service / profile-service / wallet-service ... 如果链路里某一跳自己 new 了一个 HTTP client，或者只会复制业务 header、不会传播 trace context，结果通常就是： Grafana Tempo 里看到 trace 断链，下游服务冒出新的 traceId 日志里虽然有 traceId，但 buyerId、sellerId、orderId 这种业务上下文又丢了 不同服务对 header 的处理方式各自为政，后面越改越乱 所以这篇文章不再把 @HttpExchange 当主角，而是先回答更本质的问题： 在 Spring Boot 3.5 微服务架构中，怎样设计一套稳定的 tracing 传播方案，让 trace context 和业务上下文都能跨服务连续传播？