/tags/http-exchange/ Recent content in http-exchange on Hugo -- gohugo.io en Sat, 25 Apr 2026 05:00:00 +0800 /posts/shop-starter-http-client-integration-2026/ Sat, 25 Apr 2026 05:00:00 +0800 /posts/shop-starter-http-client-integration-2026/ 这是 shop-starter-http-client 的集成指南，按这套步骤通常可以跑起第一个出站客户端。 想了解 starter 内部如何设计：shop-starter-http-client 设计 想深入连接池/超时/HTTP2 的取舍：BFF 连接池与 HTTP/2 实战 前置条件 项 要求 JDK Java 21+（建议 Java 25） Spring Boot 3.5.x 依赖 已通过 shop-common-bom / shop-contracts-bom 管理共享版本 可观测性（推荐） micrometer-tracing-bridge-otel、micrometer-registry-prometheus 5 步集成 下面以 buyer-bff 调用 marketplace-service 列商品接口为例，从 0 走完。 graph LR A[Step 1加依赖] --> B[Step 2配 application.yml] B --> C[Step 3声明 @HttpExchange 接口] C --> D[Step 4注入 Support 建代理 Bean] D --> E[Step 5业务代码调用] Step 1：加依赖 services/buyer-bff/pom.xml： <dependency> <groupId>dev. /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 和业务上下文都能跨服务连续传播？