/tags/bff/ Recent content in bff on Hugo -- gohugo.io en Sat, 25 Apr 2026 10:00:00 +0800 /posts/bff-http-client-pool-timeout-and-h2c-2026/ Sat, 25 Apr 2026 10:00:00 +0800 /posts/bff-http-client-pool-timeout-and-h2c-2026/ 配套阅读：shop-starter-http-client 设计 介绍完整的 starter 设计；本文专注于其中"连接配置"这一块的细节决定。 1. 问题场景 典型的 BFF 模式： graph LR BFF[buyer-bff] --> M[marketplace-service] BFF --> O[order-service] BFF --> L[loyalty-service] BFF --> P[promotion-service] BFF --> S[search-service] BFF -. 偶尔 .-> EXT[第三方支付 API] 每个下游的特征可能完全不同：marketplace 响应 50ms，搜索可能要 5s；payment 是外部 HTTPS API，order 是内部 cleartext；某个服务上了 HTTP/2，其他还是 HTTP/1.1。 三个绕不开的问题： 不同下游应该共用一个连接池，还是每个独立？ connectTimeout / readTimeout 怎么按服务定制？ 内部服务用 HTTP/2（h2c）值不值得开？怎么避坑？ 下面逐个讲清楚。 2. 连接池：共享还是隔离？ 我通常会先共享一个 java.net.http.HttpClient 实例。 2.1 为什么很多时候先不需要隔离 HttpClient 的连接复用天然按 origin 收敛 Oracle 的 HttpClient API 文档明确写了“一个 HttpClient 实例通常管理自己的连接池”；连接对同一 origin 复用、不同 origin 分开这一点，可以再配合 OpenJDK 源码 一起看。对 marketplace-service:80 和 order-service:80 的连接不会混在一个全局 bucket 里，所以“共享一个 HttpClient 实例”并不等于“所有下游抢同一组 socket”： /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-platform-bff-aggregation/ Thu, 02 Apr 2026 10:00:00 +0800 /posts/shop-platform-bff-aggregation/ 在上一篇中，我们看了 API Gateway 如何作为统一入口处理 JWT 校验和路由分发。请求经过 Gateway 后，到达的就是本文的主角——BFF（Backend for Frontend）聚合层。 📦 本文基于的完整项目源码：https://github.com/meirongdev/shop 上一篇：（二）API Gateway 架构 2026-04 实践更新 当前主线代码里，buyer-bff / seller-bff 都已经完成了 typed @HttpExchange 客户端改造；BuyerAggregationService / SellerAggregationService 不再直接持有一堆 raw RestClient 调用链，而是通过 HttpServiceProxyFactory 注入声明式客户端。本文下面与客户端装配相关的表述已按当前实现校正。 BFF 模式：为什么需要聚合层 在微服务架构中，前端页面往往需要从多个领域服务获取数据。如果没有 BFF，前端直接调用每个领域服务会面临： 前端 ←→ profile-service (获取用户档案) ←→ wallet-service (获取钱包余额) ←→ promotion-service (获取可用优惠) ←→ marketplace-service (获取推荐商品) ←→ loyalty-service (获取积分账户) 问题显而易见：前端需要知道每个服务的地址、认证方式、数据格式；任何服务变动都会影响前端代码；更重要的是，前端暴露了内部服务拓扑，安全和治理成本都会明显上升。 graph LR FE1["前端"] P["profile-service"] W["wallet-service"] PM["promotion-service"] M["marketplace-service"] L["loyalty-service"] FE1 -.-> P FE1 -.-> W FE1 -.-> PM FE1 -.