不同微服务之间的连接表答案

【问题标题】：Join table between Different Microservices不同微服务之间的连接表
【发布时间】：2017-10-20 11:50:23
【问题描述】：

我仍在尝试理解微服务架构。

分离不同应用程序（包括数据库）的想法让我很兴奋。但是如果有两个微服务，我仍然感到困惑，例如产品和用户。 product 和 user 在其数据库中分别拥有表 product 和 user。根据微服务的最佳实践，我们只能从服务访问数据库。

问题是，假设我们有一个包含 user_id 列的产品表。我们想要搜索产品，它还返回创建产品的用户的名称。这就需要连接产品微服务中的产品表和用户微服务中的用户表。你怎么处理这个？

【问题讨论】：

标签： architecture microservices

【解决方案1】：

您必须调用每个微服务并手动加入或将相关用户 ID 传递给每个服务。

用户微服务：

SELECT * FROM Users WHERE some condition is true

获取用户列表，包括他们的ids。

产品微服务：

SELECT * FROM Products WHERE some condition is true AND userId IN (.........)

因此用户和产品仍然可以位于两个不同的数据库中，产品只需要具有 userId 的概念。

反过来也可以，ProductMicroserivce：

SELECT * FROM Products WHERE some condition is true

提取所有的UserId然后调用UserMicroservice：

SELECT * FROM Users WHERE some condition is true AND id IN (.........)

【讨论】：

谢谢，我会试试的：D
所以我们使用 api (Rest/http) 互相调用服务？
你们能帮我解决这个问题吗？ stackoverflow.com/questions/44083919/…
通常，无论哪个服务需要数据来调用这两个服务，UserService 和 ProductService 都不会互相调用。
哦，所以我们从前端调用这两个 api？

【解决方案2】：

虽然我认为按照 Jan 建议的方式进行操作并没有错，但我想补充一点，微服务应该添加到您的系统中的差异具有不同的性质。

上述服务隔离是我们在 SOA 世界中经常看到的，但很快它就变得过于复杂而没有提供太多价值。

如果您（我知道这只是一个示例）需要查询连接到产品的用户 - 为什么要拆分服务？您最终会为每个 db-entity 设计一个服务，而不是查看给定的需求，在我看来是有界上下文。

-拉尔斯

【讨论】：

完全同意这一点，为微服务而微服务毫无意义。
那么不同微服务的最佳示例是什么？如果用户和产品应该在同一个微服务中
是的，如果您的用例显示这两个实体同时被查询/更新很多，这表明它们应该存在于相同的有界上下文中，因此由相同的微服务处理。当然，您可能会发现 2 个实体的耦合非常松散，在这种情况下，您可能希望在 db 级别复制数据，以便 2 个或更多微服务可以访问这些实体，而无需相互进行大量交互。
@Lars 这是一篇旧帖子，我现在已经多次遇到同样的情况。我同意，如果服务边界不能得到适当的尊重，那么拆分成不同的服务是没有意义的。但是，在某些情况下，每项服务本身都具有相当大的复杂性和差异性。在这些情况下，将服务保持在一起，在单个 API 下紧密耦合会导致更多问题。弄清楚“跨服务”查询的最佳策略是什么会很棒（不知道该术语是否有效）。
@AbrarHossain wrt。在设计服务时，我喜欢坚持 Vaughn Vernon 的“实施领域驱动设计”一书中的规则：1）保持边界清晰分离； 2) 最小化聚合大小，最好每个聚合一个实体，除非最终的一致性不被业务要求接受。写。跨多个服务的查询，我建议按照 Praful 的回答描述的 CQRS 和物化视图。

【解决方案3】：

这种情况的最佳答案是 CQRS。维护用户和产品关系的物化视图。计量化视图可以是任何在读取时提供低延迟的东西，例如 NoSql DB。每当 Command 通过其微服务更新用户或产品时，应生成相应的事件并由管理此物化视图的其他服务捕获。该服务将用于获取您感兴趣的查询。永远记住，微服务架构相信最终一致性，这绝对不是一件坏事:)。希望这能回答你的问题。

【讨论】：