不同微服务之间的表连接

Question

不同微服务之间的表连接

architecturemicroservices

41

我仍在努力理解微服务架构。

分离不同应用程序（包括数据库）的想法让我感到兴奋。但如果有两个微服务，例如产品和用户。它们都在各自的数据库中拥有产品和用户表。根据微服务的最佳实践，我们只能从服务访问数据库。

问题是，假设我们有一个产品表，其中包含user_id列。我们想要查找产品并返回创建该产品的用户的名称。这需要在产品微服务中的产品表和用户微服务中的用户表之间进行联接。你如何处理这个问题？

- Robert Limanto

3个回答

21

虽然我认为采用Jan建议的方法没有问题，但我想补充一点，微服务应该给您的系统带来的差异是不同的。

上述服务的分离在SOA世界中很常见，但很快就变得过于复杂，而没有提供太多价值。

如果您（我理解这只是一个例子）需要查询与产品连接的用户-为什么要拆分服务？您最终会针对每个数据库实体设计一个服务，而不是查看给定的，对我来说似乎有界限的环境的要求是什么。

-Lars

- Lars

8

完全同意这一点，仅出于微服务而采用微服务并没有意义。 - Jan Vladimir Mostert

那么不同微服务的最佳示例是什么？如果用户和产品应该在同一个微服务中，该怎么办？ - Robert Limanto

如果你的使用案例显示这两个实体被同时查询/更新很多次，那么这表明它们应该存在于同一个有界上下文中，因此由同一个微服务进行处理。当然，也可能有一些情况下，你会发现这两个实体非常松散耦合，这种情况下你可能想在数据库层面复制数据，这样2个或更多的微服务就可以访问它们，而不必相互频繁交互。 - Lars

2

@Lars 这是一篇旧文章，我现在已经遇到过多次相同的情况。我同意如果无法适当尊重服务边界，那么将其拆分为不同的服务就没有意义。然而，在某些情况下，每个服务本身都具有相当大的复杂性和差异性。在这种情况下，将服务紧密耦合在单个API下会导致更多问题。最好找出“跨服务”查询的最佳策略（不知道该术语是否有效）。 - Abrar Hossain

关于设计服务，我更倾向于遵循 Vaughn Vernon 的《实现领域驱动设计》一书的规则：1）保持边界明确分离；2）尽量减小聚合大小，除非业务需求不允许最终一致性。关于跨多个服务的查询，我建议采用 Praful 回答中描述的 CQRS 和物化视图方法。 - dbaltor

14

在这种情况下，最好的解决方案是CQRS。维护用户和产品关系的物化视图。物化视图可以是提供低延迟读取的任何东西，如NoSql数据库。每当命令通过它们的微服务更新用户或产品时，相应的事件应该生成并被其他管理此物化视图的服务捕获。此服务将用于获取您感兴趣的查询。请始终记住，微服务体系结构信奉“最终一致性”，这绝对不是坏事 :)。希望这个回答能够解答你的问题。

- Praful

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Jan Vladimir Mostert · Accepted Answer

你需要对每个微服务进行调用并手动执行连接操作，或将相关用户ID传递到每个服务中。

UserMicroservice：

SELECT * FROM Users WHERE some condition is true

获取包括其id的用户列表。

ProductMicroserivce：

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

所以用户和产品仍然可以在两个不同的数据库中，只是产品需要有一个userId的概念。

反过来也可以做，ProductMicroserivce：

SELECT * FROM Products WHERE some condition is true

提取所有的用户ID，然后调用UserMicroservice：

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