/tags/restclient/ Recent content in restclient on Hugo -- gohugo.io en Fri, 24 Apr 2026 20:00:00 +0800 /posts/shop-starter-http-client/ Fri, 24 Apr 2026 20:00:00 +0800 /posts/shop-starter-http-client/ 代码背景来自开源项目 meirongdev/shop，Java 25 + Spring Boot 3.5 + Spring Cloud 微服务电商平台。 本文讲设计——starter 内部为什么这么写。如果你的目标是集成 starter，跟着步骤跑通第一个客户端，请直接看 shop-starter-http-client 集成指南。 配套阅读：Spring Boot 3.5 微服务 tracing 为什么会断链。 1. 背景 项目是典型的 BFF（Backend For Frontend）模式： graph LR C[Client] --> G[api-gateway] G --> BB[buyer-bff] G --> SB[seller-bff] BB --> M[marketplace] BB --> O[order] BB --> L[loyalty] BB --> P[promotion] SB --> M SB --> O 每个 BFF 都要向多个 domain service 发出站请求。shop-starter-http-client 把以下四件事提取到共享 starter，避免每个 BFF 重复实现： 关注点 由谁负责 身份传播 TracingHeaderInterceptor：Micrometer Baggage → 直接 HTTP header 错误语义保留 SharedDownstreamErrorHandler：4xx/5xx → DownstreamException（带原始状态码） 可观测性 DownstreamServiceObservationConvention：metric / span 加 downstream. /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 和业务上下文都能跨服务连续传播？