向外扩展/水平扩展微服务的最佳实践或设计 [英] Best practice or design to scale out/horizontal scale database for microservices

问题描述

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

The main benefit of Microservices are one Service "Type" can be scale out by using multiple container instances and load-balancing to improve through put.

但是，有一件事是，服务类型"的多个实例(即容器)共享同一个数据库实例.并且在该数据库实例上进行多个实例写入/读取时，这可能会导致性能瓶颈.

But one things is, multiple instances (ie. containers) of a "Service Type" are sharing the same database instance; and this could leave to performance bottle neck when multiple instance write/read on that database instance.

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

Traditionally, we would scale up on the processing power of that database instance to meet high demand.

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

特别是，我要存档的是:

In particular, what I want to archive are:

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

• One instance is down, a nother instance can handle the load -> High Availability

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

Can load balance read, or maybe even write to multiple database intance

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

Maintain the persistent and consistency of data incase I want to create more database-instance

在我所知的范围内，

解决方案之一是Microsoft SQL Server为SQL Server容器提供高可用性，并且可以满足上述大多数要求(

One of the solution is Microsoft SQL Server provide High availability for SQL Server containers with can do most of the requirements above (https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-container-ha-overview?view=sql-server-2017). But I'm wonder is there a better solution to avoid technology lock-down?

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

Another solution which I'm thinking of is: Replicate to multiple instance by using CDC Stream Data from a master database instance to multiple replications. This allow replication read.

但是我仍然不相信，因为要保证一致性，每个服务实例都应写入master-database-instance，这也可能会使master数据库实例陷入瓶颈.

But I'm still not convince because to quarrant the consistency, every services instance should write to master-database-instance, this could also, leave to bottle neck on master database instance.

推荐答案

从广义上讲，数据库有3种可能的体系结构:

There are 3 possible architectures for database at a broad level:

1. 单首(例如RDBMS)
2. 多头(例如，多个DC中的RDBMS)
3. 少一些(例如Riak，Cassandra)

在上述列表中自上而下时，水平可伸缩性潜力会增加，但一致性会变弱.

As you go from top to bottom in the above list, horizontal scalability potential increases, but consistancy becomes weaker.

可扩展性增加了，因为当您进入列表时，更多的节点可以接受写入.随着写入花费时间传播或复制到负责数据的所有节点，一致性变得更弱.当同一记录几乎同时写入两个不同的节点时，就会发生冲突，因此在复制时，系统不知道哪一个是正确的.

Scalability potential increases because more nodes can accept writes as you go down the list. Consistancy becomes weaker as writes take time to propagate or replicate to all nodes responsible for the data. Conflicts arise when same record is written in two different nodes at almost same time and so at the time of replication the system does not know which one is correct.

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

There are various conflict resolution strategies. Different database use different strategies. You need to study these strategies to understand which one suits your usecase and based on that you pick your DB.

这篇关于向外扩展/水平扩展微服务的最佳实践或设计的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！