微服务架构的数据库设计 [关闭]

Posted 2023-03-08

【中文标题】微服务架构的数据库设计 [关闭]

【英文标题】：DB design for microservice architecture [closed]

【发布时间】：2017-09-11 14:36:13

【问题描述】：

我计划使用微服务架构来实现我们的网站。我想知道在服务之间共享数据库是否正确，或者是否最好为每个服务拥有一个单独的数据库。在这方面，我是否可以考虑为所有服务使用一个通用数据库，还是违反微服务架构的本质？

【参考方案1】：

微服务提供解耦。您必须将您的应用程序分解为独立的域。每个域都可以有一个数据库。如果其他 MS 需要访问其他一些微服务拥有的数据，它们必须通过网络进行通信。

如果你觉得依赖服务太多，网络调用太多，那么你可以定义一个域，将依赖服务聚集在一起。

例如 -- 假设我有一个在线测试评估服务，公司的经理可以发布测试，他可以查看他部门所有员工的结果。

我在这种情况下的微服务是：

初步设计

用户服务：用于登录和用户信息。 测试服务：评估测试的服务。 员工：处理员工详细信息 公司：处理组织 CRUD 部门：处理部门 CRUD

分解后，员工、组织和部门服务似乎会进行过多的网络/API 调用，因为它们彼此紧密依赖。所以最好将它们聚类。

更新设计

用户服务：用于登录和用户信息。 测试服务：评估测试的服务 组织：处理公司、员工和部门相关的操作。

每个服务都可以拥有自己的数据库并且可以独立部署。用户和测试服务可以使用 mongoDB 或任何 NoSql 数据库和组织服务可以使用 RDBMS。

希望这会有所帮助。

【参考方案2】：

如果您共享同一个数据库，那么您将失去微服务最重要的两个优势：strong cohesion and loose coupling (page 25)。

如果您不共享其中的表，您可以共享同一个数据库。例如，microservice1 使用 table1_1 和 table_1_2 和 microservice2 使用 table2_1 和 table2_2。当我说用途时，我的意思是读和写。一个微服务不读取也不写入另一个表。

【讨论】：

感谢您的回答。但是在我的应用程序中，有一种情况是其中一个服务使用了来自其他几个服务的数据。在这种情况下，我是否不会在服务之间以及从客户端到不同服务的 API 调用中冒太多风险？

微服务只使用网络通信

您可能想查看您的设计，找到有界上下文，这样您就可以很好地划分垂直领域，这样您就不需要跨越服务边界来进行数据更新（状态更改）、数据读取不那么令人担忧...

您可以使用消息代理来共享状态，每个微服务都会将此状态保存到自己的（可能是本地服务）数据库（或缓存）中。

@ConstantinGalbenu 如果我需要一些数据怎么办？例如，用于计算每周预定电子邮件的某些统计数据