/tags/backend-for-frontend/ Recent content in backend-for-frontend on Hugo -- gohugo.io en Thu, 02 Apr 2026 10:00:00 +0800 /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 -.