微服务的主要好处是一个服务“类型”可以通过使用多个容器实例和负载平衡来扩展以提高吞吐量。
但有一点是，“服务类型”的多个实例（即容器）共享同一个数据库实例;当在该数据库实例上进行多个实例写入/读取时，这可能会留给性能瓶颈。
传统上，我们会扩大该数据库实例的处理能力以满足高需求。
对我来说，主要的问题是，当前最佳实践/设计/解决方案的扩展/横向扩展是什么，因此我们可以拥有该数据库的多个实例并提高性能？
特别是，我要归档的是：
据我所知，
其中一个解决方案是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数据库实例上。
广泛的数据库有3种可能的架构：
当您在上面的列表中从上到下时，水平可伸缩性潜力会增加，但是整体性会变弱。
可伸缩性潜力增加，因为更多节点可以在列表中接受写入。由于写入需要时间传播或复制到负责数据的所有节点，因此一致性变弱。当同一记录几乎同时写入两个不同的节点时会产生冲突，因此在复制时系统不知道哪一个是正确的。
有各种冲突解决策略。不同的数据库使用不同的策您需要研究这些策略，以了解哪一个适合您的用例，并根据您选择的数据库。
在做出选择时总会有一个权衡。数据库有其局限性，尽管扩展数据库，我们可以通过使用简单的最佳实践来避免性能损失。你不能把它留给数据库来处理高请求率并介意它扩展数据库是昂贵的选择，如果不采取正确的方法你最终会达到数据库限制所以计划整个系统而不仅仅是数据库。
到了你的观点，你可以有一个主和从分别读写是非常常见的方法，但你必须依靠最终的一致性和sql总是在你可以看看的东西。您可以缓存最常用的数据。如果您的请求率非常高，则可能需要考虑放置请求的队列，并在以后出列以避免数据库性能受到影响。