借“云”飞天：云原生时代异地多活架构设计新范式

摘要： 随着数字化转型的加速，企业对于应用系统的高可用性、高性能和可扩展性提出了更为严苛的要求。云原生技术的兴起为异地多活架构的设计与实现带来了全新的机遇与变革。本文深入探讨云原生如何赋能异地多活架构，详细阐述其关键技术与实践策略，并分析在云原生环境下构建异地多活架构所面临的挑战与应对措施，旨在为企业在云时代构建健壮、灵活且高效的分布式系统提供全面的技术参考与实践指南。

1. 引言

当今互联网化与数字化深度融合的商业环境中，企业的业务连续性和用户体验已成为竞争的核心要素之一。无论是电商平台的购物高峰、金融服务的实时交易，还是在线娱乐的海量并发访问，任何系统中断或性能瓶颈都可能导致用户流失、业务受损以及品牌形象的负面影响。

异地多活架构作为高可用架构的终极解决方案，通过在多个地理区域部署相互协作的业务节点，实现了服务的就近接入、数据的多副本冗余以及故障的自动切换，从而极大地提升了系统整体的可用性，即便发生灾难级别的事故，也可以尽量保证业务的连续性，降低甚至避免企业遭受业务上的损失。

然而，传统的异地多活架构构建与运维面临诸多挑战，如复杂的基础设施配置、繁琐的应用部署与管理、数据一致性保障的难题以及高昂的人力与资源成本等。我自己做过异地多活架构，也和很多同行交流过异地多活架构，也作为培训讲师给银行、电信巨头讲过异地多活架构设计。总体感觉是大家普遍觉得异地多活架构很重要，但是落地异地多活架构的时候，都会觉得复杂度很高，难度很大，投入也很大。

云原生技术的出现，以其容器化、微服务化、弹性化、云产品化等核心特性，为化解这些困境提供了创新的思路与强大的工具集。借力云原生强大的基础设施能力，企业设计和落地异地多活架构设计的难度大大降低，既能够让不同的业务能够快速落地异地多活架构设计，又能够避免为了异地多活架构而对已有系统进行大规模的改造，还可以将成本控制在可接受的范围之内。

2. 异地多活现状和挑战

当我们的业务量级达到一定规模后，团队自然就会开始考虑异地多活架构的设计，但是当我们真正开始进行异地多活架构设计思考的时候，会发现异地多活架构设计远远比我们预想的要复杂，具体体现在如下几个方面：

1）很难保证所有业务都实现异地多活

比如说强一致性的库存、余额；又比如说数据冲突不好处理的用户注册、游戏里的唯一道具购买等。

2）很难实现完美的异地多活

受限于FLP定理和CAP定理的约束，以及目前远距离网络传输固有的网络时延，例如广州到北京最好的情况也是30ms，一般1000公里以上的时延是50ms，我们在设计的时候会发现总会有一些异常场景，我们没办法做到完美。

3）存储系统能力很难满足异地多活的要求

比如说MySQL的同步可能出现比较长的时延，比如说Redis可能丢失1s的数据等。

4）基础设施要求高

异地多活架构对于机房、网络、硬件等都有技术上的强要求，例如网络时延、流量调度、弹性计算、数据复制等。

因此目前真正落地异地多活架构并且取得成效的，一般都是规模比较大的公司和业务，例如：淘宝、微信、美团等。即使是大公司，我们也会发现不同的业务的异地多活架构方案不同，基本上不同的业务线可能要自己做自己的异地多活架构设计。而对于很多规模没那么大的，技术储备没那么强的企业来说，只能望“异地多活”而兴叹！

3. 云原生时代的异地多活架构设计

那么如何降低异地多活架构设计的复杂度和成本呢？云原生是一个答案，其中的关键是云厂家提供的各种功能强大，技术先进的云产品。

云厂家本身就具备了非常雄厚的技术实力，为了在市场竞争中取得优势，云厂家在云产品上会投入大量的人力物力来提升产品竞争力。因此很多云产品在设计和实现的时候已经设计了分布式的弹性架构、高可用的架构，而这些特性正是异地多活架构设计的复杂点和关键点。

如下是某云厂家自主研发的一款云原生数据库产品的介绍，可以看到其融合了传统数据库、云计算与新硬件技术的优势，为用户提供具备高弹性、高性能、海量存储、安全可靠的数据库服务。

异地多活架构设计总体上可以为3大设计：网络设计、计算设计、存储设计，接下来我们详细探讨云原生对异地多活意味着什么，云原生时代又应该如何去落地异地多活架构。

异地多活网络架构设计

首先我们来看看异地多活架构的网络设计部分。

由于异地多活的主要应用场景是应对机房级别的灾难（例如机房断电、机房火灾）和城市级别的灾难事件（例如城市大停电、水灾、地震、龙卷风等），因此异地多活网络设计核心就是当灾难事件发生后，能够把用户的访问流量快速切换到其它正常的机房。如果仅仅依赖传统的DNS是无法做到这一点的，因为DNS的缓存不可控，浏览器、JVM、操作系统等都可能缓存DNS解析结果，而且缓存的时长还各不相同。

在没有云计算的年代，如果要自己实现流量快速切换的话，通常有两种方式：

1）对于中小公司和团队来说，一般会自己来实现HTTPDNS，简单来说就是基于HTTP来实现私有的DNS解析。HTTPDNS适合App类的业务，因为需要在App内嵌入HTTPDNS的SDK来实现域名解析的功能。

2）对于大公司来说，一般采用GSLB（Global server load balancing）技术。GSLB融合了状态监控和动态路由的功能，在故障的时候能够快速的隔离故障机房，切换流量到正常机房。

对于HTTP-DNS来说，虽然技术复杂度不高，但是要自己实现一套HTTP-DNS系统的话，工作量不小，主要原因是HTTP-DNS本身的功能点不少，而且还要App做改造；而GSLB无论是实现的技术复杂度，还是部署的成本都比较高，这也是能用上GSLB的一般都是大公司的原因。

既然我们说云原生是技术的未来，那么云原生技术如何实现异地多活的流量快速切换呢？其实很简单：云厂家把HTTP-DNS和GSLB做成通用云产品，我们直接购买这类云产品即可。无论是HTTP-DNS还是GSLB，本身的技术实现是业务通用的，无论你是电商业务还是IM业务，使用HTTP-DNS和GSLB的方式都是一样的。

例如，如下是某云厂家提供的HTTPDNS的产品，基于 HTTP 协议 进行DNS解析，可以面向多端应用，包括移动端APP/PC客户端应用的域名解析服务，避免域名劫持和跨网访问问题，实现精准调度，解决移动互联网服务中域名解析异常带来的困扰，其基本原理如下：

异地多活计算架构设计

接下来我们看看异地多活架构设计的计算部分。

这里的计算我们定义为“无状态处理”的部分，可以简单理解为就是我们的应用程序。对于一个应用程序来说，无论在A机器运行还是在B机器运行，只要代码是一样的，其运行逻辑就是一样的。正因为计算的无状态特点，在异地多活架构设计的时候，计算部分反而是最容易的，简单来说就是：如果A机房的应用程序挂了，我们在B机房将应用程序起来就可以了。

虽然原理上看起来很简单，但是在落地的时候其实有很多细节要考虑。

首先就是成本。传统的异地多活架构，为了在故障的时候由正常的机房接管业务，每个机房都是需要预留处理资源容量的。最简单的异地双活，为了保证在一个机房故障的时候，剩余机房能够接管所有的业务流量，两个机房处理资源都要按照100%来配置，平时各自承担50%的业务流量，进入异地多活应急的时候，其中1个机房处理了100%的业务流量。这样就会导致50%的处理资源在平时正常的时候是闲置的。虽然说很多公司财大气粗，但50%的闲置资源其实成本还是不小的，尤其是如果你运气好，可能3~5年都用不上，这样算下来的成本其实还是很可观的。

那自然我们就会想到：如果平时的资源按照正常的业务处理量来配置，当需要异地多活的时候快速搭建是否可行呢？在传统IT年代，这样做是非常困难的。

首先，物理资源很难快速准备，如果平时就准备好放在机房但是不用，这其实也是一种浪费。

其次，就算物理资源闲置不是问题，快速搭建能完整运行的系统也是非常难的。

我们单看一个应用的话，那肯定是容易的，但是异地多活的应用场景是机房级别的故障，这就意味着整个机房的所有应用都需要重新搭建，包括应用程序的版本、相互依赖的配置等其实是非常复杂的，只要有一点点错误，整个业务就无法正常运转。这也是很多传统企业的灾备中心在真的要用的时候基本启动不起来的原因，要么应用程序版本不对导致无法启动，要么配置有问题导致业务处理出错等。

幸运的是，云原生可以很好的解决上面说的问题。

首先，云计算的资源是可以动态申请的，云厂家本来也会有很多可供调配的资源，这些资源平时你不买就不用花钱，假如为了异地多活应急要临时买几天，一旦故障修复后，这些临时买的资源又可以释放。这样的话成本就比一直买了然后放着不用要节省非常多。举个最简单的例子：假如你的业务2年启用一次异地多活应急，每次应急2天时间，通过云计算的弹性资源购买，你只需要买2天的资源即可；而如果自己一直冗余的话，相当于要承担730天的成本。

其次，云原生时代的容器技术，可以很方便的快速搭建整套系统环境。以K8s为例，只要你的K8s相关配置文件（集群配置，容器配置，业务配置）没有丢失，那么重新启动一整套K8s环境是很方便快捷的，也不用担心程序版本和配置文件和之前的不一样。

当然，并不是说目前的云计算就已经天然的具备了异地多活架构的能力，毕竟在启动异地多活应急的时候，时间就是金钱，速度就是生命，如果到了要开启异地多活应急的时候，再去云厂家的官网上去购买资源，然后再去部署，无论你手速多么快肯定至少都要几个小时了。因此，云原生时代如果想方便的落地异地都活架构，是需要云厂家或者企业来设计完整的解决方案实现“快速扩容”。

异地多活存储架构设计

最后我们来看看异地多活架构设计的存储部分。

异地多活架构设计最难的部分就是存储架构的设计，很多技术人员在设计异地多活架构的时候，可能会有一种猜想：大厂是不是有什么黑科技能够完美的实现异地多活呢？

其实根本没有什么黑科技，异地多活存储架构设计的难度主要受限于两个约束：

一是异地网络传输的限制，相距1000公里左右的两个机房，时延一般是50ms左右，最好也不会低于30ms，这个时延的理论基础是光速（可能是人类永远无法突破的物理限制），再加上网络传输过程中的各种网络设备的处理时间。

二是两个理论的限制：FLP不可能原理和CAP定理。

FLP不可能原理说明了异步通信网络场景中，假设网络正常，只有一个节点失效的情况下，也没有任何确定性算法能保证非失败进程能够达成一致（FLP理解起来还是需要花费不少功夫的，本文不做展开）。

CAP定理说明了通过复制来实现数据可靠性的分布式存储系统，无法同时满足一致性（Consistency）、可用性（Availability）、分区容忍性（Partition tolerance）。

我们在异地多活设计的时候如何应对上述的两个限制呢？核心的思想其实还是“取舍”。目前已经落地的异地多活架构有如下几种常见的做法：

1）容忍数据不一致：异地机房通过数据复制来保证高可用，但是如果因为时延丢掉了一些数据，虽然可能造成一些用户体验问题，或者导致一些业务错误，但只要这些问题不那么严重，业务上能够接受，那就直接在异地机房提供服务即可，然后等故障机房恢复后，再来进行数据修复和业务修复等处理。

2）缩短异地机房的距离，改为近邻城市部署，例如国内常见的广深、京津、成渝、沪杭这四个城市组。因为城市距离近，分布在两个城市的机房时延可以做到10ms以内（与之对比，同城两个机房时延一般是2ms以内），这样的时延对绝大部分业务来说都是足够的，即使出现机房故障，数据一致性虽然不能说100%没问题，但因为时延导致的数据丢失的量是极少的。

近邻城市部署还有另外一个非常适合的应用场景：如果数据一致性要求特别高，近邻城市是可以支持基于分布式协议算法实现的分布式强一致性数据库的部署。通过基于Paxos或者Raft这类分布式一致性算法，分布式强一致性数据库能够实现跨机房的一致性，而不会像传统的主备复制数据库那样，一旦要求强一致性就只能主机写入。

看起来近邻部署很完美，那么这个架构方案“舍”了什么东西呢？答案还是在“近邻”二字上面，简单来说就是正是因为距离太近，一旦发生“区域”级别的故障（例如地震、美加大停电、龙卷风等），那么可能出现两个城市的机房全部故障的极端情况。

那如何应对这种极端情况呢？考虑到这种故障发生的概率很低，一般都是采用三地五中心的部署架构：近邻的两个城市之外挑选一个远距离的城市，作为灾备机房；两个近邻城市部署4个节点来满足分布式一致性算法的“多数一致”要求，远端城市部署一个节点用于满足极端灾备要求。

了解到现状后，我们来看看云原生时代，我们如何来做异地多活架构设计。

首先要明确一点，云原生只是一种技术形态，它再怎么厉害也不可能突破前面讲到的光速和“FLP+CAP”两大理论的约束，因此即使是云原生，异地多活的存储架构模式是没有变化的，变化的是云原生提供的存储产品可以提供更强大的能力，例如更快的复制速度、更高的可用性、更强的一致性、更方便的切换能力。

首先，如果我们的业务对一致性要求不高，那么可以采取远距离部署异地多活机房，然后基于云厂家提供的强大的低时延网络，自行设计多活的数据同步方案， 例如CDC（Change Data Capture，变更数据捕获）方案、Event sourcing（事件溯源）方案等；也可以基于云厂家提供的支持异地快速复制和快速恢复的云存储产品。

其次，如果我们的业务对一致性要求很高，那么可以采用支持分布式一致性（基于Paxos、Raft等算法实现）的云原生存储系统，采用“两地三中心”甚至“三地五中心”的部署架构，支持业务多点写入，故障自动切换的能力。

如下是一个简化的“三地五中心”的部署架构示意图：

三地五中心部署架构图

如上图，简要说明如下：

1）城市1和城市2距离较近，满足IDC-1和IDC-2时延10ms以内（时延越小越好）；

2）城市3距离城市1和城市2都比较远，主要用于灾备，只需要部署一个节点Node-5；

3）IDC-1和IDC-2各自部署2个节点，在分布式一致性算法投票的时候，只要有3个Node投票一致就投票成功。由于IDC-1和IDC-2的4个节点之间时延很小，基本不影响分布式一致性算法的性能。

4）IDC-3的Node-5如何参与分布式一致性算法，如何复制数据等机制的设计比较灵活，不同云产品的取舍可能不同。

5）IDC-1和IDC-2的微服务应用可以同时写入数据，存储系统会自动根据分布式算法决定具体写入到Node-1到Node-4中的主节点；单个节点故障后，系统会自动选举出新的主节点。

总结

前面我们分别从网络、计算、存储3个维度来分析了异地多活架构设计的现状以及云原生时代的技术趋势和选择。总体上来看，相信你可能会有这样一种感觉：云原生时代做异地多活架构，基本上只要买买买就行了，技术的复杂性和挑战都已经由云厂家封装在各类云产品里面了。

事实也基本如此，这也正是云原生技术之所以是未来技术趋势的一个很大原因，简单来说：只要和业务无关的技术，都应该交给云原生去解决，而剩下的需要架构师做的事情主要有两类：

1）选取适合业务的异地多活模式

分析自己的业务特点，决定采取弱一致性的异地多活架构还是强一致性的异地多活架构，毕竟强一致性的异地多活架构成本是比较高的，例如三地五中心架构的成本还是很高的。

2）选取合适的云产品。

现在的云厂家众多，各个云厂家也都提供了很多云产品，不同的云产品能力和适应场景是有差异的，找到最合适自己业务的云产品，既需要对自己的业务特点有深入的理解，也需要对云厂家的产品有深入的研究。

即便如此，云原生时代异地多活架构总体设计难度肯定会大大降低，“旧时王谢堂前燕，飞入寻常百姓家”，在云原生时代，相信会有越来越多的公司和业务能够方便快捷的落地自己的异地多活架构！