大咖连载|可扩展性设计（三）

最新推荐文章于 2025-05-19 11:39:16 发布

原创最新推荐文章于 2025-05-19 11:39:16 发布 · 187 阅读

0 ·

CC 4.0 BY-SA版权

送你小心心记得关注我哦！！

作者|华为云微服务架构师王启军

本文节选自《持续演进的 Cloud Native 云原生架构下微服务最佳实践》

如何扩展数据中心

1.1.1 两地三中心和同城多活

通常，为了容灾，大型企业系统会采用灾备的部署方式，也就是说，一个主机房，一个备份机房，主机房承载所有的流量，而备份机房平时处于休眠状态，没有流量，只有当发生灾难，主机房不可用的时候才会启用备份机房。而通常主备之间的延迟比较大，只能采用异步复制数据的方式。但是这仅仅作为灾备，如果一个机房的容量达到瓶颈，是无法扩展的。

为了解决这个问题，通常会采用两地三中心的方案，这也是很多银行系统在使用的方案。如图1所示，其中两个机房需要离的比较近，延迟非常小，某些场景下可以看成一个机房，所以，需要专线连接，所有的流量都由这两个机房承载，另外一个则作为灾备，平时处于休眠状态。

图 1 两地三中心

对于两地三中心，问题如下：

由于需要低延迟，专线比较贵，“两地”通常离的比较近，真正的灾难来临，例如地震，还是跟主备一样。
备份节点处于休眠状态，比较浪费资源。
备份节点处于休眠状态，真正切换的时候，需要的时间较长。

我们需要明确的是，在两地三中心这种数据中心架构中，首先需要梳理出核心业务流程，对服务进行分级，规划哪些业务需要部署到多个数据中心，并不是所有的应用都需要做到那么高的可用性。

其次，往备份节点同步数据一定是异步的复制方式，否则性能会受到非常大的影响，异步意味着可能会丢失部分数据，这是不可避免的，如果真的发生地震，只要磁盘不坏，还是可以恢复的，尽管恢复的时间比较长。

1.1.2 同城多活

微信采用的是一地三园区的部署方式，三个园区是对等并且物理隔离的，也就是说，无论是服务层，还是存储层，都部署在三个园区，流量被负载均衡到三个园区，不存在资源浪费。当其中一个园区发生故障时，流量会被均分到另外两个园区，另外两个园区流量上升百分之五十。这是由微信的底层存储决定的，微信底层存储采用的是KVSvr，可以实现强一致性、高可用、高性能，实际上，是利用W+R>N原理，只要写数据时写两份成功才返回，就能保证，如果一个节点挂掉，读取两个节点一定能读到一份最新的数据。当然，一地决定了时延较低，但是也无法做到跨城区的容灾。

我们来总结一下上面的方案。

如果跨城区，能跨城市容灾，但是成本高，利用率低，一致性低。
如果同城，成本低，利用率高，可以保证核心业务强一致，但不能跨城市容灾，且扩展性受限。

那么有没有其他的方案呢？当然是有，不过，系统架构将变的越来越复杂，成本越来越高。

1.1.3 异地多活

异地多活是指在两个以上的城市建立机房，流量被平均分配，当一个城市出现故障的时候，可以将发生故障的城市的流量快速切换到其他城市。异地多活就像以城市为单位的分片，如，IP为北京的访问北京机房，IP为上海的访问上海机房。

如果做到异地多活，首先要分析业务，实际上，有的业务要实现多活是比较容易的，而有的业务是很难实现多活的。

例如手机通讯录，用户之间是没有关系的，也就是说A的通讯录里面存的数据不需要和其他人有任何关系。这种数据结构非常简单，可以以用户所在城市为切分键，这样就不存在一行数据在多个数据中心同时修改的情况。假设将中国分为三个数据中心，分别为北京、上海、广州，当用户属于北京数据中心时，所有请求都访问北京。新增数据时，只要北京写入成功就返回，然后同步组件订阅数据库binlog信息，同步到其他机房汇总、备份。如图2所示。

图 2 异地多活

如果是微博、电商这种数据，选择切分键就比较麻烦。在电商中，有买家和卖家两个维度读写数据，当买家下订单后，卖家维度要及时扣减库存，生成订单。而买家和卖家很可能不在一个城市。由于一般电商都是微服务架构，一次下单操作，在后台可能是几百次请求调用，如果这些请求要在多个数据中心来回传递10次，假设每次跨数据中心要延迟50毫秒，那一次下单操作在采用异地多活架构之后就要比以前响应时间降低500毫秒，这是不能接受的。所以，我们最好能保证一次请求可以在一个机房内完成。

由于异地多活的成本比较高，不只是物理成本，还有设计、开发、维护的成本，因此，应该尽量让核心业务实现异地多活，而不是所有业务一视同仁。这个思路和数据库的扩展是一致的，如果能将一个独立的业务拆分到另外一个机房，应该优先选择这种方案，如果依赖太多，解决不了，再选择异地多活。另外一个原因是有些业务很难实现拆分，特别是一些对一致性要求特别高的服务，比如库存，异步将是致命的。

在考虑异地多活的时候，还要考虑一致性问题，前面我提到了一行数据的一致性问题，如果是整张表的一致性呢？如注册手机号，需要唯一键约束，如果分布到多张表中，无法实现一致性约束，虽然前端在写入前做了很充分的校验，但是如果一个用户进入多个注册页面，填写了校验信息，瞬间提交所有注册请求，由于异步的问题，可能导致全部成功。这时候有两种解决方案，一种是从业务的角度，这种毕竟是少数，如果前端已经做了防重复提交，那就可能存在恶意行为，应该由另外的定时任务去补偿处理。另外一种从技术角度，如果认为业务不允许出现任何不一致，此业务可以不做异地多活，可以做到多个数据中心读取，一个数据中心写入。

本文为作者原创文章，未经作者允许不得转载。