我知道微服务架构建议每个服务都应该有自己的私有数据库。但是，在扩展此类服务时，是每个服务实例一个数据库还是所有服务实例共享一个数据库？
答案 0 :(得分：1)
确实是个好问题。我会这样回答：“每个微服务至少有一个数据库（不是实例）”
一个令人担忧的问题是数据库本身的可伸缩性，即服务实例能否超出数据库规模？
如果是这样，您可以选择微服务的内存数据库或辅助工具。该数据库将是临时数据库，您需要在容器/容器（重新）启动后填充它。因此状态不是真正存在于数据库中。 Apache Kafka是适合这一点的工具，因为它允许您在服务启动后填充数据库，并且还提供了用于同步所有当前正在运行和将来的实例的状态的工具。但是，使用Kafka成功实现事件源并不是一件容易的事，但是您可能会得出结论，根本不需要数据库。
所以问题仍然存在，服务实例真的可以超出数据库的规模吗？ 答案常常是“不”。
因此，通过每个微服务拥有一个数据库实例（物理上或逻辑上），就可以在不共享数据库的情况下为您带来很多“松散耦合和内聚行为”。
另一个担忧是打破微服务版本之间数据库的更改。如果出现问题，您可能会发现自己无法回滚。临时数据库可以以兼容方式自行同步。
有人说他们在微服务的整个生命周期内都在改变数据库技术，但我从来没有这样做的必要，但是内存/ sidecar方法非常适合。
答案 1 :(得分：0)
您的第一句话可能会误导某些人：“每个服务都应该有自己的私有数据库。”
您的架构在跨多个服务共享一组表时应该小心——这种共享频繁导致共享模式依赖，这会造成紧密耦合，使得在不更新许多服务的情况下更新模式变得困难同时共享该架构。
但是，共享单个数据库实例（或数据库集群）并不意味着您的服务正在访问数据库中的相同表甚至相同架构。如果它们不访问相同的表，它们就不会耦合。 （依赖同一个数据库实例并不比依赖同一个网络更耦合。不要将耦合与共享基础架构混淆。）
通常，同一服务的多个实例共享同一个数据库。在我看来，这没有什么本质上的错误，但有一些事情需要注意。如果您采用这种方式，则在更改数据架构时需要非常小心。由于该服务的多个版本可能在更新期间同时访问数据，因此任何架构更改都需要与至少任何两个相邻版本兼容。如果添加列或表，那很好。旧版本不会尝试使用它，所以不会有问题。 （还要注意，旧版本也不会填充它。）删除列或表完全是另一个问题，要进行这种破坏性更改，您可能需要分几个较小的步骤来完成，以确保旧版本服务的版本没有损坏。可以做到，只是更难。