为微服务横向扩展/水平扩展数据库的最佳实践或设计
微服务的主要好处是一种服务“类型”可以通过使用多个容器实例和负载平衡来扩展以提高吞吐量。
但有一件事是，多个实例(即，“服务类型”的容器)共享相同的数据库实例；当多个实例对该数据库实例进行读/写时，这可能会造成性能瓶颈。
传统上，我们会扩展该数据库实例的处理能力，以满足高需求。
我的主要问题是，在横向扩展/水平扩展方面，当前的最佳实践/设计/解决方案是什么，以便我们可以拥有该数据库的多个实例并提高性能？
特别是，我想归档的内容是：
为了保证数据的持久性和一致性，如果我想创建更多Availability
- Can，一个实例停机了，另一个实例可以处理高负载平衡读取( High database-instance
load balance read )的负载，甚至可以写入多个数据库(
- -> )
据我所知，
其中一个解决方案是Microsoft SQL Server为SQL Server容器提供高可用性，可以满足上述大部分要求(https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-container-ha-overview?view=sql-server-2017)。但我想知道有没有更好的解决方案来避免技术锁定？
我正在考虑的另一个解决方案是:通过使用CDC Stream数据从主数据库实例复制到多个实例。这允许复制读取。
但我仍然不能令人信服，因为为了保证一致性，每个服务实例都应该写入master- database - instance，这也可能会在master数据库实例上留下瓶颈。
回答 2
Stack Overflow用户
发布于 2019-02-23 00:22:32
在广泛的层次上，数据库有3种可能的架构：
- 单引线(例如关系数据库)
- 多引线(例如多个DC中的关系数据库)
- 少引线(例如Riak、Cassandra)
在上面的列表中，从上到下，水平可伸缩性的潜力会增加，但一致性会变弱。
可伸缩性潜力增加了，因为随着列表的向下移动，更多的节点可以接受写入。一致性变得较弱，因为写入需要时间来传播或复制到负责数据的所有节点。当几乎同时在两个不同的节点中写入相同的记录时，就会出现冲突，因此在复制时，系统不知道哪一个是正确的。
有各种冲突解决策略。不同的数据库使用不同的策略。你需要研究这些策略，以了解哪种策略适合你的用例，并在此基础上选择你的数据库。
Stack Overflow用户
发布于 2019-02-20 04:37:34
在做出选择时，总是有权衡的。数据库有其局限性，尽管可以扩展数据库，但我们可以通过使用简单的最佳实践来避免性能损失。你不能让数据库来处理高请求率，注意扩展数据库是一种昂贵的选择，如果处理不当，你最终会遇到数据库的限制，所以计划整个系统而不仅仅是数据库。
说到这里，您可以使用一个主机和一个从机来分别读取和写入，这是一种非常常见的方法，但您必须依赖最终的一致性，并且sql always on是您可以查看的东西。您可以缓存最频繁的数据。如果您有非常高的请求率，您可能需要考虑放置请求的队列，并在稍后将其出队，以避免影响数据库性能。
https://stackoverflow.com/questions/54771633
复制相似问题
腾讯云开发者
