architecture - 单个数据库与多个数据库 - 微服务架构

Question

我计划使用微服务架构构建一个项目。我很想知道哪种设计在数据库方面会更好？

1. 为给定图像中的每个服务保留一个单独的数据库

2. 多个应用程序指向 1 个数据库。

如果我为每个服务保留单独的数据库，我们如何决定将映射表保存在哪里？

例如，我们有客户服务（单独的项目与 DB 1 交谈）和产品服务（单独的项目与 DB 2 交谈），我应该在哪里存储客户和产品映射（客户购买的产品）？

从长远来看，如果我需要连接多个表（由于第 1 点中提到的体系结构，这些表位于不同的数据库中），如何报告？

标签： architecturemicroservices

Answer 1

如果您的数据高度相关，您可以将单个共享数据库与由不同微服务拥有的表一起使用。此外，如果您对数据一致性和服务可用性有强烈要求。有利有弊。

优点

可靠性

• 您可以使用标准数据库工具对整个系统进行完全一致的增量备份，而无需停机。
• 在事件驱动架构的情况下，您可以将事件与数据一起存储。如果您将事件存储在数据库中，您甚至可能会失去您的代理并在不丢失数据的情况下生存。
• 完全约束和正确的数据关系。

维护：

• 您不必编写网络接口来从另一个服务获取数据，但如果您想要这种级别的分离，您可以这样做！
• 没有数据重复和陈旧状态。

特征：

• 复杂的查询是可能的，而且非常快！
• 交易并不难。（仍然需要重试）。

缺点

可靠性：

• 另一个单点故障（在简单的情况下）。您可以为 HA 使用复制设置，但它需要 OPS 资源。

维护：

• 架构更改（迁移）应该非常小心（作为外部 API 更改），即使实现了单写入器原则，因为读取时架构不匹配也是永久性故障。对于大型项目，很难跟踪谁会受到表更改的影响。

纪律：

• 只有表的所有者才能对其执行写操作。
• 您仍然需要努力将数据解耦以降低事务冲突率。

表现：

• 在存储容量和性能方面很难扩展。几乎所有成熟的数据库中都有集群解决方案，但正如上面所说，它需要大量的 OPS 资源

恨：

• 当您说您将微服务设计为使用单个数据库时，每个人都会无缘无故地讨厌您。忍受它。

其他想法：

以我个人的经验，如果您不是 Netflix 并且您的应用程序不能容忍任何形式的数据丢失，那么单一数据库是一个不错的选择。

1. “共享数据库”实际上在 microservices.io 上被描述为“架构模式”，它有自己的优点和缺点。那么为什么要贴上“反”的标签呢？
2. 这篇文章和这篇文章对共享数据库模式给出了相反的观点。从我的角度来看，这完全有道理。
3. 本文档描述了 BAC 定理。这基本上意味着如果您使用多个数据存储，您将无法同时拥有完整的正常运行时间和一致的备份。