在传统的微服务体系结构中，每个服务似乎都拥有对数据的不同理解的自己的数据库（描述为here）。有时认为数据库允许重复数据。例如，“用户”服务可能实质上了解有关用户的所有信息，而“帖子”服务则可能只存储主键和用户名（例如，帖子的作者可以显示其姓名）。 This page讨论了复制数据时的最终一致性，真理来源和其他相关概念。我了解微服务架构有时会包含一个共享数据库，但是我认为大多数地方都建议这是一种罕见的策略。
至于为什么每个服务通常都有自己的数据库，到目前为止，我所看到的只是“使每个服务拥有自己的资源”，但我不相信a）服务层以任何方式“拥有” “通过数据库访问的持久资源开始于，或者b）服务甚至需要拥有其所需的资源，而不是通过共享数据库访问主资源的必要子集。
那么微服务体系结构中的每个服务都应该拥有自己的数据库有哪些理由？
答案 0 :(得分：0)
微服务
微服务提倡设计约束，其中每个服务都是独立开发，部署和扩展的。仅当每个服务都有数据库时，这种哲学才有可能。如果数据库出现故障，如何继续开展业务以及应采取哪些步骤来缓解这种情况？数据库是任何企业应用程序中必不可少的部分。我同意服务拥有自己的数据库时会面临许多不同的挑战。
为什么要使用独立数据库？
与其他方法不同，该方法不仅保持代码库整洁和可扩展，而且真正省略了业务中的单点故障。要实现此服务，有时只要我的服务是自治的，并且只有在每个服务都有数据库的情况下，服务才可以是自治的，所以有时也会有重复的数据。
从业务角度来看，让我们接受电子商务应用程序。您有微服务，例如预订，订单，付款，推荐，搜索等。数据库是共享的。如果数据库关闭，会发生什么？您所有的服务都失败了！除了拥有清晰的代码库之外，使用Microservies架构毫无用处。
如果您的每项服务都有其自己的数据库，那么我不介意我的推荐服务是否不起作用，但是我仍然可以搜索和预订订单，而且我也没有失去客户。这就是重点。
这带来了成本和挑战，但是从长远来看，它会有所回报。
SQL / NoSQL
每种服务都有其自己的需求。为了获得最佳性能，我可以使用SQL进行支付服务（交易），并且可以使用（我应该使用）NoSQL进行推荐服务。在这种情况下，共享数据库对我没有帮助。在诸如CQRS，事件源，物化视图之类的现代云体系结构中，有时我们为相同的服务使用2个不同的数据库来发挥性能。
每个服务的再次数据库不仅涉及资源或应拥有的数据量。但是我们确实必须看到更大的图景。是的，我们有一定的惯例，多少数据和重复数据是好是坏，但这是另一个争论。
希望有帮助！
答案 1 :(得分：0)
有几个原因使每个微服务使用单独的数据库确实有意义。其中一些是：
缩放
在微服务中拆分您的域名很好。您可以根据需要在已部署的Web服务器上扩展特定的微服务，也可以根据需要扩展。这显然是使用微服务的好处之一。更重要的是，您可以在例如10台服务器上运行微服务1，因为它需要这种流量，但是微服务2只需要1个Web服务器，因此您可以将其部署在1台服务器上。好处是您可以控制它，并且可以管理计算资源，例如，以便节省资金，因为云提供商并不便宜。 考虑到这一点，数据库呢？ 如果您有一个用于多种服务的数据库，则无法执行此操作。您无法像在一台服务器上那样分别扩展数据库。
数据分区以减小大小
当您在微服务中拆分域（每个包含1个数据库）时，会自动自动拆分每个数据库中存储的数据量。理想的情况是，如果您这样做，则可以拥有具有较少计算能力和/或RAM的小型数据库服务器。 通常，购买多台小型服务器要比购买一台大型服务器便宜。 因此，在这种情况下，您可以利用这一事实并节省一些资源。 如果碰巧已经由域数据库吐出的数据具有大量数据技术，例如数据分片或数据分区，则可以额外应用，但这是另一个主题。
哪种数据库技术可满足业务需求
这对于拥有多个数据库非常重要。它可以让您选择最适合您的业务需求的数据库技术，以获得最佳性能或最佳使用。例如，某些特定的微服务可能具有大量读取操作，这些操作具有非常复杂的过滤器选项和全文搜索要求。在这种情况下，使用Elastic Search是一个不错的选择。其他一些微服务可能会使用SQL Server，因为它需要SQL特定的功能，例如跨国行为或类似行为。如果出于某种原因您对所有服务都拥有一个数据库，那么您将被特定的数据库技术所困扰，而该数据库技术可能无法满足那些要求。当然，这是一个妥协。
开发人员纪律
如果由于某种原因您将拥有几个共享其数据库的微服务，则需要处理人为因素。开发人员必须受到纪律处分，使其不能跨域访问和修改/修改其他难以实现和控制的微服务数据库（表，集合等）。在拥有大量开发人员的大型组织中，这可能是一个严重的问题。进行硬体分割时，这不是问题。
摘要
对于每个微服务都有数据库有一些争论，但也有人反对。通常，使用微服务时的指导原则和建议是使微服务及其数据具有自治性，以便在理想情况下独立工作（并非总是如此）。绝对是一种妥协，并且通常也使用微服务。与往常一样，规则就是规则，但是也有例外。微服务架构非常灵活，并且非常依赖您的域需求。如果您和您的团队发现将多个微服务数据库合并为1并解决了很多问题，那就继续吧。