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

Question

鉴于我有两个微服务:服务 A 和服务 B。
服务 A 拥有完整的客户数据，而服务 B 需要这些数据的一小部分(它通过一些批量加载从服务 A 获取)。
这两种服务都将客户存储在自己的数据库中。
如果然后服务 B 需要与服务 A 交互以获取额外的数据(例如 GET/customers/{id})，它显然需要一个在两个服务之间共享的唯一标识符。
因为 id 是 GUID，所以我可以在服务 B 中创建记录时简单地使用来自服务 A 的 PK。所以两个 PK 匹配。
然而，这听起来非常脆弱。一种选择是将“外部 ID”(或“源 ID”)存储为服务 B 中的一个单独字段，并使用它与服务 A 进行交互。这可能是一个字符串，因为有一天它可能不是 GUID。
是否有围绕此的“最佳实践”？
更新
所以我做了更多的研究，发现了一些相关的讨论:
Should you expose a primary key in REST API URLs?
Is it a bad practice to expose the database ID to the client in your REST API?
Slugs as Primary Keys
结论
我认为我试图在服务 A 和 B 中保持客户的两个主键相同的想法是错误的。这是因为:

显然，PK 是特定于服务实现的，因此它们可能完全不兼容，例如UUID 与自动递增的 INT。

即使您可以保证兼容性，尽管这两个实体都恰好被称为“客户”，但它们实际上是两个(可能非常不同)的概念，并且服务 A 和服务 B 都“拥有”自己的“客户”记录。您可能想要做的是在这些服务之间同步一些客户数据。

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

Answer 1

我认为这有点取决于数据源和您的设计。但是，我会避免共享的一件事是主键，它是外部服务的 GUID 或自动递增整数。这些是您的服务的内部细节，而不是其他服务应该依赖的内容。
我宁愿拥有一个更容易被其他服务甚至整个业务理解的外部 ID。它可以是唯一的客户编号、订单编号或保单编号，而不是 id .您也可以将它们视为“企业 ID”。还要记住的一件事是，外部 ID 也可以暴露给最终用户。因此，它是一种在整个组织和服务中识别“实体”的普遍方式，无论您是否拥有事件驱动设计或您的服务是否通过 API 进行通信。我只会将数据库 ID 公开给基础设施或存储库。除此之外，它只是一个业务/外部 ID。