微服务：如何有效处理微服务之间的数据依赖关系答案

【问题标题】：Microservices: how to effectively deal with data dependencies between microservices微服务：如何有效处理微服务之间的数据依赖关系
【发布时间】：2017-11-09 06:36:31
【问题描述】：

我正在使用平均堆栈的微服务开发方法开发一个应用程序。我遇到了需要在多个微服务之间共享数据的情况。例如，假设我有用户、视频、消息（发送/接收、收件箱等）服务。现在视频和消息记录属于一个帐户记录。当用户创建视频并发送/接收消息时，有一个外键（userId）必须与他们创建的视频和消息记录相关联。例如，我有需要显示与每个视频关联的名字、中间名和姓氏的场景。现在假设在前端，用户正在滚动浏览上传到系统的视频列表，一次 50 个。在最坏的情况下，我可能会看到每个视频都与一个唯一用户相关联的情况下出现 50 的拉动。

似乎有两种方法可以解决这个问题：

第一，我对用户服务进行 api 调用，并让每个用户与列表中的每个视频相关联。这似乎效率低下，因为如果我为每个视频打一个电话，它可能会变得非常健谈。在第二个 api 调用场景中，我将获取视频列表并发送不同的用户外键列表进行查询，以使每个用户与每个视频相关联。这似乎更有效，但似乎我仍然失去了性能，将所有东西重新组合在一起以发送显示，或者需要对其进行操作。

二，每当创建一个新用户时，帐户服务都会向一个扇出队列发送一条包含每个其他服务所需的用户信息的消息，然后各个服务负责将新用户添加到它的表中自己的数据库，从而保持松散耦合。这里的极端缺点是数据重复，并且必须在需要进行更新以确保最终一致性时处理扇出队列。不过，从长远来看，从性能的角度来看，这种方法似乎是最有效的。

我在这两种方法之间犹豫不决，因为它们都有各自的权衡取舍。哪种方法最适合实施？为什么？

【问题讨论】：

标签： node.js mean-stack microservices

【解决方案1】：

不要将您的设计决策限制在您概述的这 2 个选项上。微服务最难的事情是让您了解服务是什么以及如何将您的应用程序切割成有意义的块/服务以作为“微服务”实现。

仅仅因为您拥有这 3 个实体（用户、视频和消息）并不意味着您必须实现 3 个服务。如果您的实际用例表明这些服务（或实体）严重依赖彼此来满足来自前端的简单请求，那么这是一个明确的信号，表明您的切割不正确。

根据我从您的示例中看到的情况，我将设计 1 个满足请求的微服务。请记住，微服务的设计基础之一是尽可能独立。无需过于复杂的服务，这不是 SOA。

https://martinfowler.com/articles/microservices.html -> 精彩阅读！

问候，拉尔斯

【讨论】：

大体上同意，但是，我认为 Lewis/Fowler 的文章对这里的 OP 有帮助的服务组合没有什么可说的。
不同意。应用程序如何分解为微服务没有问题。所有的决定都是合理的。
问题，如果上面描述的三个微服务被组合成一个服务，这可能会导致创建一种更大的单体服务，因为为用户创建了更多的功能来附属？除非你说要创建一个微服务来组合来自所需依赖项的数据。
@tomredfern - 这篇文章并没有关注这个确切的问题，而是讨论了服务和上下文边界之间的问题，我认为这很重要。
我喜欢@SergeyYarotskiy 在他的回答中发布的文章，但如果服务变得过于健谈，它也谈到了“将服务合并为一个的案例”，这是我试图用我的原始答案概述的内容。

【解决方案2】：

我也对这个问题感兴趣。

首先，您描述的场景很常见。用户、视频和消息绝对是三种不同的微服务。您如何将系统分解为多个部分没有问题。

其次，有多种选择，如何解决数据共享问题。看看来自 auth0 的精彩文章：https://auth0.com/blog/introduction-to-microservices-part-4-dependencies/

【讨论】：