微服务架构中的外键约束
Foreign key constraint in mirco-service-oriented architecture
给定以下两个微服务，产品和购物车，它们连接到事件总线。
每当创建、更新或删除产品时，都会发出一个事件，以便购物车微服务可以更新其产品数据副本。
现在，如何实现业务需求 不能删除用户购物车中仍引用的任何产品。
到目前为止我的想法：
- 通过向购物车微服务添加额外的依赖项，在产品微服务中实现该逻辑。我不喜欢那个解决方案，因为它增加了耦合并引入了循环依赖。
有什么推荐的方法或模式来解决这个问题？
我会让购物车服务发布添加商品、删除商品、购物车关闭事件的事件流。产品服务可以直接订阅这些事件并跟踪产品是否在购物车中。
因为事件发布和消费之间存在固有的滞后，这当然会带来产品被删除后但购物车服务收到事件之前添加到购物车的机会；然后，购物车服务会发布引用已删除商品的购物车更改事件。
为了处理这种情况，我会：
- 强制在一定时间后关闭购物车
- 至少在该期间将产品删除视为未决。删除事件是一个“我们打算删除这个产品”事件，它向购物车服务发出信号以防止它被添加但不影响当前的购物车
- 在待处理产品删除和该项目的最后一个 added-to-cart 事件之后的购物车 auto-close 时间过去后，删除才会生效
这并不能完全消除（例如，如果购物车服务停机时间超过 auto-close 时间段）服务之间的最终一致性，但它会显着降低概率。所以这留下了两个选项，这是企业必须决定的事情：
他们可以通过服务（可以是产品，可以是购物车，可以是新服务，可以是产品和购物车的合并）作为协调点来消除最终一致性为了这。请注意，如果此服务已关闭（或无法访问），它将阻止将商品添加到购物车。
他们可以接受一个小风险，即如果购物车服务出现故障，客户将能够添加已删除的商品。在这种情况下，大概有一种方法可以向客户发送道歉信息和某种补偿（例如，下次购买 X 的代金券）。
应该采用这些方法中的哪一个纯粹是一个商业决策；考虑到失去协调服务可能对业务造成的影响，我强烈怀疑几乎所有企业都会更喜欢后者。
给定以下两个微服务，产品和购物车，它们连接到事件总线。 每当创建、更新或删除产品时，都会发出一个事件，以便购物车微服务可以更新其产品数据副本。
现在，如何实现业务需求 不能删除用户购物车中仍引用的任何产品。
到目前为止我的想法：
- 通过向购物车微服务添加额外的依赖项，在产品微服务中实现该逻辑。我不喜欢那个解决方案，因为它增加了耦合并引入了循环依赖。
有什么推荐的方法或模式来解决这个问题？
我会让购物车服务发布添加商品、删除商品、购物车关闭事件的事件流。产品服务可以直接订阅这些事件并跟踪产品是否在购物车中。
因为事件发布和消费之间存在固有的滞后，这当然会带来产品被删除后但购物车服务收到事件之前添加到购物车的机会；然后，购物车服务会发布引用已删除商品的购物车更改事件。
为了处理这种情况，我会：
- 强制在一定时间后关闭购物车
- 至少在该期间将产品删除视为未决。删除事件是一个“我们打算删除这个产品”事件，它向购物车服务发出信号以防止它被添加但不影响当前的购物车
- 在待处理产品删除和该项目的最后一个 added-to-cart 事件之后的购物车 auto-close 时间过去后，删除才会生效
这并不能完全消除（例如，如果购物车服务停机时间超过 auto-close 时间段）服务之间的最终一致性，但它会显着降低概率。所以这留下了两个选项，这是企业必须决定的事情：
他们可以通过服务（可以是产品，可以是购物车，可以是新服务，可以是产品和购物车的合并）作为协调点来消除最终一致性为了这。请注意，如果此服务已关闭（或无法访问），它将阻止将商品添加到购物车。
他们可以接受一个小风险，即如果购物车服务出现故障，客户将能够添加已删除的商品。在这种情况下，大概有一种方法可以向客户发送道歉信息和某种补偿（例如，下次购买 X 的代金券）。
应该采用这些方法中的哪一个纯粹是一个商业决策；考虑到失去协调服务可能对业务造成的影响，我强烈怀疑几乎所有企业都会更喜欢后者。