代码之家 › 专栏 › 技术社区 › FBryant87

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

integration-patterns eventual-consistency cqrs microservices architecture

0

FBryant87 · 技术社区 · 5 年前

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

订单 最终一致 在确认出售后不久。

这种体系结构的优点是销售服务对它的需求量很大,因此使它尽可能轻量级是理想的。

任何进一步的交易都可以为该客户进行。这是因为他们能买多少东西等都有限制,还有其他的限制。它不能依赖Order服务在任何时候提供这些信息,因为处理订单时可能会有积压工作。

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

0 回复 | 直到 5 年前

1

2

Levi Ramsey 5 年前

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

2

1

Maxim Fateev 5 年前

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

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

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