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

Question

假设有两个微服务：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 及其电子邮件）。

一切都很好，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 的每个用户以也填充地址）？

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

Answer 1

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

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

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

或者只是等待，直到它在某个时候更新。但是对于这种情况，您将始终需要某种 "initial seeding" （即 wenn A 在 B 开发之前很久就退出了）。在这种情况下没有什么不同，因为 B 不被视为 "single source of truth"（即 A - B 只是 A 的投影），很容易丢弃 B 的所有数据并从 A 的数据中重新播种。

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

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

Approaches to update microservices databases retroactively

domain-driven-design

microservices

eventual-consistency