microservices - 难以理解事件溯源微服务事件接收/通信

Question

我已经了解事件溯源、CQRS、DDD 和微服务有一段时间了，现在我想尝试并开始实施一些东西并试一试。

我一直在研究 CQRS 的技术方面，并且了解其中的 DDD 概念。写入端如何处理来自 UI 的命令并从中发布事件，以及读取端如何处理事件并在它们上创建投影。

我遇到的困难是从服务到服务（从写入到读取服务以及微服务之间）的通信和处理事件。

所以我想专注于 eventstore（这个：https ://eventstore.com/不那么含糊）。这就是我想要使用的，因为我知道它是事件溯源的完美选择，存储事件的简单性质意味着我也可以将它用于消息总线。

所以我的问题分为两个问题：

1. 在写入和读取之间，为了让读取端接收/获取从写入端创建的事件，我是否认为可以使用追赶订阅之类的东西来订阅流以接收写入的任何事件它还是我使用轮询之类的方法从给定点获取事件？

2. 在微服务之间，我的日子更加艰难......所以在查看 CQRS 教程/讲座等时......他们似乎总是在谈论一个从 UI/API 接收命令的隔离服务的示例。这可以。我了解写入端将附加一个 API，以便用户可以与其交互以执行命令。例如创建一个客户。但是...假设我有两个微服务，例如订单微服务和运输微服务，运输微服务如何获取从订单微服务发布的事件。具体来说，这些客户事件如何转化为运输服务的命令。

所以让我们举一个简单的例子： - 从订单的 API 创建的命令来下订单。- 将 OrderPlacedEvent 发布到事件存储。运输服务如何监听并对此做出反应是它需要然后 DispatchOrder 并依次创建一个 OrderDispatchedEvent。

运输微服务的写入端是否需要轮询或还需要订阅订单流？如果是这样，如何使用 DDD 方法将事件转换为命令？

标签： microservicesdomain-driven-designcqrsevent-sourcingeventstoredb

Answer 1

诸如追赶订阅之类的东西可用于订阅流以接收写入其中的任何事件

是的，使用追赶订阅是正确的做法。您还需要将订阅的流位置保持在某个地方。

在这里您可以找到一些有效的示例代码。我没有发布整个片段，因为它太长了。

投影服务启动流程为：

• 加载检查点（第一次是流开始）
• 从该检查点订阅流

运行时流程将是：

• 然后，订阅将在收到事件时调用您提供的函数。有一些管道要做，比如如果你订阅了$all，你需要过滤掉系统事件（在下一个版本的 Event Store 中会更容易）
• 投影事件
• 存储新的检查点

如果你让你的预测是幂等的，你可以不时存储检查点并节省一些 IO。

发货微服务如何获取订单微服务发布的事件

当您构建一个全新的系统并且您有一个小团队处理所有组件时，您可以创建快捷方式并从另一个服务订阅域事件，就像您对预测所做的那样。在集成上下文中（框之间），排序应该不重要，因此您可以使用持久订阅，因此您无需考虑检查点。活动商店将为您完成。

请注意，它在原始服务的域事件模式上引入了紧密耦合。您的上下文将具有合作关系，或者下游服务将是 Conformist。

当您继续使用您的系统时，您可能会决定适当地解耦这些上下文。因此，您为发布事件供其他人使用的服务引入了一个稳定的事件 API。您用于集成的同一订阅现在可以将域（内部）事件转换为集成（外部）事件。然后，消费上下文将使用稳定的 API，并且上游服务的域模型将可以自由地迭代其域模型，只要它们保持转换是最新的。

没有必要为下游上下文使用事件存储，他们也可以使用消息代理。由于它们的瞬态特性，集成事件通常不需要持久化。

我们正在 Event Store 举办有关 Event Sourcing 的网络研讨会系列，请查看我们的网站以按需访问以前的网络研讨会，您可能会感兴趣加入未来的网络研讨会。