具有共享数据库的微服务？使用多个 ORM？
Microservices with shared database? using multiple ORM's?
我正在学习微服务，我打算用微服务架构构建一个项目。
问题是，我的一个队友想为所有服务使用一个数据库，共享所有表，因此 "data doesn't get repeated"，每个服务都将使用不同的框架和语言构建，例如 django 和 rails 使用非常不同的 ORM 标准。
正确的做法是什么？因为我认为使用一个数据库会涉及很多 "hacking" ORM 才能使它们正常工作。
如果所有服务共享同一个数据库 table，您就不可能从微服务架构中获益。这是因为您有效地紧密耦合了服务。如果数据库 table 更改，则所有服务都必须更改。
您必须明白，微服务架构的全部原因是为了减少开发团队之间的依赖性，并允许他们通过快速发布独立前进。
这里引用亚马逊首席技术官 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 年更新：
一些评论者指出，共享物理数据库可能没问题，例如，通过在同一数据库中为不同的服务使用单独的 tables 或模式。这当然是可能的，并且对于服务开发来说仍然是一个有用的关注点分离。如果您希望服务团队负责整个服务堆栈和部署（包括基础架构），或者如果您希望将其分离到基础架构或 devops 团队中，这是一个架构（也是组织）决策。根据您的组织环境、规模、要求等，每种方法都有其优缺点。
另一方面，更新的、可扩展的数据库技术正变得越来越流行。它们通常抽象存储和计算以实现单独的可扩展性，并用作服务（例如 Snowflake、Teradata、BigQuery 等）。它们允许使用单个集群增长到具有数百万 table 和 PB 内容的非常大的尺寸。有了这些，目标就是让微服务实施团队不必担心 运行 数据库基础设施的细节，而只需将数据库集群端点用作服务依赖项。通常情况下，许多服务都依赖于同一个数据库集群。但是您仍然需要注意存储分离，例如单独的逻辑 tables、集合或任何在特定数据库技术中有意义的东西。
一般来说，微服务应该对其自己的数据负责。那是一个完美的世界场景。
实际上，某些服务可能彼此高度相关。例如。 CustomerShippingDetails 和 CustomerShoppingCheckout 服务可能都访问相同的数据——客户地址。那么您将如何解决向客户结账服务提供客户地址的问题。如果结账服务直接查询购物详情，那么您就打破了服务之间的松散耦合。另一种选择是引入共享数据库。
在架构上总会有某种妥协。牺牲的是高度依赖于全局（整个系统的设计）的架构决策。
没有太多关于您的系统的详细信息，我会采用混合方法。也就是说，为处理类似业务逻辑的服务提供共享数据库。因此 CustomerShippingDetails 和 CustomerShoppingCheckout 可以共享一个数据库。但是 StoreItemsDetails 会有一个单独的数据库。
您可以在 Microservice Architecture 找到更多关于微服务共享数据库模式的信息。
我正在学习微服务，我打算用微服务架构构建一个项目。
问题是，我的一个队友想为所有服务使用一个数据库，共享所有表，因此 "data doesn't get repeated"，每个服务都将使用不同的框架和语言构建，例如 django 和 rails 使用非常不同的 ORM 标准。
正确的做法是什么？因为我认为使用一个数据库会涉及很多 "hacking" ORM 才能使它们正常工作。
如果所有服务共享同一个数据库 table，您就不可能从微服务架构中获益。这是因为您有效地紧密耦合了服务。如果数据库 table 更改，则所有服务都必须更改。
您必须明白，微服务架构的全部原因是为了减少开发团队之间的依赖性，并允许他们通过快速发布独立前进。
这里引用亚马逊首席技术官 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 年更新：
一些评论者指出，共享物理数据库可能没问题，例如，通过在同一数据库中为不同的服务使用单独的 tables 或模式。这当然是可能的，并且对于服务开发来说仍然是一个有用的关注点分离。如果您希望服务团队负责整个服务堆栈和部署（包括基础架构），或者如果您希望将其分离到基础架构或 devops 团队中，这是一个架构（也是组织）决策。根据您的组织环境、规模、要求等，每种方法都有其优缺点。
另一方面，更新的、可扩展的数据库技术正变得越来越流行。它们通常抽象存储和计算以实现单独的可扩展性，并用作服务（例如 Snowflake、Teradata、BigQuery 等）。它们允许使用单个集群增长到具有数百万 table 和 PB 内容的非常大的尺寸。有了这些，目标就是让微服务实施团队不必担心 运行 数据库基础设施的细节，而只需将数据库集群端点用作服务依赖项。通常情况下，许多服务都依赖于同一个数据库集群。但是您仍然需要注意存储分离，例如单独的逻辑 tables、集合或任何在特定数据库技术中有意义的东西。
一般来说，微服务应该对其自己的数据负责。那是一个完美的世界场景。
实际上，某些服务可能彼此高度相关。例如。 CustomerShippingDetails 和 CustomerShoppingCheckout 服务可能都访问相同的数据——客户地址。那么您将如何解决向客户结账服务提供客户地址的问题。如果结账服务直接查询购物详情，那么您就打破了服务之间的松散耦合。另一种选择是引入共享数据库。
在架构上总会有某种妥协。牺牲的是高度依赖于全局（整个系统的设计）的架构决策。
没有太多关于您的系统的详细信息，我会采用混合方法。也就是说，为处理类似业务逻辑的服务提供共享数据库。因此 CustomerShippingDetails 和 CustomerShoppingCheckout 可以共享一个数据库。但是 StoreItemsDetails 会有一个单独的数据库。
您可以在 Microservice Architecture 找到更多关于微服务共享数据库模式的信息。