当最终的一致性是一个服务的问题,而不是其他服务的问题时?

如果订单服务依赖于来自销售服务的事件来做出决策,并且销售服务需要与订单服务所做的决策强烈一致,那么这强烈地表明它们实际上是同一个服务。如果它们碰巧分开部署,它们就会形成一个分布式的整体(很可能是两个世界中最糟糕的一个)。

您的选择要么是构建一个使用单个数据库的单片应用程序,要么是支持最终的一致性并在出现问题时依赖补偿。

请注意,在任何非玩具应用程序中,无论如何都必须支持补偿。例如,向客户承诺的最后一件商品在包装过程中损坏。这将要求取消或推迟订单。这种情况的处理与销售服务的处理没有太大区别,销售服务处理的是关于商品可用性的最新信息。

当使用队列和独立服务时,几乎不可能处理所有这样的边缘情况。当采用像这样的集中式编排解决方案时,这将成为一个容易处理的问题 temporal.io .