单个数据库与多个数据库. Microservices体系结构

Question

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

1. 为每个服务保留一个单独的数据库，如在给定的映像中。

​

​

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

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

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

在更长的时间内，我需要连接多个表(由于第1点提到的体系结构，这些表位于不同的数据库中)，这样的报告怎么样？

Answer 1

如果数据有很大的关联，则可以使用单个共享数据库和不同的微服务拥有的表。此外，如果您对数据一致性和服务的可用性有强烈的要求。有正反两方面的。

Pros

可靠性

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

维修：

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

功能：

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

Cons

可靠性：

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

维修：

• 模式更改(迁移)应该非常小心地进行(外部API更改)，即使使用单编写器原则也是如此，因为模式读取上的不匹配也是永久性的失败。随着大型项目的开展，很难追踪谁会受到表更改的影响。

纪律：

• 只有表的所有者才能对表执行写操作。
• 您仍然需要大力推动数据解耦，以降低事务冲突的发生率。

性能：

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

恨：

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

其他想法：

在我个人的解释中，如果您不是Netflix，并且您的应用程序不能容忍任何形式的数据丢失，那么单个数据库是一个很好的选择。

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

Answer 2

第二种方法是微服务体系结构中的“共享数据库”反模式。

在微服务体系结构中，最好使用每个服务模式的数据库。

这些方法在页面末尾的链接中也有优点和缺点。

在回答您关于在哪里存储客户购买的产品的问题时，您需要创建一个新的微服务，它将用自己的数据库存储客户购买的产品。

对于分析和统计，您需要将数据从所有数据库发送到报告模块。换句话说，您需要构建一个etl进程。消息代理(如阿帕奇卡夫卡 )通常用于此目的。这个页面很好地描述了这种方法。

构建一个微服务体系结构是一项非常复杂和广泛的任务，它与许多问题和设计模式相关，这些问题和设计模式允许您将这些问题最小化。我推荐阅读一本"微服务模式“一书，它研究了各种微服务体系结构设计模式。