我正在学习微服务，我将用微服务架构构建一个项目.
问题是，我的一个团队成员想要为所有服务使用一个数据库，共享所有的表，这样"数据就不会重复"，每个服务将使用不同的框架和语言(如Django和Rails)构建，它们使用非常不同的ORM标准.
正确的方法是什么？因为我认为使用一个数据库需要对ORM进行大量"黑客攻击"，以使其正常工作.
我正在学习微服务，我将用微服务架构构建一个项目.
问题是，我的一个团队成员想要为所有服务使用一个数据库，共享所有的表，这样"数据就不会重复"，每个服务将使用不同的框架和语言(如Django和Rails)构建，它们使用非常不同的ORM标准.
正确的方法是什么？因为我认为使用一个数据库需要对ORM进行大量"黑客攻击"，以使其正常工作.
如果所有服务共享相同的数据库表，则不太可能从微服务体系 struct 中获益.这是因为您有效地将服务紧密耦合在一起.如果数据库表更改，则所有服务都必须更改.
您必须理解，微服务体系 struct 的全部原因是减少开发团队之间的依赖，并允许他们独立地推进快速发布.
以下是亚马逊首席技术官沃纳·沃格尔(Werner Vogels)的一段话(亚马逊开创了许多微服务风格的架构):
对于我们来说，面向服务意味着用
2021年的更新:
一些 comments 者指出，共享一个物理数据库可能是可以的，例如，对同一数据库中的不同服务使用不同的表或模式.这当然是可能的，而且仍然是服务开发的有用的关注点分离.如果您希望服务团队负责整个服务堆栈和部署(包括基础设施)，或者希望将其分离到基础设施或开发运营团队中，这是一个架构(也是组织)决策.每种方法都有其优缺点，具体取决于您的组织环境、规模、需求等.
另一方面，较新的、可伸缩的DB技术正变得越来越流行.它们通常抽象化存储和计算以实现单独的可扩展性，并用作服务(例如，Snowflake、Teradata、BigQuery等).它们允许使用单个群集增长到具有数百万个表和PB级内容的非常大的大小.有了这些，目标就是让微服务实现团队不必担心运行DB基础设施的细节，而只是将DB集群端点用作服务依赖项.通常情况下，许多服务依赖于同一数据库群集.但是，您仍然需要注意存储分离，例如，分离逻辑表、集合或特定数据库技术中有意义的任何东西.