具有共享数据库的微服务？使用多个 ORM？ [关闭]

Posted 2023-03-08

【中文标题】具有共享数据库的微服务？使用多个 ORM？ [关闭]

【英文标题】：Microservices with shared database? using multiple ORM's? [closed]

【发布时间】：2017-09-22 14:20:24

【问题描述】：

我正在学习微服务，我将使用微服务架构构建一个项目。

问题是，我的一个队友想要为所有服务使用一个数据库，共享所有表以便“数据不会重复”，每个服务都将使用不同的框架和语言构建，例如 django 和 rails 使用非常不同的 ORM 标准。

什么是正确的方法？因为我认为使用一个数据库会涉及大量“破解” ORM 以使其正常工作。

【问题讨论】：

你为什么需要“破解”orms？仅仅因为它们具有不同的语法并不意味着它们最终基本上不会做同样的事情，查询数据库。

DB design for microservice architecture的可能重复

这不是见仁见智，你可以使用共享数据库；但您只需要为独占访问权限分离访问权限即可强制执行数据所有权。 Cars 表可以归 Cars 服务所有。这已经很有用了，但有趣的是，编排服务可以通过只读视图加入 Cars 表。视图可以维护服务合同。 （不幸的是问题已经结束，所以我不能详细说明）

你可以，但你不应该。或者更确切地说，如果您要共享数据库，为什么还要为微服务烦恼？

【参考方案1】：

如果所有服务共享相同的数据库表，您就不可能从微服务架构中受益。这是因为您有效地紧密耦合服务。如果数据库表发生更改，所有服务都必须更改。

您必须了解，微服务架构的全部原因是减少开发团队之间的依赖关系，并允许他们通过快速发布独立前进。

这是来自亚马逊首席技术官 Werner Vogels 的一句话（亚马逊开创了许多微服务风格的架构）：

对我们来说，面向服务意味着用 对数据进行操作的业务逻辑，只能通过 发布的服务接口。不允许直接访问数据库 从服务外部，并且在服务之间没有数据共享 服务。

更多信息请阅读this和this。

2021 年更新：

一些评论者指出，共享一个物理 DB 可能是可以的，例如通过在同一个 DB 中为不同的服务使用不同的表或模式。这当然是可能的，并且对于服务开发来说仍然是一个有用的关注点分离。如果您希望服务团队负责整个服务堆栈和部署，包括基础设施，或者如果您想将其分离到一个基础设施或 devops 团队，这是一个架构（也是组织）决策。每种方法都有其优缺点，具体取决于您的组织环境、规模、要求等。

另一方面是更新的、可扩展的数据库技术正变得越来越流行。它们通常抽象存储和计算以实现单独的可扩展性，并用作服务（例如 Snowflake、Teradata、BigQuery 等）。它们允许使用单个集群增长到具有数百万表和 PB 级内容的非常大的规模。有了这些，目标是让微服务实施团队不必担心运行数据库基础设施的细节，而只需使用数据库集群端点作为服务依赖项。有许多服务依赖于同一个数据库集群是很正常的情况。但是，您仍然需要注意存储分离，例如单独的逻辑表、集合或任何在特定数据库技术中有意义的东西。

【讨论】：

这个答案显然是错误的。即使它们共享相同的数据库，您仍然可以从使用微服务中受益匪浅。不，微服务的全部目的不是为了减少你所描述的。这只是众多原因之一。我的公司将一个单体应用程序转换为 5 个微服务，它极大地改善了我们的工作流程和应用程序的性能......但它使用了一个单体数据库。

@gshauger：很高兴听到您可以从重构中受益。听起来您使用它来更正确地组件化您的应用程序。并且您的应用程序在复杂性、人员规模和水平扩展要求方面可能以不同的规模运行，而不是为微服务架构风格发明的场景（亚马逊、Netflix、具有 100 多个服务的谷歌等）。较小的场景当然更容易处理共享数据库的额外依赖项。我建议您阅读 SOA（在微服务术语之前就已经存在）。

我完全熟悉 SOA。我也很熟悉这样一个事实，即最初的微服务提案并不关心公司的规模，也没有提到共享数据库。就“松散耦合”而言，它只是建议您“根据最适合的方式”选择事物。您似乎对微服务的定义非常狭窄。

我同意@gshauger。在某些情况下，您可以通过在单个数据库中为每个服务实现私有表或私有模式来实现服务的数据隐私。当然，在某些情况下，由于吞吐量要求，某些服务也可能必须有自己的数据库。但我不认为每台服务器都必须有一个数据库......

@jim ：我不反对。我的回答中不排除这一点。另一点是考虑从计算中抽象存储的新数据库技术。有了这些，它就更不重要了，许多服务可能使用相同的逻辑和/或物理数据库作为服务。不过，您仍然希望分离范围，并且您建议通过单独的表或模式来实现，这可能会很好。根据数据库技术，可能还有其他方法可以减少您的服务范围并避免重叠。没有什么是虔诚的。当然，有充分的理由你可能会偏离。

【参考方案2】：

一般来说，微服务应该对自己的数据负责。这是一个完美的世界场景。

在实践中，某些服务可能彼此高度相关。例如。 CustomerShippingDetails 和 CustomerShoppingCheckout 服务可能都访问相同的数据 - 客户地址。然后，您将如何解决向客户结帐服务提供客户地址的问题。如果结账服务直接查询购物细节，那么你就打破了服务之间的松散耦合。其他选择是引入共享数据库。

在架构上总会有某种妥协。牺牲的是高度依赖于全局（整个系统的设计）的架构决策。

没有太多关于您的系统的详细信息，我会采用混合方法。也就是说，拥有一个用于处理类似业务逻辑的服务的共享数据库。所以 CustomerShippingDetails 和 CustomerShoppingCheckout 可以共享一个数据库。但是 StoreItemsDetails 会有一个单独的数据库。

您可以在Microservice Architecture 找到有关微服务共享数据库模式的更多信息。

【讨论】：

您有客户详细信息服务？

取决于此服务的职责。如果它处理该人的详细信息 - 当然。如果它处理人的详细信息加上购物详细信息和运输等，那么我会将其分解，以便微服务的范围仅限于非常精确的域 - 以便在需要时很容易替换。

您所指的模式在这里称为反模式：microservices.io/patterns/data/database-per-service.html 如果结帐服务使用 API 检索地址，则不会破坏松散耦合。如果通过模式依赖将两者联系起来，松散耦合就会被破坏。

让一个专用的微服务与数据库通信并让所有其他微服务调用该服务怎么样？最大的优势之一是，如果我们将来迁移到另一个数据库（比如从 SQL 到 Mongo），那么我们只需要更新该服务，其他服务都不需要知道。