微服务的主要好处是可以通过使用多个容器实例和负载平衡来提高吞吐量，从而扩展一种“服务”类型。
但是有一件事是，“服务类型”的多个实例（即容器）共享同一个数据库实例。并且在该数据库实例上进行多个实例写入/读取时，这可能会导致性能瓶颈。
传统上，我们将扩大该数据库实例的处理能力以满足高需求。
对我来说，主要问题是，当前最佳的横向扩展/水平最佳实践/设计/解决方案是什么，以便我们可以拥有该数据库的多个实例并提高性能？
特别是，我要存档的是：
一个实例关闭，另一个实例可以处理负载->高 可用性
可以负载均衡读取，甚至可以写入多个数据库 实例
维护数据的持久性和一致性，以防万一 创建更多的数据库实例
据我所知
解决方案之一是Microsoft SQL Server为SQL Server容器提供高可用性，并且可以满足上述大多数要求（https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-container-ha-overview?view=sql-server-2017）。但我想知道是否有更好的解决方案来避免技术锁定？
我正在考虑的另一个解决方案是：通过使用CDC流数据从主数据库实例复制到多个实例，从而复制到多个实例。这允许复制读取。
但是我仍然不相信，因为要保证一致性，每个服务实例都应写入master-database-instance，这也可能会使master数据库实例陷入瓶颈。
答案 0 :(得分：1)
从广义上讲，数据库有3种可能的体系结构：
在上面的列表中自上而下时，水平可伸缩性潜力增加，但一致性变弱。
可扩展性增加了，因为当您进入列表时，更多的节点可以接受写入。随着写入花费时间传播或复制到负责数据的所有节点，一致性变得更弱。当同一记录几乎同时写入两个不同的节点时，就会发生冲突，因此在复制时，系统不知道哪一个是正确的。
有多种冲突解决策略。不同的数据库使用不同的策略。您需要研究这些策略，以了解哪种策略适合您的用例，并以此为基础选择数据库。
答案 1 :(得分：0)
做出选择时总是要权衡取舍。数据库有其局限性，尽管可以扩展数据库，但我们可以通过使用简单的最佳实践来避免性能受到影响。您不能将其留给数据库来处理高请求率，并且介意扩展数据库是昂贵的选择，如果使用不当，最终将达到数据库的限制，因此要规划整个系统，而不仅仅是数据库。
说到您的观点，您可以有一个主服务器和一个从属服务器分别进行读写，这是很常见的方法，但是您必须依靠最终的一致性，而sql始终存在就是您可以看看的东西。您可以缓存最频繁的数据。如果您的请求率很高，则可能需要考虑放置请求的队列，并在以后出队，以免影响数据库性能。