问微服务和数据存储

EN

在您的三个选项中，第一个选项(一个共享数据库)和第三个选项(“数据库服务”)是最常见的。

第一个被称为集成数据库。在微服务体系结构中，这通常不是一个好的解决方案。它确实为您的服务添加了耦合。它还使一个服务很容易简单地绕过其他服务，直接查询到数据库。您可能会丢失应用程序级别提供的任何类型的数据完整性或验证，而该应用程序级别在数据库级别上没有强制执行。

你的第三个想法叫做应用数据库。而且您是对的--它允许您在服务之间在API级别强制执行松散耦合，并允许您在数据库级别上更容易地扩展服务。它还使用每个服务替换底层数据库技术变得更容易，就像您可以更改每个服务的技术或其他实现细节一样。非常灵活。

然而，我会提出一个中间的解决方案。

与其为每个微服务建立一个数据库服务，不如为每个服务建立一个模式。如果您正在使用多个数据库技术，您可能需要稍微不同地拆分，但是这样做的想法是尽量减少正在运行的数据库服务器的数量，但是如果需要的话，可以很容易地将服务拆分到它自己的数据库服务器中。只要您只允许数据库访问它自己的架构，您就有应用程序数据库的优点，但是没有为每个应用程序或服务存在的数据库服务器的开销。

然而，作为一个单独的开发人员，我会在这个时候对微服务的整个概念提出质疑-- Martin写到了单点第一和小额服务溢价，Simon谈到了模单橄榄石，DHH谈到了雄伟的莫立石。我不知道你的独角兽组织得有多好，但是重构和组织它。识别组件，并在它们之间进行干净的分离，以便轻松地将部件提取到服务中。数据库结构也是如此。专注于良好的、干净的、基于组件的体系结构，它可以支持重构到服务中。Microservices增加了单个开发人员在操作中构建和支持的大量开销。然而，一旦您实际需要扩展系统的一部分，使用您的监视和报告系统来识别瓶颈，提取到服务，并根据需要进行扩展。

每个微服务都有自己的数据库服务--这似乎是最有希望的，因为它保留了松散耦合和水平扩展的好处(使用冗余的数据库副本和/或跨几个)

同意。第三种选择是微观服务的自然选择。如果微服务是真正独立的(而不是分布式单石的一部分)，那么每个微服务都有一个数据库，这是正常的。

...每个微服务有两个实际的微服务实例(在服务器故障时和在没有停机的情况下部署)，以及每个微服务两个数据库服务实例(在服务器故障等情况下.)。

如果您想要实现负载平衡，那么运行微服务的数量是正确的。如果您计划拥有4个微服务，您需要准备每个微服务的至少2个实例(总共8个)，正如您已经解释过的那样。

但每个微服务有两个数据库？这真的很有问题。我不知道您的微服务将参与的业务问题的细节，但是有一个数据库冗余--对于大多数产品/项目来说，这是相当多的事情。我将建议从一个具有良好备份的单一数据库开始，并将基础结构的复杂性最小化(至少在最初是这样)。

坦白地说，这似乎有点荒谬。16-20服务器运行一个简单的API，考虑到一个现实的项目可能有超过4-5的服务？有什么基本的概念，我错过了，可以解释这一点吗？

对于一个简单的API，这个数字不匹配。如果你没有陷入“微服务第一”(Microservice First) 陷阱，请注意。

微型服务是一种面向服务的体系结构，可能是极端的。它们的一般目的是减少耦合，允许独立的开发和部署。

从体系结构上讲，微服务是一个逻辑层次上适用的术语。微观服务在逻辑上是相互分离的。从这个角度来看，微服务应该各自拥有并提供自己的存储，而存储应该与其他微服务的存储分离。对于微服务来说，这种存储的独立性对于它们实现模块化和松散耦合的目标至关重要。

从架构的角度来看，横向扩展适用于更低的层次，更接近于实现，比方说，在物理层面。在这个层次上，我们正在实现一个微服务，我们可以在内部将这个单一的微服务分解为一个水平可伸缩的无状态组件，以及一个由所有无状态组件共享的有状态组件。但是，我们不要仅仅将无状态部分与微服务本身混淆。

因此，当我们谈论单个的微服务时，我们处于逻辑层面，谈论API和分离的责任以及分离的开发/部署周期。当我们谈论水平扩展时，我们在物理层面上讨论了(单个)微服务的实现及其分解为无状态和有状态组件。

在实现多个微服务时，我们可以选择对有状态组件重用数据库技术：

• 每个微服务单独的数据库
• 与：共享数据库
  • 每个微服务的单独/私有模式
  • 每个微型服务单独/专用表

请参阅更多这里。

一个由所有微服务共享的数据库服务--这似乎完全消除了松耦合的任何好处。

同意，如果您的意思是共享表、行和列，那就不是真正的微服务。

如果我们能够--在我们的思维过程中--将微服务的逻辑概念与微服务的有状态和无状态组件的物理概念分离开来，我们可能会发现更容易实现微服务提供的松散耦合，同时保持共享数据库的效率。

通常，关于微服务和有状态的持久性有相当多的内容，请参见这里。