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

我正在开发一个利用微服务开发方法和平均堆栈的应用程序。我遇到了需要在多个微服务之间共享数据的情况。例如，假设我有用户，视频，消息（发送/接收，收件箱等）服务。现在，视频和消息记录属于一个帐户记录。当用户创建视频和发送/接收消息时，有一个外键（userId）必须与他们创建的视频和消息记录相关联。例如，我需要显示与每个视频关联的名字的第一个，中间名和最后一个名字。现在让我们说一下用户在前端滚动浏览上传到系统的视频列表，每次50个。在最糟糕的情况下，我可以看到每个视频都与唯一用户绑定的情况，即50次拉动。微服务：如何有效地处理微服务之间的数据依赖关系

似乎有两种方法对这一问题：

一个，我做了一个API调用用户服务，让每一个用户绑定到列表中的每个视频。这看起来效率不高，因为如果我每个视频都会拨打一个电话，它可能会变得非常健谈。在第二个API调用场景中，我会获取视频列表并发送一个清晰的用户外键列表来查询，以便让每个用户与每个视频关联。这似乎更有效率，但仍然看起来像是我失去了将所有东西放在一起发送出去或者需要被操纵的性能。

二，无论何时创建新用户，帐户服务都会将消息与其他服务需要的用户信息一起发送到扇出队列，然后单个服务将新用户添加到表中它是自己的数据库，因此保持松耦合。这里的极端不利之处在于数据重复，并且需要在需要更新以确保最终一致性时使扇出队列处理。尽管从长远来看，这种方法似乎是从性能角度来看效率最高的。

我在这两种方法之间徘徊，因为他们都有他们的折衷份额。哪种方法最适合实施？为什么？

来源

2017-06-07 user1790300

我也有兴趣在这个问题上。

首先，您描述的场景非常普遍。用户，视频和消息绝对是三种不同的微服务。如何将系统分解成碎片没有问题。

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

来源

2017-06-08 14:28:21

不要将您的设计决定限制为您已列出的2个选项。关于微服务最难的事情是让你的头脑知道服务是什么，以及如何将你的应用程序切割成可以作为“微服务”实现的有意义的块/服务。

仅仅因为你有3个实体（用户，视频&消息）并不意味着你必须实现3个服务。如果您的实际使用案例显示这些服务（或实体）严重依赖彼此来完成来自前端的简单请求，那么这显然表明您的裁剪不正确。

从我看到你的例子中我会设计出满足要求的1个微服务。请记住，微服务的设计基础之一是尽可能独立。没有必要过度复杂的服务，它不是SOA。

https://martinfowler.com/articles/microservices.html - >很棒的阅读！

问候，拉尔斯

来源

2017-06-08 05:12:57 Lars

同意广泛，但是，我不认为刘易斯/福勒的文章有什么太多的话要说，这有利于这里的OP服务组合。 –

不同意。应用程序如何分解为微服务没有问题。所有决定都是合理的。 –

如果将上述三种微服务组合在一起形成一个服务，问题是否可能导致创建一种更大的单一服务，因为为用户创建的附加功能更多？除非您要创建一个组合来自所需依赖项的数据的微服务。 – user1790300

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

回答

相关问题