微服务设计：订单与库存服务间产品名称获取方案选型

先明确核心矛盾：既要满足前端展示产品名称的需求，又要遵守微服务的域边界原则，同时兼顾性能与可用性。下面逐个分析现有方案，并给出更合理的替代方案：

现有方案的弊端分析 #

方案1：前端发起两次请求 #

前端先调用orders服务拿订单列表，再提取所有产品ID批量调用inventory服务拿名称。

• 问题：前端逻辑复杂度上升，多一次网络请求可能带来页面加载延迟；如果inventory服务故障，订单列表的产品名称直接无法展示，可用性受影响。

方案2：orders服务存储产品名称 #

在订单数据中冗余存储产品名称，通过消息机制同步inventory的产品名称变更。

• 问题：违反微服务的域边界原则——产品名称属于inventory服务的核心数据，orders服务不该存储不属于自身域的信息；同时需要维护消息同步的可靠性（比如消息丢失、重复消费、同步延迟），大幅增加系统复杂度。

更符合微服务设计的方案：BFF（前端后端）聚合层 #

在前端与微服务之间新增一层BFF服务，专门负责跨服务的数据聚合：

1. 前端仅向BFF发起一次请求，获取订单列表（含产品名称）
2. BFF内部先调用orders服务拿到订单数据
3. BFF提取所有订单中的产品ID，批量调用inventory服务获取对应的产品名称
4. BFF将订单数据与产品名称整合后，返回给前端

为什么这个方案更合适 #

• 简化前端逻辑：前端不用处理跨服务数据关联的细节，只需要处理单一请求的结果
• 坚守域边界：orders和inventory服务各自只维护自身域内的数据，职责清晰
• 性能与可控性更强：BFF可以做批量查询、结果缓存（比如缓存产品ID-名称映射，减少对inventory服务的重复调用），比前端分散请求更高效
• 容错性更好：如果inventory服务故障，BFF可以降级返回产品ID，或者用缓存的旧数据兜底，保证订单列表依然可用

额外优化建议 #

• 针对产品名称这类变更频率低的数据，在BFF层设置合理的缓存过期时间（比如1小时），进一步降低inventory服务的压力
• 为BFF的聚合逻辑添加超时、重试机制，提升服务稳定性

内容的提问来源于stack exchange，提问作者JᴀʏMᴇᴇ