微服务架构中如何管理外键关系？答案

【问题标题】：How do you manage foreign key relation in Microservice architecture?微服务架构中如何管理外键关系？
【发布时间】：2020-07-16 21:13:12
【问题描述】：

我很欣赏一个直截了当的答案。

场景一：我需要展示产品信息。

产品服务（PS）：保存有关产品的信息定价服务（XS）：保存每个产品的定价信息聚合服务 (AS) ：结合产品信息和价格。

问题：“AS”调用“PS”（带有产品ID）以获取产品信息。现在，“AS”如何从“XS”中获取特定的产品价格？

这里的困惑是，PS 表是否有一个 DB 列，其 ID 与 XS 表中的相应价格对应？我们可以称它为外键吗？如果是这样，它是否会在两个服务之间引入紧密耦合？这违反了微服务的原则。

【问题讨论】：

【解决方案1】：

您可以将该字段称为“外键”，但只要您不对它施加任何约束，就可以了。

在我看来，这只是一个参考。它不会带来任何紧密耦合，它提供了一些绑定。就微服务架构而言，这完全没问题。如果您在可能的实现方面考虑更广泛一点，您可能会看到，例如，您可以使用完全不同的数据库（如关系数据库）进行定价服务，也许产品服务的文档数据库。在这种情况下，您所说的“外键”只是实际记录的参考会更清楚。

话虽如此，我可能仍然会质疑您的解决方案，例如

但无论如何，从我的角度来看，外键部分还不错。

【讨论】：

1) 我需要聚合器服务，因为我需要调用多个微服务并聚合结果（为了简单起见，我没有提到它们）。例如，我还需要产品评级表格评级服务。库存服务中的产品数量等 2) 单独的定价服务，因为价格取决于许多因素，如库存可用性、需求、交换价值、折扣等 3) 想了解为什么最好保留产品参考定价服务？
1- 可能还有很多其他原因我现在看不到聚合服务的合理性，但我仍然认为您的产品服务可以进行聚合。 3-根据我在上下文中看到的内容，您对产品有几个方面。像价格、评级等。在我看来，您将产品作为中心实体。这就是为什么我认为在其他服务中引用产品会更好。这实际上是一个写错的问题。我改变了我原来的帖子。
1) 同意，我们不需要聚合服务 3) 你可能是对的。但是，我仍然质疑我们可能面临的问题，如果我们在同一个表中有多个引用，而不是其他方式
“同一张表中的多个参考”，您可以在价格服务方面进行管理。实际上，根据要求，拥有多个参考甚至可以。也许您想保留价格随时间变化的历史。所以这应该是定价服务解决这个问题的一个问题，可能有一些字段来保持活跃状态，或者对参考表有限制以防止有多个参考等。