跨两个微服务的复杂输入验证：订单商品购买权限校验位置探讨

现有两个微服务：

• Purchasable Product Service：维护数千个在售商品，可根据用户所在地区、年龄返回其可购买的商品列表
• Order Service：负责处理完整的订单流程

用户下单时，系统需要校验该用户是否有权购买所选商品，请问这个校验逻辑应该部署在哪里？

方案1：在BFF层做前置校验 #

下单前，由BFF同步调用Purchasable Product Service验证商品对当前用户是否可见。因为商品状态始终可用，无需考虑最终一致性问题。

• 缺点：必须确保所有BFF和API网关都实现了这套校验逻辑，容易出现遗漏或逻辑不一致的情况
• 优点：逻辑简单直观，同步校验能快速将结果反馈给用户

方案2：基于Saga模式实现异步校验 #

由Order Service发起异步请求，调用Purchasable Product Service完成商品权限校验。

• 缺点：实现复杂度远高于方案1，需要处理异步回调、异常补偿等额外逻辑
• 优点：能有效过滤无效请求，避免不符合权限的请求进入Order Service的核心流程，起到保护作用

方案3：调整服务边界与职责 #

考虑将商品过滤逻辑迁移至Order Service，但这会引发新的矛盾：

• 如果Order Service承担商品过滤职责，BFF要展示商品列表时，要么重复实现过滤逻辑（这显然不合理，会导致代码冗余和维护成本上升），要么依赖Order Service提供商品列表查询能力，这会打破原有服务的职责划分，让Order Service承担非核心的查询工作。

内容的提问来源于stack exchange，提问作者LostInComputer