Microservice架构下涉及多服务调用的复杂流程最优实现方案咨询

你当前的基础架构如下：

/ -> MS1 -> DB1
UI - -> MS2 -> DB2
   \ -> MS3 -> DB3

针对涉及2个及以上微服务调用的复杂流程，两种方案的适配场景和优劣对比如下： #

方案1：前端直接完成所有跨服务调用 #

适用场景 #

• 仅涉及并行拉取多个微服务的展示类数据，无串行依赖调用、事务处理、数据拼接等复杂逻辑
• 对应的业务逻辑仅为单端使用，不需要在PC端、移动端等多端复用
• 单服务调用失败的降级逻辑非常简单，前端可以独立处理

缺陷 #

• 前端代码复杂度大幅提升，同类逻辑多端复用时需要重复开发
• 客户端网络请求次数激增，弱网环境下用户体验会明显下降
• 内部微服务的接口细节直接暴露给前端，后续微服务迭代改造需要同步协调前端修改，维护成本极高
• 涉及跨服务的写入操作时，前端无法保证数据一致性，很容易出现脏数据

方案2：新增中间聚合层（通常为BFF，Backend For Frontend，即面向前端的后端服务）处理复杂请求 #

适用场景 #

• 流程存在串行依赖调用（比如需要拿到MS1的返回结果才能调用MS2）、跨服务数据聚合、事务处理等复杂逻辑
• 相同的聚合逻辑需要给多端复用，或者后续会对外开放对应的业务接口
• 涉及跨服务的写入操作，需要保证数据的最终一致性/强一致性
• 希望隐藏内部微服务的接口细节，对外提供统一语义的业务接口

注意事项 #

• 聚合层仅负责请求编排、数据拼接、统一鉴权、容错降级这类通用逻辑，不要把微服务本身的领域业务逻辑下沉到聚合层，避免聚合层过重变成臃肿的单体服务
• 如果涉及跨服务的写入操作，需要配套对应的分布式事务方案：简单低敏感场景可以用本地消息表实现最终一致，高敏感场景可以选择Saga、TCC等事务模式
• 聚合层可以和现有API网关合并部署，也可以按照业务域拆分多个独立的聚合服务，避免出现单点性能瓶颈

选型建议 #

绝大多数业务复杂场景，优先选择新增聚合层的方案，长期维护成本更低，后续迭代效率更高；仅临时的、逻辑极其简单的多服务数据拉取场景，可以用前端直接调用的方案快速实现。

内容的提问来源于stack exchange，提问作者Jesús Cota