BFF复合服务设计模式Springy-Store-Microservices如何用Mono.zip聚合3个微服务为1个API【免费下载链接】Springy-Store-MicroservicesSpringy Store is a conceptual simple μServices-based project using the latest cutting-edge technologies, to demonstrate how the Store services are created to be a cloud-native and 12-factor app agnostic. Those μServices are developed based on Spring Boot Cloud framework that implements cloud-native intuitive, design patterns, and best practices.项目地址: https://gitcode.com/gh_mirrors/sp/Springy-Store-MicroservicesSpringy-Store-Microservices 是一个基于 Spring Boot 与 Spring Cloud 的云端原生微服务教学项目。它的 Store Service 就是一个标准的BFF 复合服务前端只需调用 1 个 API后端就用响应式编程的Mono.zip并发聚合 Product、Review、Recommendation 这 3 个微服务的数据为客户端返回一个完整的商品聚合视图。本文带你快速看懂这套 BFF 复合服务设计模式的完整实现。一、什么是 BFF 复合服务为什么需要它BFFBackend For Frontend服务于前端的后端是一种经典微服务设计模式前端每次打开商品详情页需要的不只是商品信息还有评论和推荐——这些数据分散在 3 个独立微服务里如果让前端分别调 3 个接口就要自己拼数据且网络请求翻 3 倍BFF 复合服务本项目的 Store Service充当聚合层对外 1 个 API对内并发扇出 3 个调用把结果组装成一个聚合对象ProductAggregate返回。 核心收益客户端少 2/3 请求、跨服务组装逻辑收敛到一处、聚合服务可独立演进。二、Store 复合服务的三层结构整个聚合逻辑分为清晰的三层位于 store-services/store-service/ 模块层文件职责API 层StoreEndpoint.java定义GET /store/api/v1/products/{id}接口业务层StoreServiceImpl.java用Mono.zip聚合并组装结果集成层StoreIntegration.javaWebClient 调用 3 个下游服务 事件发布ControllerStoreController.java只是薄薄一层转发真正的主角在业务层的getProduct方法StoreServiceImpl.java#L97-L117。三、核心一行 Mono.zip 如何聚合 3 个微服务聚合的关键代码长这样简化自 StoreServiceImpl.java#L98-L117return Mono.zip( values - createProductAggregate(...), // 组装聚合对象 integration.getProduct(productId, ...), // ① Product 服务Mono integration.getRecommendations(productId).collectList(), // ② RecommendationFlux→List integration.getReviews(productId).collectList()) // ③ ReviewFlux→ListMono.zip的工作方式并发扇出——3 个调用同时发出响应式非阻塞不会为等待慢服务而占用线程全部到齐才触发——4 个源含安全上下文都完成后第一个参数 Lambda 把Product 推荐列表 评论列表组装成ProductAggregate任一源报错即整体失败——例如 Product 服务返回 404整个聚合请求直接失败不会半成品。最终返回的聚合对象定义在 ProductAggregate.java商品基础信息 推荐摘要 评论摘要 各参与服务地址是一个标准的聚合根DTO。四、容错三件套超时、重试熔断、部分响应BFF 模式最大的风险是下游变慢拖垮入口本项目用 3 个手段化解1️⃣ 显式超时调用 Product 服务时附加.timeout(Duration.ofSeconds(2))StoreIntegration.java#L102超时秒数来自 store.yml 的app.product-service.timeoutSec配置。2️⃣ 重试 熔断Resilience4jgetProduct上标注Retry和CircuitBreaker注解参数在 store.yml#L94-L134重试最多 3 次尝试间隔 1 秒仅对 HTTP 500 触发熔断最近 5 次调用中 50% 失败即打开10 秒后进入半开探测NotFoundException等业务异常不计入故障率。3️⃣ 部分响应Partial ResponseReview 和 Recommendation 两个下游锦上添花调用失败时返回空列表而非抛错StoreIntegration.java#L137-L143.onErrorResume(error - empty()); // 出错就返回空让复合服务仍可返回部分响应⚖️ 对比记忆核心数据Product失败 → 整体失败附属数据Review/Recommendation失败 → 降级为空。这就是复合服务做取舍的核心思路。五、写操作事件驱动的扇出聚合是读多写少场景写路径完全不走同步调用Store Service 把创建/删除拆成 3 类Event通过 Spring Cloud Stream 发布到 RabbitMQ 的products、reviews、recommendations三个 TopicStoreIntegration.java#L222-L236由各微服务消费落库——读同步聚合、写异步事件是 12-Factor 云原生应用的标准做法。六、用 Zipkin 亲眼看到扇出调用启动整套系统后打开链路追踪 UI就能直观看到store → gateway → product / review / recommendation的完整调用拓扑图中store节点同时指向product、review、recommendation三个节点这正是Mono.zip并发聚合的可视化证据——一次 API 调用对应 3 条并行 Span。七、快速上手一键运行完整微服务全景环境需要 Maven、Java 15 与 Docker克隆仓库并启动git clone https://gitcode.com/gh_mirrors/sp/Springy-Store-Microservices cd Springy-Store-Microservices docker-compose -p ssm up -d然后请求复合 API 验证聚合效果需携带 OAuth2 Tokencurl -k https://localhost:8443/store/api/v1/products/1返回的 JSON 即包含商品、推荐、评论与服务地址的完整聚合视图。接口文档见 Swagger/swagger-ui.html。八、小结BFF 复合服务的核心要点清单 ✅要点本项目做法关键文件单一入口 APIGET /store/api/v1/products/{id}StoreEndpoint.java并发聚合Mono.zip扇出 3 服务StoreServiceImpl.java非阻塞调用LoadBalancedWebClientStoreServiceConfiguration.java#L89-L94故障隔离超时 重试 熔断 部分响应store.yml聚合结果ProductAggregate聚合根ProductAggregate.java想深入微服务云原生实践还可以关注 config/repo/ 下各服务的集中式配置以及 README.md 中完整的组件结构与测试脚本说明。【免费下载链接】Springy-Store-MicroservicesSpringy Store is a conceptual simple μServices-based project using the latest cutting-edge technologies, to demonstrate how the Store services are created to be a cloud-native and 12-factor app agnostic. Those μServices are developed based on Spring Boot Cloud framework that implements cloud-native intuitive, design patterns, and best practices.项目地址: https://gitcode.com/gh_mirrors/sp/Springy-Store-Microservices创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考