是否应该使用数据库主键来跨微服务识别实体？

Question

鉴于我有两个微服务：服务 A 和服务 B。

服务 A 拥有完整的客户数据，而服务 B 需要这些数据的一小部分（它通过一些批量加载从服务 A 获取）。

这两种服务都将客户存储在自己的数据库中。

如果然后服务 B 需要与服务 A 交互以获取额外的数据（例如 GET /customers/{id}），它显然需要一个在两个服务之间共享的唯一标识符。

因为 id 是 GUID，所以我可以在服务 B 中创建记录时简单地使用来自服务 A 的 PK。所以两个 PK 匹配。

然而，这听起来非常脆弱。一种选择是将“外部 ID”（或“源 ID”）存储为服务 B 中的一个单独字段，并使用它与服务 A 进行交互。这可能是一个字符串，因为有一天它可能不是 GUID。

是否有围绕此的“最佳实践”？

更新

所以我做了更多的研究，发现了一些相关的讨论：

您应该在 REST API URL 中公开主键吗？

在 REST API 中向客户端公开数据库 ID 是一种不好的做法吗？

作为主键的 Slug

结论

我认为我试图在服务 A 和 B 中保持客户的两个主键相同的想法是错误的。这是因为：

1. 显然，PK 是特定于服务实现的，因此它们可能完全不兼容，例如 UUID 与自动递增的 INT。
2. 即使您可以保证兼容性，尽管这两个实体都恰好被称为“客户”，但它们实际上是两个（可能非常不同）的概念，并且服务 A 和服务 B 都“拥有”自己的“客户”记录。您可能想要做的是在这些服务之间同步一些客户数据。

所以我现在认为任何一个服务都可以通过自己的唯一 ID（在我的例子中是 PK GUID）公开客户数据，如果一个服务需要从另一个服务获取额外的客户数据，它必须存储另一个服务标识符/密钥并使用它。所以基本上回到我的“外部 ID”或“源 ID”的想法，但也许更具体为“服务 B id”。

Answer 1

我认为这有点取决于数据源和您的设计。但是，我要避免共享的一件事是主键，它是外部服务的 GUID 或自动增量整数。这些是您的服务的内部详细信息，而不是其他服务应该依赖的内容。

我宁愿有一个外部 ID，它可以被其他服务甚至整个业务更好地理解。它可以是唯一的客户编号、订单编号或保单编号，而不是id. 您也可以将它们视为“企业 ID”。还需要记住的一件事是，外部 ID 也可能会暴露给最终用户。因此，它是在整个组织和服务中识别“实体”的普遍方法，无论您是否有事件驱动设计或者您的服务是否通过 API 进行通信。我只会将数据库 ID 公开给基础设施或存储库。除此之外，它只是一个企业/外部 ID。