我知道微服务架构建议每个服务都应该有自己的私有数据库。但是，当扩展此类服务时，是每个服务实例一个数据库还是所有服务实例共享一个数据库？
你的第一句话可能会误导一些人："每个服务都应该有自己的私有数据库。
您的体系结构在跨多个服务共享一组表时应小心 - 共享经常会导致共享架构依赖关系，这会创建紧密耦合，使得在不同时更新共享该架构的许多服务的情况下很难更新架构。
但是，共享单个数据库实例(或数据库集群)并不意味着您的服务正在访问数据库中的相同表甚至相同的架构。 如果它们不访问相同的表，则它们不会耦合。 (依赖同一个数据库实例并不比依赖同一个网络更耦合。 不要将耦合与共享基础结构混淆。
通常，同一服务的多个实例共享同一个数据库。 在我看来，这本身并没有什么问题，但有一些事情需要注意。 如果采用此路线，则在更改数据架构时需要非常小心。 由于该服务的多个版本可能在更新期间同时访问数据，因此任何架构更改都需要至少兼容任何两个相邻版本。 如果添加列或表，那很好。 旧版本不会尝试使用它，因此不会有问题。 (另请注意，旧版本也不会填充它。 删除列或表完全是另一个问题，若要进行这种中断性更改，可能需要通过几个较小的步骤进行，以确保旧版本的服务不会损坏。 这是可以做到的，只是更难。
微服务开发的一般规则是每个微服务 应该管理自己的数据。在理想世界中，由 每个服务都是完全独立的。没有必要 将一个服务中所做的数据更改传播到其他服务。 然而，在现实世界中，完全的数据独立是不可能的。 不同数据中使用的数据之间总是有重叠 服务，因此，作为架构师，您需要仔细考虑 共享数据并管理数据一致性。你需要考虑 微服务作为交互系统而不是单个 单位。
这意味着：
- 应尽可能少地隔离每个系统服务中的数据 尽可能共享数据。
- 如果数据共享是可避免的，则应设计微服务，以便 大多数共享是只读的，具有最少数量的 负责数据更新的服务。
- 如果在系统中复制服务，则必须包含 可以保留副本使用的数据库副本的机制 服务一致。
确实是个好问题。我会这样回答："每个微服务(不是实例)至少有一个数据库">
一个问题是 databse 本身的可伸缩性，即服务实例的规模能否超过数据库？
如果是这样，您可以选择内存数据库或微服务的挎斗。数据库将是临时的，您需要在 pod/容器(重新)启动后填充它。因此，状态并不真正存在于数据库中。 Apache Kafka 是一个适合这个位置的工具，因为它允许您在服务启动后填充数据库，并提供同步所有当前正在运行和未来实例的状态的工具。但是，使用 Kafka 成功实现事件溯源并不是一项简单的任务，但您可能会得出根本不需要数据库的结论。
所以问题仍然存在，服务实例真的能超过数据库吗？ 答案往往是"不"。
因此，通过为每个微服务(物理或逻辑上)拥有一个数据库实例，已经为您提供了很多"松散耦合和内聚行为"，因为您不共享数据库。
另一个问题是微服务版本之间对数据库的重大更改。如果出现问题，您可能会发现自己无法回滚。临时数据库可以以兼容的方式同步自身。
有人说它们在微服务的整个生命周期中都会更改数据库技术，我从来没有这样做的必要条件，但是内存/挎斗方法非常适合这里。
我假设您与一个微服务的所有实例共享一个数据库。以便同一微服务的每个实例立即有一个更新可用。每个微服务实例可以使用一个数据库实例，以避免数据库成为单点故障。但是您必须保持每个数据库的同步，这似乎是数据库和应用程序不必要的过载。我假设数据库能够使一组数据库实例保持同步(每次插入，更新，删除都正确传播)。