当最终一致性是一项服务的问题，而不是其他服务的问题时？

Question

我有一个 销售 服务，它接受付款并在确认销售时引发事件。

我有一个 Order 服务，它使用此事件并记录作为交易的一部分购买的所有物品。因此，此购买信息在确认销售后不久最终一致。

这种架构的好处是销售服务对它有巨大的需求量，所以让它尽可能轻量是理想的。

问题是...当确认销售时，销售服务需要知道购买了什么，然后才能为该客户进行任何进一步的交易。这是因为他们可以购买多少物品等以及其他限制。它不能依赖订单服务随时提供此信息，因为处理订单可能会出现积压。

我可以通过让销售服务在确认销售后立即记录所有这些信息来解决这个问题，但随后我要在销售服务中引入更多的逻辑和处理。除了编写事件之外，它现在正在计算作为订单一部分购买的所有商品，并将其全部推送到其数据库中。

是否有解决此类问题的模式？我是否有效地被迫让销售服务也了解如何处理和存储订单？

Answer 1

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

Answer 2

您的选择是要么构建使用单个数据库的单体应用程序，要么拥抱最终一致性并在出现问题时依靠补偿。

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

使用队列和独立服务时，几乎不可能处理所有此类边缘情况。当采用像 temporal.io.

这样的集中式编排解决方案时，它就变成了一个易于处理的问题

免责声明：我是 Temporal 开源项目的技术负责人。