采用微服务架构时，底层读写数据库会成为瓶颈吗？

Question

正如我在问题中所描述的，如果我要实现微服务架构，集中式读/写数据库会成为瓶颈吗？

举个例子来扩展，假设我有三个微服务：

users

、

teams

和

team_members

。每个都有自己的微服务，但它们都在数据库中相互依赖，因此排他的并行数据库是不合适的。由于微服务旨在将工作分配到多个不同的服务器，因此中央数据库最终是否会违背这些微服务的目的，因为它们最终都会调用同一台服务器？

Answer 1

...如果我要实现微服务架构，会吗？ 集中式读写数据库成为瓶颈？

您的问题中有一个内置的假设。假设微服务必须共享数据库中相同的主表。

事实上，在你的问题中，你直接表达了这个概念：

...但是他们在数据库中都是相互依赖的，如此排他， 并行数据库不合适。

如果微服务共享数据库表，那么您实际上所做的就是使用多个组件构建一个“服务”，这些组件恰好通过某种带外传输相互消耗，而不是通过直接二进制引用在内存中消耗。

面向服务背后最重要的概念之一是“自治”，这基本上意味着每个服务都应该拥有自己的数据。 扩展您的示例，

用户服务

将了解团队。它怎么知道？那么，团队服务会将团队数据推送到用户服务。同样，team_members 服务 将从这两个服务接收数据。现在，所有服务都拥有完成工作所需的所有数据。 因此，通过将服务实现为自治，同一组基表上的争用可能性就会消失。

Answer 2

分解域时，不要使用单实体交互模型，而是使用属性/字段交互和有界上下文来组合组件/微服务。

例如，用户帐户注册将仅具有正在修改的用户字段（更改状态，因此拥有实体的这些属性）。

另一个组件可能有用户的地址，另一个组件可能有用户的年龄、性别和婚姻信息，另一个组件可能有他的信用卡和银行详细信息......

您最终将为每个有界上下文提供单独的表。

如何托管表取决于您，并取决于您的负载和基础设施（一个数据库和一台服务器或多个数据库/服务器中的所有表）

澄清一下，这些表没有参照完整性，如果有参照完整性，您将重新引入耦合，这将使您回到数据库争用问题...

观看

Udi Dahan 的演讲

了解更多详细信息

Answer 3

最好为每个微服务拥有单独的数据库实例，并对公共表/数据使用缓存。

Answer 4

users

和

teams

服务，我认为情况已经如此。现在如何实现

team_members

服务？当新关联推送到服务时，服务必须确保团队和用户存在。

唯一的方法是通过 API 调用其他服务。

team_members 服务必须向

team

服务发出 HEAD 请求（或 GET 请求），以检查给定的团队 ID 是否引用了团队存在，并向

user

服务发出另一个 HEAD 请求来检查用户 ID。您应该同时执行这两个请求以加快速度。因此，带有有效负载

POST /team_members

的

{"team":"123","member":"456"}

应触发

HEAD /team/123

和

HEAD /user/456

。如果 HEAD 返回 404，您的服务将返回 400。您开始时将所有服务的表都存储在同一个数据库中，但后来您可以通过将一些表移动到专用数据库来进行扩展，甚至可以切换到不同类型的数据库（例如非 SQL）。