微服务架构-数据库是否跨服务的所有实例共享？

Question

我知道微服务架构建议每个服务都应该有自己的私有数据库。但是，当扩展这样的服务时，它是每个服务实例一个db还是所有服务实例共享一个db？

Answer 1

确实是个好问题。我会这样回答：“每个微服务(不是实例)至少有一个数据库。”

一个令人担忧的问题是数据库本身的可伸缩性，即服务实例的规模能否超过数据库？

如果是这样的话，你可以选择内存中的数据库或者sidecar作为你的微服务。数据库是短暂的，您需要在pod/容器(Re)启动后填充它。所以状态并不是真正存在于数据库中。Apache Kafka是一个适合这一点的工具，因为它允许您在服务启动后填充数据库，还提供了同步所有当前运行和未来实例的状态的工具。但是使用Kafka成功实现事件采购并不是一件容易的事情，但你可以得出这样的结论:你根本不需要数据库。

因此，问题仍然存在，服务实例真的能超过数据库吗？答案往往是“不”。

因此，通过为每个微服务提供一个数据库实例(物理上或逻辑上)，已经在“松散耦合和内聚行为”方面为您提供了很多，因为您不共享数据库。

另一个问题是在不同版本的微服务之间破坏对数据库的更改。如果出现问题，您可能会发现自己无法回滚。临时数据库可以以兼容的方式同步自身。

有人说他们会在微服务的整个生命周期中改变数据库技术，我从来没有必要这样做，但是内存/sidecar方法非常适合这里。

Answer 2

你的第一句话可能会误导某些人：“每个服务都应该有自己的私有数据库。”

在多个服务之间共享一组表时，您的体系结构应该格外小心--共享通常会导致共享模式依赖项，这会造成紧密耦合，这使得在不同时更新许多共享该模式的服务的情况下更新模式变得非常困难。

但是，共享单个数据库实例(或数据库集群)并不意味着您的服务正在访问数据库中的相同表或相同模式。如果它们不是访问相同的表，那么它们就不是耦合的。(依赖于相同的数据库实例并不比依赖于相同的网络耦合得更多。不要混淆耦合和共享基础设施。)

通常，同一服务的多个实例共享同一数据库。在我看来，这本身并没有什么错，但有一些事情需要注意。如果采用这种方式，则在更改数据模式时需要非常小心。由于该服务的多个版本可能在更新期间同时访问数据，因此任何架构更改都需要至少与任意两个相邻版本兼容。如果添加一个列或表，就可以了。旧版本不会尝试使用它，所以不会有问题。(还要注意，旧版本也不会填充它。)删除列或表完全是另一个问题，要进行这种破坏性的更改，您可能需要在几个较小的步骤中完成，以确保旧版本的服务不会被破坏。这是可以做到的，只是更难。

Answer 3

我假设您与一个微服务的所有实例共享一个数据库。因此，同一微服务的每个实例都可以立即使用一个更新。您可以为每个微服务实例使用一个数据库实例，以避免数据库成为单点故障。但是，您必须保持每个数据库的同步，这对于数据库和应用程序来说似乎是不必要的过载。我假设数据库能够使一组数据库实例保持同步(每次插入、更新、删除都会被正确传播)。