为什么每个微服务都有自己的数据库? [英] Why does each microservice get its own database?

问题描述

在传统的微服务体系结构中，每个服务似乎都拥有对数据的不同理解的自己的数据库(描述为此页面讨论了最终的一致性，来源事实以及其他有关复制数据时的相关概念.我了解微服务架构有时会包含一个共享数据库，但是我认为大多数地方都建议这是一种罕见的策略.

It seems that in the traditional microservice architecture, each service gets its own database with a different understanding of the data (described here). Sometimes it is considered permissible for databases to duplicate data. For instance, the "Users" service might know essentially everything about a user, whereas the "Posts" service might just store primary keys and usernames (so that the author of a post can have their name displayed, for instance). This page talks about eventual consistency, sources of truth, and other related concepts when data is duplicated. I understand that microservice architectures sometimes include a shared database, but most places I look suggest that this is a rare strategy.

至于为什么每个服务通常都有自己的数据库，到目前为止，我所看到的只是使每个服务拥有自己的资源"，但我不相信a)服务层以任何方式拥有" 通过数据库访问的持久资源开始，或者b)服务甚至需要拥有其所需的资源，而不是通过共享数据库访问主资源的必要子集.

As for why each service typically gets its own database, all I've seen so far is "so that each service owns its own resources," but I'm not convinced that a) the service layer in any way "owns" the persisted resources accessed through the database to begin with, or that b) services even need to own the resources they require rather than accessing necessary subsets of the master resources through a shared database.

那么微服务体系结构中的每个服务都应该拥有自己的数据库有哪些理由?

So what are some of the justifications that each service in a microservice architecture should get its own database?

推荐答案

为每个微服务使用单独的数据库确实有意义.其中一些是:

There are a few reasons why it does make sense to use a separate database per micro-service. Some of them are:

缩放

在微服务中拆分您的域名很好.您可以根据需要在已部署的Web服务器上扩展特定的微服务，也可以根据需要扩展.这显然是使用微服务的好处之一.更重要的是，您可以在例如10台服务器上运行微服务1，因为它需要这种流量，但是微服务2只需要1个Web服务器，因此您可以将其部署在1台服务器上.好处是，您可以控制它，并且可以管理计算资源，例如，以便节省资金，因为云提供商并不便宜. 考虑到这一点，数据库又如何呢? 如果您有一个用于多种服务的数据库，则无法执行此操作.您无法像在一台服务器上那样分别扩展数据库.

Splitting your domain in micro-services is fine. You can scale your particular micro-service on the deployed web-server on demand or scale out as needed. That it obviously one of the benefits when using micro-services. More importantly you can have micro-service-1 running for example on 10 servers as it demands this traffic but micro-service-2 only requires 1 web-server so you deploy it on 1 server. The good thing is that you control this and you can manage your computing resources like in order to save money as Cloud providers are not cheap. Considering this what about the database? If you have one database for multiple services you could not do this. You could not scale the databases individually as they would be on one server.

数据分区以减小大小

在微服务中拆分域(每个域包含1个数据库)时，将自动拆分每个数据库中存储的数据量.理想的情况是，如果您这样做，则可以拥有具有较少计算能力和/或RAM的小型数据库服务器. 通常，购买多台小型服务器要比购买一台大型服务器便宜. 因此，在这种情况下，您可以利用这一事实并节省一些资源. 如果碰巧已经由域数据库吐出的数据具有大量数据技术，例如数据分片或数据分区，则可以额外应用，但这是另一个主题.

Automatically as you split your domain in micro-services with each containing 1 database you split the amount of data that is stored in each database. Ideally if you do this you can have smaller database servers with less computing power and/or RAM. In general paying for multiple small servers is cheaper then one large one. So in this case you could make use of this fact and save some resources as well. If it happens that the already spited by domain database have large amount of data techniques like data sharding or data partitioning could be applied additional, but this is another topic.

哪种数据库技术可以满足业务需求

这对于拥有多个数据库非常重要.它可以让您选择最适合您的业务需求的数据库技术，以获得最佳性能或最佳使用.例如，某些特定的微服务可能具有大量读取操作，这些操作具有非常复杂的过滤器选项和全文搜索要求.在这种情况下，使用Elastic Search是一个不错的选择.其他一些微服务可能会使用SQL Server，因为它需要特定于SQL的功能，例如跨国行为或类似行为.如果出于某种原因您对所有服务都拥有一个数据库，那么您将被特定的数据库技术所困扰，而该数据库技术可能无法满足那些要求.当然，这是一个妥协.

This is very important pro fact for having multiple databases. It would allow you to pick the database technology which fits your Business requirement best in order to get the best performance or usage of it. For example some specific micro-service might have some Read-heavy operations with very complex filter options and a full text search requirement. Using Elastic Search in this case would be a good choice. Some other micro-service might use SQL Server as it requires SQL specific features like transnational behavior or similar. If for some reason you have one database for all services you would be stuck with the particular database technology which might not be so performant for those requirement. It is a compromise for sure.

开发人员纪律

如果由于某种原因您将拥有几个共享其数据库的微服务，则需要处理人为因素.开发人员必须受到纪律处分，使其不能跨越域并访问/修改难以实现和控制的其他微服务数据库(表，集合等).在拥有大量开发人员的大型组织中，这可能是一个严重的问题.进行硬体分割时，这不是问题.

If for some reason you would have a couple micro-services which would share their database you would need to deal with the human factor. The developers would need to be disciplined to not cross domains and access/modify the other micro-services database(tables, collections and etc) which would be hard to achieve and control. In large organisations with a lot of developers this could be a serious problem. With a hard/physical split this is not an issue.

摘要

对于每个微服务都拥有数据库有一些争论，但也有人反对.通常，使用微服务时的指导原则和建议是使微服务及其数据具有自治性，以便在理想情况下独立工作(并非总是如此).这与一般情况下使用微服务一样，无疑是一种折衷.与往常一样，规则是规则，但也有例外.微服务架构非常灵活，并且非常依赖您的域需求.如果您和您的团队发现将多个微服务数据库合并为1并解决了很多问题，那就继续吧.

There are some arguments for having database per micro-service but also some against it. In general the guidelines and suggestions when using micro-services are to have the micro-service together with its data autonomous in order to work independent in Ideal case(this is not the case always). It is defiantly a compromise as well as using micro-services in general. As always the rule is the rule but there are exceptions to it. Micro-services architecture is flexible and very dependent of your Domain needs and requirements. If you and your team identify that it makes sense to merge multiple micro-service databases to 1 and that it solves a lot of your problems then go for it.

这篇关于为什么每个微服务都有自己的数据库?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！