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

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是一种不好的做法吗？

弹头作为主键

结论

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

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

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

Answer 1

好吧，如果你对价值对象有一个想法，商业ID将更适合设计。

DDD专注于业务，纯UUID/自动增量ID无法呈现它。

使用商业意义ID（UL ID），如客户ID，而不是简单的ID。

Answer 2

我认为这在一定程度上取决于数据源和您的设计。但是，我要避免共享的一件事是主键，它是指向外部服务的GUID或自动递增整数。这些是您服务的内部细节，而不是其他服务应该依赖的内容。

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