Database 为微服务扩展/水平扩展数据库的最佳实践或设计

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

但有一点是，“服务类型”的多个实例（即容器）共享同一个数据库实例；当多个实例对该数据库实例进行写/读操作时，这可能会导致性能瓶颈

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

对我来说，主要的问题是，目前扩展/水平扩展的最佳实践/设计/解决方案是什么，这样我们就可以拥有该数据库的多个实例并提高性能？

特别是，我想归档的内容包括：

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

• 可以对多个数据库进行负载平衡读取，甚至写入 入口

• 维护数据的持久性和一致性，以备不时之需 创建更多数据库实例

据我所知

其中一个解决方案是Microsoft SQL Server为SQL Server容器提供高可用性，可以满足上述大部分要求（）。但我想知道有没有更好的办法来避免技术封锁

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

---

但我仍然无法说服您，因为要获得一致性，每个服务实例都应该写入主数据库实例，这也可能会在主数据库实例上留下瓶颈。

在做出选择时总是要权衡。数据库有其局限性，尽管可以扩展数据库，但通过使用简单的最佳实践，我们可以避免性能受到影响。您不能让数据库来处理高请求率，请记住，扩展数据库是一个昂贵的选择，如果不采取正确的措施，您最终会达到数据库的极限，所以规划整个系统而不仅仅是数据库

---

说到这里，您可以使用一个主控和从控分别进行读写，这是一种非常常见的方法，但您必须依赖于最终的一致性，并且您可以查看sql always on。您可以缓存最频繁的数据。如果你有很高的请求率，你可能需要考虑你把请求放在队列中，然后再排队，以避免数据库性能命中。p> 在广泛的层面上，数据库有3种可能的体系结构：

单一领导（如关系数据库管理系统）

多领导者（例如多个DC中的RDBMS）

无领袖（如里亚克、卡桑德拉）

在上面的列表中，从上到下，水平可伸缩性的潜力会增加，但一致性会变弱

可伸缩性的潜力会增加，因为当您进入列表时，更多的节点可以接受写操作。当写入需要时间传播或复制到负责数据的所有节点时，一致性变弱。当相同的记录几乎同时写入两个不同的节点时，会产生冲突，因此在复制时，系统不知道哪一个是正确的

有各种解决冲突的战略。不同的数据库使用不同的策略。您需要研究这些策略，以了解哪种策略适合您的用例，并在此基础上选择数据库