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

容灾系统职能演进

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

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

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

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

业务连续性以及容灾概述

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

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

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

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

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

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

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

标签： IDC、 IDC、 互联网数据中心、 数据备份、

本文地址： https://yihaiquanyi.com/article/746f45ac02cecfa5707a.html

上一篇：零售和批发的差别零售VS批发国内IDC市场趋...
下一篇：产业链深度解决方案产业链深度解析算力时代...