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

​

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

容灾零碎职能演进

​

​

明天讲的多活，其实是容灾体系外面的一块，大家能够看一下整个容灾体系架构的演进：
​

容灾 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 天以内就能够构建起来本人的多活能力。特地是私有云上有很多产品部署都曾经是现成的企业，其实构建起来工夫消耗会更短。咱们心愿通过这套产品和计划多活的能力能够帮忙企业疾速在分钟级实现故障的切换和多活能力的构建。

解决方案征询技术交换群：搜寻钉钉群号 31704055 退出钉钉群，可获取云原生具体解决方案材料与专家答疑。

解决方案征询技术交换群
（注：进群申请请提供公司、职位、姓名）

版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。