微服务体系结构中的读取模型

Question

我对微服务架构中的事件源有疑问。

假设每个服务将其事件存储在自己的事件存储中，如果投影需要来自多个服务的数据，我该如何重建读取模型？

例如，我们有UserService和InvoiceService。在发票服务模型中，我仅使用用户ID，但在读取模型中，我还需要用户名，以便于查询。

谢谢，我现在有这些选择：

1. 还将用户名存储在发票服务中。我认为不是很好，因为我的真实来源仍然应该是用户服务。
2. 创建（其余？）api以在重建读取模型的情况下从用户服务中获取用户名。

我错过了什么吗？有人知道更简单的解决方案吗？

Answer 1

用户可以拥有多个发票，并且从事件源使用唯一的用户名重播/重建模型是不理想的（或者至少从我的理解来看）。我比较喜欢的路线是a co-relation identifier。顾名思义，它将帮助您在作为给定业务任务/动作的一部分而发生的服务调用/事件源记录之间建立相互关系。在重新构建模型（无论是在仪表板中显示还是在执行模型/动作重播的逻辑）方面，有一些相互关联的内容很重要。通过快速搜索，我发现了a talk about关联ID。请继续阅读并详细了解它，看看这种方法是否可以解决您的业务问题。

Answer 2

假设每个服务都将自己的事件存储在自己的事件存储中，如果投影需要更多数据，我该如何重建读取模型多于一项服务？

我认为您错过了事件存储的概念。服务不应具有自己的事件存储。假设您正在通过服务发布事件，而其他一些服务将必须订阅事件流。您的事件存储区是所有服务的唯一真实来源。

这样，如果需要从多个流创建投影，则可以执行此操作。请查看this blog post。

现在，如果您不想在事件存储侧构建投影，该怎么办。假设您有一个新要求，要显示包含发票计数，总账单等的用户报告。然后，我将执行以下操作-

1. 订阅以侦听来自UserService（新订阅）的UserCreated，UserBasicInfoUpdated事件

2. 从InvoiceService订阅以侦听InvoiceGenerated事件（新订阅）]] >>

3. 建立新的读取模型

4. 然后将先前的订阅（如果有）合并到新的订阅中。这个很重要。因为您不应有多个订阅者参与同一事件。