面向微服务的架构中的外键约束

Question

给出以下两个微服务，产品和购物车，它们连接到事件总线。 每当创建，更新或删除产品时，都会发出事件，以便购物车微服务可以更新其产品数据副本。

现在，将如何实施一项业务要求，即不能删除仍在用户购物车中引用的产品。

到目前为止我的想法：

• 通过向购物车微服务添加其他依赖项，在产品微服务中实现该逻辑。我不喜欢这种解决方案，因为它增加了耦合并引入了循环依赖性。

是否有解决此问题的推荐方法或模式？

Answer 1

我将让购物车服务发布一个事件流，该事件流包括添加，删除和关闭购物车事件。产品服务可以直接订阅这些事件，并跟踪产品是否在购物车中。

由于事件在发布到被使用之间固有地存在延迟，因此，这当然会带来产品被删除后但在购物车服务收到事件之前被添加到购物车的机会；然后，购物车服务将发布购物车更改事件，该事件将引用已删除的商品。

要处理这种情况，我会：

• 强制在一定时间后将购物车关闭
在至少那个时期内将产品删除处理为待定。然后，删除事件是“我们打算删除该产品”事件，该事件表示购物车服务阻止其添加，但不影响当前购物车
• 自从待定产品删除和该商品的上次添加到购物车事件中的较晚时间起，直到购物车自动关闭时间过去后，删除操作才生效

这不能完全消除（例如，如果购物车服务关闭的时间长于自动关闭时间）服务之间的最终一致性，但可以大大降低这种可能性。因此，这留下了两个选择，这是企业必须决定的事情：

• 他们可以通过拥有服务（可以是产品，可以是购物车，可以是新服务，可以是产品和购物车的合并）消除最终的一致性。请注意，如果此服务关闭（或无法访问），它将阻止将商品添加到购物车中。

• 他们可以接受一个小小的风险，即如果购物车服务已关闭，客户将能够添加已删除的项目。在这种情况下，大概可以通过一种方式向客户发送道歉信息和某种补偿（例如，下次购物时获得X的优惠券）。

这些方法中的哪一个纯粹是业务决策；考虑到丢失该协调服务可能对企业造成的影响，我强烈怀疑几乎所有企业都将选择后者。