单数据库 vs 多数据库 - 微服务架构

Question

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

优点

可靠性

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

维护：

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

特征：

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

缺点

可靠性：

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

维护：

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

纪律：

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

表现：

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

恨：

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

其他想法：

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

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