云原生时代，企业多活容灾体系构建思路与最佳实践

对于云原生的概念解读，大家经常会听到微服务、容器这些，那么这些技术跟企业容灾到底有什么样的关系？其实容灾的需求各行各业都有，比如金融行业对于容灾也有强烈的需求。但是怎么把容灾和多活能力构建起来，其实是每家企业都需要好好思考的。这篇分享希望能给大家提供一些相关思路。

今天讲的多活，其实是容灾体系里面的一块，大家可以看一下整个容灾体系架构的演进：

容灾 1.0：在原有应用系统的构建过程中，业务系统是基于传统架构部署在机房里面，那么相关的应急措施或者故障处理的办法呢？这个时期只考虑到了数据备份，主要以冷备的方式。除了提供业务的机房，另外可能会考虑到灾难场景做额外的机房。从系统建设的角度，可能会选择用单独的机房把数据同步到另外的机房做冷备，在出现问题的时候切换。但在实际情况中，平时一般不会选择切换机房，哪怕是每年做灾备系统例行演练的金融行业，在生产过程中遇到系统出了问题的时候都不太敢切换。

容灾 2.0：更多地考虑到了应用。比如云原生，或者再往上层应用在传统的 IOE 体系中，切换不仅仅是简单地切过去，把原来冷备的数据加载出来，而是希望切过去的时候可以很快速地把应用在另外的机房拉起来。为了实现数据层上的复制不会有太大延时，我们通常会有双活的要求。但是一般做双活会有一些要求，比如距离要求一定范围以内才可以做同城双活。双活更多会应用在 AQ 模式，即在生产这边做全业务，在另外机房做别的业务。

容灾 3.0：希望做成异地多活。多是什么？意思是不再局限两个机房，更希望是三个或者更多的机房。比如阿里的业务分布在多个机房，怎么同时对外提供业务的支撑，这是需要对应技术支持的。而异地多活的意思就是不局限于距离，比如 200 公里或者同城，因为如今的机房部署在全国各地。

对于业务连续性来说其实有体系化的方法，指在容灾系统建设上多年积累下来的规范和指导，这其中有几个维度：

1、多活业务并不是跟原来的容灾一样，把对等在另外一个机房一样的业务直接拉过去，而是选择有价值的业务。因为在容灾系统建设中，要把所有的业务实现多活，在成本和技术实现上是非常困难的。

2、实时性运行的保障，需要保证核心业务不会因为机房断电等各种原因停止服务。

3、M 代表保障体系。如今各行各业，可能都有自己不同的手段和管理的方式，而阿里提供的是将这一部分的东西转变为技术、工具和产品，让大家未来在构建多活能力的时候，可以很快速地基于这套方法和产品构建业务的多活。

BCM 体系和 IT 容灾恢复能力是一个偏实践的指导性框架。从完整性来讲，顶部的业务连续性是目标，下面是各种实现方式。在底部可以看到例如 IT 计划，业务连续性出现特殊问题处理故障的计划等，这些在原来做容灾的时候是会考虑到的，而我们是从多活的角度把这些东西考虑在产品体系里面。

这里提到的几个容灾方式，其实是比较常见的：从冷备到同城双活、同城双活加异地冷备（两地三中心），这些在业内相对来说都是比较规范的方式。而异地多活就好比在两地三中心的三个机房里面同时提供多活的能力，在以前的基础上，又跟原来传统的容灾有一些区别。多活在建设成本上与传统也有区别，比如构建异地多活的能力，在建设成本上比传统（例如同城双活和两地三中心）会有更多的投入。

在构建多活能力的时候，其实也会考虑到业务的实际情况。比如不同的行业，或者比如在多活方面只要求实现两边的读，那么不同情况下，建设成本以及对业务切换的时间是有区别的。异地多活能力从横向时间轴来看的话可以做到分钟级切换，但如果基于冷备的话可能需要以天来切换。

在阿里的业务模式下，为什么要做多活的原因跟前面提到的类似。前面讲到的同城加冷备，如果不采用多活就要建另外一个机房，成本非常高，因为那个机房只是用作平时的数据同步，并不处在运行状态，在这期间还需要不间断地更新生产系统对应的版本和灾备系统的版本。但实际情况下，原来的冷备或者两地三中心出现故障的时候不敢去切换，因为很有可能切换后就无法切回来。

而做多活主要有三个主要的诉求：

1、资源。随着今天业务高速发展，单地资源容量受限。我们知道云原生、云计算提供高可用、容灾的能力，但是云计算部署在不同的机房里面，跨地域多活的能力本身需要底层的基础设施来支持，我们希望把业务扩展到不受限于物理机房的限制，还达到多个机房同时接业务；

2、业务有多元化的需求，需要就地或异地部署的要求；

3、针对容灾事件。比如光缆挖断，或者天气原因机房供电散热的问题，这些都会导致单机房的故障。如今的需求希望不受限于某个机房，而是有多个机房部署在全国各地处于不同的形态，根据业务模式可以灵活调控。

因为这些诉求对多活的能力要求比较迫切，所以阿里根据自己的业务需求和技术上的能力做了多活的方案和产品。

多活架构的拆解

1、异地互备：今天大家讲云原生有多好，云计算有多好，没有多活能力这些技术其实就是闲置的状态。冷备状态时不工作，而在什么状态下要切到冷备大多要靠人的决策。由于层层上报对业务影响比较大，比较成熟的客户会有一些预案，比如什么样的影响和故障需要做这种切换，但实际上基于冷备模式的话一般不敢去做切换。

2、同城双活：有一定的距离限制，常见的双活模式在上层应用这一层，比如像云原生的 PaaS 层两面机房都可以分发。在数据这一层因为是同城可以用贮备的方式，主机房出现问题数据库方面切到备机房，但是这个好处是两边机房的机器、资源都属于活动的状态。另外，机房处于活动的状态就不用担心生产的版本跟备机房的版本有区分，不会不敢切。

3、两地三中心：除了考虑同城提供这个问题，对于故障应对能力会更强，在异地建一个冷备的机房，这个跟冷备第一个方案有类似，冷备的机房平时是不用的，可能会做一些其他的同步，只有在故障发生的时候做切换。

4、异地多活：有多个数据中心同时对外提供业务的能力。由于距离的局限，在数据层面的复制可能会受限于网络，导致延时的问题是一定会存在的。这其中有很多技术问题要解决，比如怎么做到可以很快速从北京机房切换到上海，底层的数据受物理限制情况下没有完全同步怎么去切。我们操作模式不像原来容灾的方式切换，而是要做一堆准备工作和后续数据的补偿流程。我们将这套东西融合到产品体系中，物理极限没有办法突破我们就用架构的模式来优化。

对于关键核心业务，其实在做多活系统或者项目的时候，对业务会做一些梳理，今天讲的是单元化的梳理。

递进式多活容灾架构

双读、两地三中心，一般情况下两个机房最多一半一半去分，这是最简单的。按照这种模式能找出业务切分的规则，比如可以按照用户号码，就像银行可能按照卡号或者用户所属地分成一半一半的业务。而在多活里面我们希望可以灵活去配，比如机房的处理能力多大，碰到的故障是什么样子，流量可以调成 50%、60% 或者其他比例。在多个机房也一样，可以统一分配流量接入的情况。

在技术方面，像异地互备就是单向的数据复制，异地的双活是双向的，双向的意思是这两个机房某一个机房任何一个都有可能出问题，可以互相切换。这其中很重要的是技术上的实现，在数字这一层要想办法去避免循环复制的问题，不能在把数据同步之后，另外一个机房认为是新增的数据又复制回来。而在多个机房的情况下，传统方式是在数据库内用序列号，在多活里面序列号需要规则生成具有全局唯一性，并且不是基于某一个单机房而是基于整个集群，我们需要考虑多个机房生成的序列号不能有重复，这就需要产品具备一些规则来解决这个问题。

多活产品方案的架构图

1、接入层：在多活里面第一个要解决的是非常重要的流量接入层。接入层可以很精细控制接入的规则，按照业务分片的规则，要精确到要映射到下层每一个机房，流量进来以后需要判断流量用户应该在哪个机房提供服务。这在实际情况中具体是如何实现的呢？

传统的方式是域名切换。例如前端的域名有两个机房，切换的时候把域名的地址切了，那么整个业务原来是接到机房 A 的，通过域名可以切换到另一个机房 B 。这个方法的问题在于会影响正在做的业务。举个例子，某一个机房出现问题后需要快速把业务切到另一个机房，通过域名切换的话，最底层正在进行的业务会受到影响。除此之外，这种底层切换没办法跟整个云原生 PaaS 层做联动，上层切了下层感知不到，根本不知道前面流量已经切换到另外的机房里了，包括中间的调用可能还在原来机房单元里面，这对于业务连续性来说其实受影响比较大。在极端的情况下用这种模式可以解决一些问题，比如一个机房一点业务都做不了且有备用机房的情况下，那么把域名切过去也是一种办法。

另一个办法是用云原生微服务，可以在微服务里面对流量做打标，打标完之后在云原生的微服务技术体系里面把这个标记往下传，尽可能把请求认为在某个单元或者某个机房做，不能跳到其他机房。

2、应用层：中间这一层接入路由的规范包括服务路由的组件，是我们这个产品体系里面可以单独提供的。比如一些客户说不想用全套的方案，因为方案的中间这一层用的开源组件他可能都有，但又想实现多活的能力。那么上层可以是用我们整个多活的管控切流，精确定义出来有多少逻辑的单元，并且提供 API ，供中间调用。全局唯一的序列号、路由规则和分片规则都有前面这一层提供给他。而这其中像打标和流量识别等看似比较简单，实际上例如在多活的场景里面，一些在拆分解耦的时候会用到的分布式消息，以及在架构里用到的消息，如果在某个机房没有消费完就进行了切换，那么需要用什么方式同步到另外机房，这类问题都需要借助云原生来解决。

3、数据层：涉及到复制、写入的逻辑。我们方案中的禁写管控在数据库上会有一个逻辑，即一旦在前端发生切换会自动生成代码。比如说被切换的目标机房什么时候数据恢复了，就会自动生成带时间的代码，只有当数据恢复了才会把写入的动作重新放开。我们会通过禁写来保障对数据库的保护和数据库延时的判断。如果底层数据同步能力不够强，切换及大部分业务还可以做，但很多写入的业务不一定能做了，因为数据库受禁写规则的限制。另外数据同步的规则，在多个机房逻辑下对于复制的要求在整体规则上管控更高。

基于整套方案体系，我们提出了一个概念（如上图所示）：MSHA 四个字母的缩写代表的就是今天提供云原生这一块多活产品的能力，我们希望在这四个数字上面发挥小作用：0、1、5、10 分钟的预防。

首先是 0 分钟预防，前面提到切流，可以在两个机房部署蓝绿发布的环境，这是一种方法。就算同一个机房也可以在管控台的逻辑下定义出来两个单元，很快速的在同一个机房里进行蓝绿发布。一个机房做蓝绿发布受限于技术产品的支撑，通过这个组件可以很清晰划出来，哪些资源是属于其中一个单元的，哪些资源是另外一个单元的，同时对这个单元快速去实现蓝绿发布；

第二，5 分钟定位，原来同城的比如冷备容灾技术，往往做决策非常费劲，或者谁做切换要承担后果，我们更希望基于这个平台能直观看到今天故障影响的情况，相关对应出现什么问题干系人需要做什么样的动作，或者做什么操作，把应用恢复起来；在发生故障的时候快速通过这套体系发现故障的问题，比如说通过 5 分钟定位问题后，再由它来发起决策要不要做切流；

第三，10 分钟恢复，最后，我们希望通过这套模式能把整个业务重新运作起来的整个过程控制在 10 分钟内恢复。

下面有几个例子是阿里给外部企业应用的案例，这个多活容灾能力不只有在公有云上可以用，因为云不代表当应用部署在云上面的时候，天然所有的高可用就都是由云来提供的，用资源的时候就会发现云其实有不同的区域，同一个地区含有不同的可用区。在公有云上使用的时候是需要结合实际情况的，比如大部分客户可能在南边，那么在南边的机房可能会先开一个节点，那么当阿里机房出现了问题的时候，客户的业务也会相应收到影响，虽然客户部署在云上对应的业务，云上的产品也提供高可用，但故障的场景一旦涉及到机房，对应的业务仍旧会收到影响。所以提供的方案是多活能力除了可以部署在云上，也可以跟商业软件一样部署在机房。

案例一：同城双活

某物流的客户，其实是同城的范围内使用了多活，虽然用传统的技术问题也不大，用多活的好处体现在比如说有对应的 SDK ，可以自动识别出来，不需要业务做太多的改造，可以把打标的请求自动传递下去。容灾能力在做完之后在 RTO 这块比原来快了很多。

案例二：异地双读

异地双读的这个案例难点在于异地超过上千公里。在这个距离限制下，不管是读还是写其实都有难度，数据复制本身就存在延时，用这套产品的逻辑也是希望统一从管控、流量这一层很清晰知道，哪些是读的业务，哪一些业务导入到读的机房，复制的状态是什么样的。分钟级 RTO 比原来有很大的提升，可以在线动态地做业务的灵活切换。

案例三：异地双活

使用异地双活的这个企业客户目前是有两个机房写，将来可能会往前拓展。做这个方案落地的时候做了很多产品上适配性的开发，因为要实现读的话，原来产品的基础能力，有大量的工作在中间这一层，整个过程是从多活产品研发再往前适配应用场景，再到全面跟业务做改造。核心点是业务连续性，所以不是指所有的业务将来在机房里都采用多活，而是仅针对关键的业务。举个例子，比如说每年双十一，我们核心的业务是保证下单不能有影响，那么物流通过解耦或是其他方式，从业务连续性来讲优先级不会像下单交易类这么高。核心交易链路所涉及到的服务、产品在多活的维度以什么方式保证切换的时候不会出问题才是重点。

这个多活管控平台建议大家亲身体验一下。两个或多个单元在控制台里面定义出来后，当其中一个机房出现故障时，我们希望通过多活快速把它的应用切换到另一个机房时。切换的前提是需要定义出管控台内的点，不管是单个机房逻辑的点，还是多个物理机房的点，都要映射到多活管控平台里面。在管控台内我们会配一些规则，比如说单一化业务的接入，以什么维度去切分接入的流量，或者以 ID 的方式标记。在切流的时候动态显示哪些维度的流量到另一个机房，出现故障的时候可以快速去配，这就相对比较简单。

如今我们帮助客户部署能力，也会经常在体系里面通过控制台做一些切流和演练，来看一下这个机房是否受到一些影响，因为整个系统里面还配套其他的一些方案，比如做故障演练，配合这些故障把应用切换到另外一个机房等等。

多活容灾的能力在阿里内部业务中已经实践很多年，将其演变成产品也花了很长时间，目的是希望今天这套产品和方案可以帮助企业在 30 天以内就可以构建起来自己的多活能力。特别是公有云上有很多产品部署都已经是现成的企业，其实构建起来时间耗费会更短。我们希望通过这套产品和方案多活的能力可以帮助企业快速在分钟级实现故障的切换和多活能力的构建。