Microservices 为什么每个微服务都有自己的数据库？

似乎在传统的微服务体系结构中，每个服务都有自己的数据库，对数据有不同的理解（如上所述）。有时，数据库可以复制数据。例如，“用户”服务可能基本上了解用户的所有信息，而“帖子”服务可能只存储主键和用户名（例如，帖子的作者可以显示其姓名）。讨论数据复制时的最终一致性、真相来源和其他相关概念。我知道微服务架构有时包括共享数据库，但我看到的大多数地方都表明这是一种罕见的策略

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

---

那么，微服务体系结构中的每个服务都应该拥有自己的数据库的一些理由是什么呢

微服务提倡设计约束，其中每个服务都是独立开发、部署和扩展的。只有在每个服务都有数据库的情况下，这一理念才可能实现。如果我的数据库出现故障，我如何继续我的业务？我可以采取什么措施来缓解这一问题？数据库是任何企业应用程序的重要组成部分。我同意当服务有自己的数据库时，会有不同数量的挑战

为什么选择独立数据库？

与其他方法不同，这种方法不仅可以保持代码库的干净性和可扩展性，而且可以真正忽略业务中的单一故障点。为了实现这一点，服务有时也可以有重复的数据，只要我的服务是自治的，并且只有在每个服务都有数据库的情况下，服务才能是自治的

---

从商业的角度来看，让我们来看看电子商务应用。你有诸如预订、订购、付款、推荐、搜索等微操作。数据库是共享的。如果数据库关闭，会发生什么情况？你所有的服务都停止了！除了拥有干净的代码库之外，使用微服务体系结构没有任何意义

如果每个服务都有自己的数据库，我不介意我的推荐服务是否不起作用，但我仍然可以搜索和预订订单，而且我没有失去客户。这就是重点

这需要付出代价和挑战，但从长远来看，这是值得的

SQL/NoSQL

每项服务都有自己的需求。为了获得最佳性能，我可以将SQL用于支付服务（事务），并将NoSQL用于推荐服务。在这种情况下，共享数据库对我没有帮助。在现代云架构（如CQR、事件源、物化视图）中，我们有时会对同一服务使用两个不同的数据库，以提高其性能

同样，每个服务的数据库不仅仅是关于资源或者它应该拥有多少数据。但我们必须看到更大的前景。是的，我们有一些特定的做法，有多少数据和重复是好是坏，但这是另一个争论

---

希望有帮助

每个微服务使用一个单独的数据库是有意义的，有几个原因。其中包括：

缩放

在微服务中拆分域是可以的。您可以根据需要在部署的web服务器上扩展特定的微服务，也可以根据需要扩展。这显然是使用微服务的好处之一。更重要的是，您可以让micro-service-1在10台服务器上运行，因为它需要这种流量，但micro-service-2只需要1台web服务器，所以您可以在1台服务器上部署它。好的是，你可以控制这一点，你可以像这样管理你的计算资源，以节省资金，因为云提供商并不便宜。 考虑到这一点，数据库呢？ 如果有一个数据库用于多个服务，则无法执行此操作。无法单独扩展数据库，因为它们将位于一台服务器上

数据分区以减少大小

当您在micro services中自动拆分域时，每个域包含一个数据库，您将拆分存储在每个数据库中的数据量。理想情况下，如果您这样做，您可以拥有更小的数据库服务器，并且计算能力和/或RAM更少。 一般来说，支付多台小型服务器的费用要比支付一台大型服务器的费用便宜。 因此，在这种情况下，您可以利用这一事实并节省一些资源。 如果域数据库中已有大量数据，比如数据分片或数据分区，那么可以应用其他技术，但这是另一个主题

哪种数据库技术适合业务需求

这对于拥有多个数据库非常重要。它允许您选择最适合您的业务需求的数据库技术，以便获得最佳性能或使用率。例如，某些特定的微服务可能有一些读操作，这些操作具有非常复杂的筛选选项和全文搜索要求。在这种情况下，使用弹性搜索将是一个不错的选择。其他一些微服务可能使用SQL Server，因为它需要特定于SQL的功能，如跨国行为或类似功能。如果出于某种原因，您的所有服务都只有一个数据库，那么您将不得不使用特定的数据库技术，而这种技术对于这些需求来说可能性能不太好。这肯定是一种妥协

开发人员规程

如果出于某种原因，你会有一对微型服务共享他们的数据库，你将需要处理这个问题