Microservices 微服务通信与设计决策

我在设计微服务以及它们应该如何相互通信方面遇到了一个难题。假设我正在构建一个标准的电子商务系统，用户可以在其中浏览目录、添加到购物车和结帐

最简单的方法是提供目录服务和订单服务。目录服务保存所有产品的主副本，而订单服务处理购物车和付款

这就引出了设计。我可以想出三种设计方法：

产品服务包含所有目录的主副本，每个产品的子集被推送到订单服务进行价格计算。购物车驻留在订单服务中。这允许服务松散耦合，并且设计是干净的。缺点是，如果服务之间存在任何网络问题，它们可能会失去同步。这可能导致客户支付错误的价格

另一种方法是将购物车置于产品服务中。价格是在用户向购物车添加商品时计算的。当用户希望下订单时，整个购物车被推送到订单服务进行处理和付款。这完全将目录与订单分离，不需要在两个服务之间同步产品。但缺点是用户界面在下订单时需要与2个服务进行通信。首先，它需要告诉目录服务将购物车推送到订单服务，然后查询订单服务的状态

最后一种选择是使用某种编排来管理工作流。这只是方法1的改进。在这个场景中，将有另一个服务位于订单和目录服务之上。所有产品都将进行版本控制，这项新服务将确保产品价格和详细信息在订单和目录服务之间保持同步。购物车仍将驻留在订单服务中。明显的缺点是复杂性，因为还有一个服务需要维护和调试

正如您可能已经注意到的，我试图避免服务之间的同步请求/响应通信。我倾向于#2，但不确定是否有更好的方法。只是想知道其他人是如何处理类似问题的？欢迎任何建议