具有共享数据库的微服务?使用多个 ORM? [英] Microservices with shared database? using multiple ORM's?
问题描述
我正在学习微服务，我将使用微服务架构构建一个项目.
I'm learning about microservices and I'm gonna build a project with a microservices architecture.
问题是，我的一个团队成员想要为所有服务使用一个数据库，共享所有表，这样数据不会重复"，每个服务都将使用不同的框架和语言构建，例如使用 django 和 rails非常不同的 ORM 标准.
The thing is, one of my team mates want to use one database for all services, sharing all tables so "data doesn't get repeated", each service would be built with different frameworks and languages like django and rails which use very different ORM standards.
正确的方法是什么?因为我认为使用一个数据库会涉及到很多破解" ORM 以使其正常工作.
What would be the correct approach? Since I think working with one database would involve a lot of "hacking" the ORMs in order to make them work correctly.
推荐答案
如果所有服务共享相同的数据库表，您就不太可能从微服务架构中受益.这是因为您有效地紧密耦合了服务.如果数据库表更改，所有服务都必须更改.
You are not likely to benefit from a Microservices architecture if all the services share the same database tables. This is because you are effectively tightly coupling the services. If a database table changes all the services will have to change.
您必须明白，采用微服务架构的全部原因是为了减少开发团队之间的依赖关系，并允许他们通过快速发布独立推进.
You have to understand that the whole reason for a Microservices architecture is to reduce dependencies between development teams and allow them to move ahead independently with fast releases.
这是亚马逊 CTO Werner Vogels 的引述(亚马逊开创了许多微服务风格的架构):
Here is a quote from Werner Vogels, the Amazon CTO (Amazon pioneered a lot of the Microservices style architecture):
对我们来说，面向服务意味着用对数据进行操作的业务逻辑，只能通过已发布的服务接口.不允许直接访问数据库从服务外部，并且在服务之间没有数据共享服务.
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.
For more information read this and this.
2021 年的更新:
一些评论者指出，共享一个物理数据库可能没问题，例如通过为同一数据库中的不同服务使用不同的表或模式.这当然是可能的，并且对于服务开发来说仍然是一个有用的关注点分离.如果您希望服务团队负责整个服务堆栈和部署(包括基础设施)，或者您希望将其分成基础设施或 DevOps 团队，那么这是一个架构(也是组织)决策.每种方法都有其优缺点，具体取决于您的组织环境、规模、要求等.
Some commenters pointed out that sharing a physical DB may be ok, for example by using separate tables or schemas for different services in the same DB. This is of course possible and still a useful separation of concerns for the service development. It is an architectural (and also organizational-) decision if you want the service teams being responsible for the whole service stack and deployment, including infrastructure, or if you want to separate that out into an infrastructure- or devops-team. Each approach can have its pros and cons depending on your organizational circumstances, scale, requirements, etc.
另一方面是更新的、可扩展的数据库技术正变得越来越流行.它们通常抽象存储和计算以实现单独的可扩展性，并用作服务(例如 Snowflake、Teradata、BigQuery 等).它们允许使用单个集群扩展到包含数百万表和 PB 内容的非常大的大小.有了这些，目标就是让微服务实现团队不必担心运行数据库基础设施的细节，而只需将数据库集群端点用作服务依赖项.并且许多服务依赖于同一个数据库集群是正常情况.但是，您仍然需要注意存储分离，例如单独的逻辑表、集合或任何在特定数据库技术中有意义的东西.
Another aspect is that newer, scalable DB technologies are becoming more popular. They generally abstract storage and compute for separate scalability and are used as a service (for example Snowflake, Teradata, BigQuery, etc.). They allow growing to very large sizes with millions of tables and petabytes of content using a single cluster. With those it would be the goal to have the microservice implementation teams not worry about the details of running a DB infrastructure, but just use the DB cluster endpoint as a service dependency. And it would be the normal case to have many services depend on that same DB cluster. However you would still want to pay attention to storage separation, e.g. separate logical tables, collections, or whatever makes sense in the specific DB technology.
这篇关于具有共享数据库的微服务?使用多个 ORM?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
