database - 微服务横向扩展/横向扩展数据库的最佳实践或设计

Question

微服务的主要好处是一种服务“类型”可以通过使用多个容器实例和负载均衡来提高吞吐量。

但有一件事是，“服务类型”的多个实例（即容器）共享同一个数据库实例；当多个实例在该数据库实例上写入/读取时，这可能会导致性能瓶颈。

传统上，我们会扩大该数据库实例的处理能力以满足高需求。

我的主要问题是，当前横向扩展/横向扩展的最佳实践/设计/解决方案是什么，以便我们可以拥有该数据库的多个实例并提高性能？

特别是，我要存档的是：

• 一个实例停机，另一个实例可以处理负载 -> 高可用性

• 可以负载平衡读取，甚至可以写入多个数据库实例

• 保持数据的持久性和一致性，以防我想创建更多的数据库实例

据我所知，

解决方案之一是 Microsoft SQL Server 为 SQL Server 容器提供高可用性，可以满足上述大部分要求（https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-container- ha-overview?view=sql-server-2017）。但我想知道是否有更好的解决方案来避免技术锁定？

我正在考虑的另一个解决方案是：通过使用 CDC 流数据从主数据库实例复制到多个实例到多个复制。这允许复制读取。

但我仍然不能说服，因为为了保证一致性，每个服务实例都应该写入主数据库实例，这也可能会导致主数据库实例的瓶颈。

标签： databasemicroservicesscale

Answer 1

广义上的数据库有 3 种可能的架构：

1. 单一领导者（例如 RDBMS）
2. 多领导者（例如多个 DC 中的 RDBMS）
3. 无领导者（例如 Riak、Cassandra）

当您在上面的列表中从上到下进行时，水平可扩展性潜力会增加，但一致性会变弱。

可扩展性潜力会增加，因为随着您在列表中向下移动，更多节点可以接受写入。由于写入需要时间来传播或复制到负责数据的所有节点，因此一致性变得更弱。当相同的记录几乎同时写入两个不同的节点时会出现冲突，因此在复制时系统不知道哪一个是正确的。

有多种解决冲突的策略。不同的数据库使用不同的策略。您需要研究这些策略以了解哪一个适合您的用例并根据您选择数据库。