<分区>
我正在学习微服务，我将构建一个具有微服务架构的项目。
问题是，我的一个队友想为所有服务使用一个数据库，共享所有表以便“数据不会重复”，每个服务都将使用不同的框架和语言构建，例如 django 和 rails，它们使用非常不同的 ORM 标准。
什么是正确的方法？因为我认为使用一个数据库会涉及大量“破解”ORM 以使其正常工作。
<分区>
我正在学习微服务，我将构建一个具有微服务架构的项目。
问题是，我的一个队友想为所有服务使用一个数据库，共享所有表以便“数据不会重复”，每个服务都将使用不同的框架和语言构建，例如 django 和 rails，它们使用非常不同的 ORM 标准。
什么是正确的方法？因为我认为使用一个数据库会涉及大量“破解”ORM 以使其正常工作。
最佳答案
如果所有服务共享相同的数据库表，您就不可能从微服务架构中受益。这是因为您有效地紧密耦合了服务。如果数据库表更改，则所有服务都必须更改。
您必须明白，微服务架构的全部原因是为了减少开发团队之间的依赖性，并允许他们通过快速发布独立前进。
这里引用亚马逊首席技术官 Werner Vogels 的话(亚马逊开创了很多微服务风格的架构):
For us service orientation means encapsulating the data with the business logic that operates on the data, with the only access through a published service interface. No direct database access is allowed from outside the service, and there’s no data sharing among the services.
2021 年更新:
一些评论者指出，共享一个物理数据库可能没问题，例如，通过为同一数据库中的不同服务使用单独的表或模式。这当然是可能的，并且对于服务开发来说仍然是一个有用的关注点分离。如果您希望服务团队负责整个服务堆栈和部署(包括基础架构)，或者如果您希望将其分离到基础架构或 devops 团队中，这是一个架构(也是组织)决策。每种方法都各有利弊，具体取决于您的组织环境、规模、要求等。
另一方面，更新的、可扩展的数据库技术正变得越来越流行。它们通常抽象存储和计算以实现单独的可扩展性，并用作服务(例如 Snowflake、Teradata、BigQuery 等)。它们允许使用单个集群增长到具有数百万表和数 PB 内容的非常大的规模。有了这些，目标就是让微服务实现团队不必担心运行数据库基础设施的细节，而只需将数据库集群端点用作服务依赖项。通常情况下，许多服务都依赖于同一个数据库集群。但是您仍然需要注意存储分离，例如单独的逻辑表、集合或任何在特定数据库技术中有意义的东西。
关于database - 具有共享数据库的微服务？使用多个 ORM？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/43612866/