追溯更新微服务数据库的方法答案

【问题标题】：Approaches to update microservices databases retroactively追溯更新微服务数据库的方法
【发布时间】：2020-05-12 08:42:12
【问题描述】：

假设有两个微服务：A 和 B。每个都有自己的数据库。

A 有一个使用此方案的数据库：

{
    "id": "unique id for the user",
    "name": "the name of the user",
    "email": "the email of the user",
    "address": "the address of the user"
}

B 有这个方案：

{
    "userId": "unique id for the user",
    "email": "the email of the user"
}

每当我在 A 的数据库中插入一些内容时，都会调度一个事件，B 最终会得到它并保存从 A 的事件接收到的一些数据（当前是用户 ID 及其电子邮件）。 p>

一切都很好，B 的数据库有迄今为止注册的每个用户的用户 ID 和电子邮件。

现在，无论出于何种原因，我都需要 B 还拥有每个用户的地址，因此 B 的数据库架构将如下所示：

{
    "userId": "unique id for the user",
    "email": "the email of the user",
    "address": "the address of the user"
}

现在，B 的数据库中的每个用户都可以有一个地址字段，但现在它们将为空。

我的问题是：有哪些方法可以使 B 的数据库与 A 的数据库保持一致（即如何更新 B 的每个用户以也填充地址）？

我知道我可以更新我的活动并现在包含地址，但它只适用于新用户，旧用户的地址为空。我应该扫描整个数据库并为每个用户手动分派一个事件吗？

【问题讨论】：

您的用例是什么？

标签： domain-driven-design microservices eventual-consistency

【解决方案1】：

取决于您的系统以及数据是否持久。

如果您有事件并且该事件包含所有数据，请重播它们。

如果您没有事件（即没有事件源），请编写一个迁移服务，在部署应用程序之前（或期间）运行一次，这将为 B 中的每个条目从 A 获取数据并更新它。

或者只是等待，直到它在某个时候更新。但是对于这种情况，您总是需要某种“初始播种”（即，在开发 B 之前很久就退出 A 了）。在这种情况下没有什么不同，因为 B 不被认为是“单一事实来源”（即 A - B 只是 A 的投影），因此很容易丢弃 B 的所有数据并从 A 的数据中重新植入。

还请记住，您还可以在每次启动应用程序时更新数据。实际上这不是问题（假设数据不是太大），因为如果您在启动期间和应用程序开始处理事件之前进行更新，它将始终以最新状态结束，如果有一些迁移期间的事件，它们将被再次处理，在最坏的情况下，只需进行一些不必要的更新 - 假设您的事件是幂等的，这在这样的系统中将事件设计为幂等非常重要。

【讨论】：