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

Question

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

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

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

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

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

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

Answer 1

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

优点

可靠性

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

维护：

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

特点：

• 可以进行复杂的查询，而且速度极快！
• 交易并不难。 （仍然需要重试）。

缺点

可靠性：

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

维护：

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

纪律：

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

性能：

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

仇恨：

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

其他想法：

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

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

Answer 2

第二种方法是微服务架构中的"Shared database" anti-pattern。

在微服务架构中，最好使用Database per service pattern。

这些方法的优点和缺点也可以在页面末尾的上述链接中找到。

针对您关于将客户购买的产品存储在何处的问题，您需要创建一个新的微服务，该微服务将使用自己的数据库存储客户购买的产品。

对于分析和统计，您需要将所有数据库中的数据发送到报告模块。换句话说，您需要构建一个 etl 进程。消息代理，例如Apache Kafka，通常用于此目的。这个page很好地描述了这种方法。

构建微服务架构是一项非常复杂和广泛的任务，它与许多问题和设计模式相关联，可以让您最大限度地减少这些问题。我推荐读一本书“Microservices patterns”，看看微服务架构设计的各种模式。