并行聚合两种方式对比

至于方式一。CompletableFuture

java // 注意必须指定线程池，否则默认 ForkJoinPool.commonPool 会被打满。ExecutorService pool = Executors.newFixedThreadPool;

CompletableFuture userService.getUserInfo,pool);

CompletableFuture.allOf.join;

UserInfoRespDTO user = futureUser.join;// 若失败则抛异常，需要 try/catch 并给出默认值。OrderInfoRespDTO order = futureOrder.join;

*关键注意事项*:

• *线程池不可复用过大，否则会抢占程序资源*;

方式二:响应式编程 Project Reactor java Mono) monoUser = webClient.get .uri .retrieve .bodyToMono;

Mono) monoOrder = webClient.get .uri .retrieve .bodyToMono;

return Mono.zip .map,tuple.getT2));

Reactor 基于非阻塞 I/O 和事件驱动模型，适用于需要极低延迟且所有链路都响应式的场景；否则混用会产生阻塞事件循环.

四、防踩坑教程

• `WebBff`: 专注嵌套对象完整返回;
"
• `AppBff`: 注重字段裁剪、省流量还有请求压缩;"
• `MiniProgramBff`: 针对小程序体积限制进行更严格的压缩策略;"
• `ProductDomainBff`: 按业务域拆分。可复用共享算法，但请确保同一个实体只在一个 Domain 内聚合;
" \
• `CrossDomainCall` 是反模式——禁止远程调用其他 Bff 实例，以免形成环形依赖;
" \*\*\*\*\*

---

五 落地约束

严格边界

不该做 原因 实现主要业务规则 会使得业务逻辑散布到多个地方。难以维护 写数据库事务 降低事务隔离级别 & 容易产生死锁 承载领域主要计算 占用了本该放在领域服务里的资源 做限流/全局路由 已经由网关承担，应保持职责单一 边界模糊很快让 Bff 演变成第二个臃肿的业务服务，从而破坏整体架构。

拆分方案

拆分方式	优势	劣势
按终端拆分	天然支持多终结差异，各自独立迭代；可针对不同终结调整缓存策略	重复实现相似业务逻辑，需要额外抽象共通模块
按业务域拆分	高复用性，同一实体只存在一个 Aggregation 点。更易管理事务边界	多终结差异处理不直观，需要手工映射

---

六 Trade‑off 探讨

导入导出走 Bff 吗？

至于对于超大文件，
1. 只负责接收上传请求并返回 taskId – 主要后置异步任务将文件写入 OSS；
2. 文件下载直接从 OSS 获取链接 – 大文件流量完全绕过 BfF。
好处是导入导出耗资源，而独立部署可以防止大型文件操作造成主要程序 OOM 崩溃。如果你们仍然想保留权限校验和参数收集，可以让上传入口经过 BfF。但**不要让它参与真正的大文件 IO 操作**。怎么说呢，

多一层真的必要吗？

• 额外应用层＝额外 DTO/V0 转换 → 成本 ↑；
• 部署运维成本 ↑。

说到判定标准，

• 多终结客户端且各自需求明显差异？✅，
• 页面零散且每页需要多个后台接口？✅，
• 移动设备极需省流量？✅，
• 页面需要跨多个微服务组装数据？✅，

若是“简单”场景。一层轻量适配即可满足需求，无需完整程序。

---

七

回到架构本质的观点是，能满足当前业务场景且团队能够持续维护的就是好架构。BfF 并非银弹，大厂经验也许跟我们规模与阶段不符。

说到先问自己，

1️⃣ 痛点到底是「多终结适配」还是「接口聚合」？2️⃣ 是否已有轻量级适配层足够？3️⃣ 成本投入是否值得？

盲目套上大厂经验往往陷入经验主义误区 —— 别忘了“最小可行”原则。老实说，