0

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

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

这种架构的好处是销售服务对其有巨大的需求量，因此使其尽可能轻量级是理想的。

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

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

有没有解决这些类型问题的模式？我是否实际上被迫让销售服务也了解如何处理和存储订单？

4

2 回答 2

2

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

于 2021-01-31T14:16:55.580 回答
1

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

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

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

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

于 2021-01-31T20:34:25.063 回答