问事件驱动架构-最佳实践

EN

请注意：“微服务体系结构”并不是通常所描述的灵丹妙药。它们在应该是顺序的情况下引入异步性，而在大多数设计中实际上是顺序的。它们还带来相当大的复杂性，往往没有好处。我认为没有令人信服的理由在这个场景中使用微服务。

为了回答你的第一个问题，这两个选项对我来说都是正确的，因为你是在假设库存的状态。我会选择在……

order-service - place an order event             
inventory-service - consume event and deduct if enough stock
inventory-service - place transaction event or abort event
order-service - consume event and do or not the order transaction depending on the event

关于你的第二个问题，让我把你转到关于这个的另一个帖子。关键是卡夫卡已经为你这样做了，但它取决于你的用例是否应该使用它。

在一个真正的仓库管理系统中，订单的处理比您描述的要复杂得多，但我知道您只是想玩一个简单的场景。

把我的答案完全限制在你提到的系统上，我会这样做：

当客户在前端下订单时，可以向PlaceOrder发送一个命令到订单管理系统，该系统只需将订单记录到其数据库中的“挂起”状态，并广播一个OrderPlaced事件。

在这种状态下，订单还不会出现在履行系统中，因为订单库存没有保留，付款没有保证，发货也没有创建等等。客户仍然可以取消订单。

库存管理系统将侦听OrderPlaced事件，并通过试图为订单找到最佳库存来响应这些事件。这比现实生活中听起来要复杂得多。零售商可能在全国不同的地方拥有多个设施。您希望库存最接近最终目的地，以降低交付成本。如果订单是国际的，您需要从离机场最近的设施中获得库存。如果您在主要位置有库存，您应该更喜欢在库存中，等等。因此，该算法比仅在SKU计数中扣除一个要复杂得多。

另一个可以干预的系统是负责客户通知的系统，因为您希望您的客户收到订单被接受的通知。

一旦库存管理完成了将库存与订单捆绑在一起，它就可以广播事件InventoryTied，其他系统可以收听该事件。在这一点上，我认为实现系统将需要干预，但由于它不是在您的例子中，我将把它排除在答案之外。您可以使用此事件来决定更改订单中的订单状态，可能会使此时无法取消，例如更改为“托运”状态。

然而，你必须知道这是对现实生活中发生的事情的过度简化。在现实生活中，对我来说，订单管理系统作为一个状态机工作。这就是为什么微服务往往很适合这个领域，因为每个阶段都有些复杂，并且需要许多服务的编排才能最终完成订单。

关于你关于存储事件的第二个问题。假设你谈论的是卡夫卡已经提供的东西以外的东西，除非我正在写一个事件源系统，否则我不会这么做，但是没有必要有一个完全的功能事件驱动的架构。你可以简单地对发生的事件做出反应。如果你以幂等的方式构建你的服务，你仍然有一些空间可以重播例如失败的事件。