从传统 IT 容灾转向“全栈云容灾”｜什么是更适合政企的云

凌晨 3 点，在某医院的自助缴费机前，一位医患家属正愁眉紧锁，手中的医保卡已经刷了无数遍，可次次都提示缴费失败，至亲的手术已经迫在眉睫…

早上 8 点，是上班族在通勤途中打开新闻 app 刷新闻的高峰，而此刻在新闻编辑室内，后台编辑正焦头烂额，系统上当日热点大新闻的发布界面一遍遍显示“发布失败”…

这些画面简直是企业 IT 管理者心中的“灾难大片”，而导致这些问题的原因可能是企业数据中心中某个机柜断电、某次台风导致机房故障、某位 IT 管理员一不小心删除了数据库…

天灾人祸或许难以避免，但是上述场景却可以通过 IT 架构设计来规避预防。在云计算时代，面对黑天鹅事件，IT 人员如何利用容灾方案来保证业务连续性？云平台的容灾和传统 IT 容灾究竟有哪些不同？哪些因素影响着政企云平台的容灾设计？阿里云又有怎样的解决方案？这篇文章，将一一给出答案。
在这里插入图片描述

数智时代的双刃剑，云计算的普及让容灾课题变得更为紧迫

随着全行业的数智化转型不断深入，云原生应用已经成为各界公认的数字化转型范式，而承载云原生应用的底座 —— 全栈云计算平台，则成为政企数智化转型的坚实底座。

云计算本身具备的“集约化建设、统一大资源池、统一服务供给”的模式，让应用天然在云平台上大量汇集，一方面释放出平台资源弹性供给和敏捷调配的优势，另一方面也意味着一旦平台出现故障，影响范围会更大。为了保证业务层面连续性，云平台高可用能力成为现在政企 IT 掌舵者所关注的重中之重。
在这里插入图片描述

虽然云平台在设计之初，已经具备了初步的高可用能力，诸如组件多副本、数据跨服务器机柜、网络机架打散等，但这只能做到“单机房高可用”。对于金融、税务、医保、能源等行业来说，他们对于系统的业务连续性有更高的要求。比如金融行业有明确的跨机房容灾政策要求，且核心业务系统故障达 30 分钟则需要上报上级监管单位；国家、省级医保信息系统必须采用同城容灾模式来满足业务连续性要求。因此，基于全栈云产品的跨机房容灾成为了部分政企客户的强需求。

新瓶为何不能装旧酒？传统 IT 容灾技术在云时代面临的困境

传统 IT 容灾经过多年的沉淀，目前有两种常见的技术路线：

存储级容灾

这种技术主要以传统的阵列存储为主，在两个机房放置相同的存储机型，通过阵列间的“同步复制”或“异步复制”等模式，实现数据在双中心的同步。
典型存储级容灾示意图

在该模式下，为了避免数据双写，备中心的计算节点及应用日常处于停机状态，即处于“冷备”。这就意味着，当一个数据中心发生故障后，需要先切换到备中心的 IT 设施，然后再逐个启动备中心的计算节点和应用程序，结果必然带来较长的 RTO。另外，该模式下还存在着应用无法正常启动的可能性，进一步延长 RTO。

随着云原生的发展应用，业务应用一般会被分散到动辄数百甚至数千个节点，对如此规模的节点和应用进行重新启动，RTO 必然会被大幅拉长，也无法满足最基本的恢复时间要求。另外，传统阵列在扩展性、成本等维度也不满足云计算的基本技术架构要求。

产品级容灾

这种技术的特点是产品自身可实现“工作节点的跨机房转移和数据跨机房的复制”，不依赖于底层存储。对外服务层面，一般采用主备、双活等模式。数据层面，产品通过自身的机制实现跨机房数据复制，如 Mysql 的 binLog 复制等。

典型数据库容灾复制架构

由于备机房产品也是正常的工作节点，只是日常角色为备，不接受流量。当主机房完成切换后，备机房节点立刻可用。因此，不会存在切换到备中心后实例不可用的异常情况，业务的 RTO 一般要小于存储级容灾架构。

从整个业务维度来看，该模式相比存储级容灾的可控程度更高、RTO 更好。但该技术只负责应用的某一层技术栈如 DB，缺乏全局业务视角的业务容灾能力。

在云原生条件下，应用会基于 IaaS、中间件、数据库、大数据等全栈云产品进行构建，数据也分散在大量不同的产品，容灾架构也必须基于全栈产品视角，进行端到端的重新设计。

给云上掌舵者的考题，全栈云容灾考量公式

基于上述分析，传统 IT 技术架构难以满足云原生的业务模式，这时就需要全栈云容灾解决方案登场了。作为 IT 管理者，全栈云容灾是一个全新的复杂命题，又有哪些问题需要考虑呢？这里引入一个公式帮助 IT 掌舵者来进行评估判断：

全栈云容灾复杂度 =（产品数量 X 产品依赖 X 切换场景 X 容灾指标）/ 容灾管理体验

产品数量多

一个业务系统需要使用十几个甚至几十个云产品，业务牵涉到的所有云产品及支撑产品都需要具备容灾切换能力。同时，数据存储类型相比传统 IT 大大增加，常见如块存储、对象存储、OLTP 数据存储、OLAP 数据存储、离线大数据存储、日志存储等。为了达到跨机房容灾效果，在选择云平台时，IT 管理者需要确保这些产品均要具备“跨机房数据同步”和“跨机房高可用”的能力。
某阿里云客户所使用的主要云产品统计

产品依赖多

为了实现云产品的高可用，降低产品的重复开销，云平台在设计时，一般会将产品组件和依赖组件进行拆分，如把 DNS、NTP、元数据库、分布式协调服务等作为底座组件来统一对上层云产品提供服务。因此，容灾切换需要考虑到底座及产品依赖，避免产品切换后，因为缺少依赖而导致报错或无法使用。

容灾场景多

跨机房故障场景类型较多，每种产品都需要同时考虑“机房断电、脑裂、网络中断、故障回切”等多种场景下的数据复制策略和切换预案，以最快的速度实现业务恢复和保障数据安全。

容灾要求高

云时代的业务故障影响面更大，容灾相比传统 IT 架构需要更高的 RTO 和 RPO 要求。如中国人民银行发布的《云计算技术金融应用规范容灾》中对于 RTO 和 RPO 的具体要求如下：
在这里插入图片描述

容灾管理体验

鉴于上述的“三多一高”问题，全栈云的容灾管理也成为一个难题，容灾管理最好能具备如下能力：

简单切换：一次容灾切换可能同时牵涉到几十款产品的容灾协同，无法再通过传统手工的方式逐个执行产品切换，因此云平台必须具备高效的演练和切换能力，降低 RTO。
全场景覆盖：容灾设计需要兼顾同城、异地、两地三中心等多种容灾场景，且可随着政企容灾架构的演进在各场景持续进行迭代。
租户隔离：在多租户场景中（云平台需要对外提供运营和服务），需要支持各租户进行自助容灾，同时单个客户不同系统可以按需进行切换，且保证容灾切换对其他客户的业务无影响。
可控容灾：云平台需要具备完善的容灾监控体系，用户可随时掌握最新容灾动态，并与内部的容灾预案流程相结合，确保系统时刻处于“可控、可预知”的状态，避免“非预期切换”造成的数据安全风险。

更强实力更有底气，阿里云是全栈专有云容灾的开创者

从上述全栈云容灾的特点和需求来看，全栈云容灾考验的是云厂家对全栈产品的掌控和驾驭能力，需要对所有产品具备代码级的架构修改和功能迭代能力，以及完善的产品工具支撑体系。唯有如此，才能提供成熟、稳定、可迭代的容灾服务能力。这也正是阿里云全栈自研的优势所在。

阿里云于 2015 年推出飞天企业版，采用与公共云同样的技术架构，为政企客户提供全栈产品服务能力。在帮助客户完成“建云”“上云”过程后，基于客户普遍的高业务连续性要求，阿里云在业内率先进行基于专有云的跨机房容灾研发。经过广泛的用户需求调研，阿里云“采用应用级容灾思路、基于全栈产品视角，以应用端到端恢复为出发点”，于 2017 年正式推出飞天企业版容灾解决方案，在业内开创了全栈专有云容灾的新范式。

经过多年技术迭代，飞天企业版容灾解决方案的能力不断加强：

2017 年，支持同城双 AZ 容灾，支持 20+ 云产品容灾；
2018 年，在金融、政务等多个客户完成同城容灾项目交付，具备生产级容灾能力；
2019 年，支持异地跨云容灾、异地多活容灾，并在多个政务客户完成交付；
2020 年，支持同城 3AZ 容灾，业内率先实现了基于云原生条件下的数据库 RPO=0，多个银行客户进入 3AZ 容灾阶段；支持多对一异地容灾，支持了某省医保“省级同城容灾、省市间多对一异地容灾”建设模式；
2021 年，支持全栈产品级的两地三中心容灾，满足金融等行业同时具备同城、异地容灾的政策要求；
2022 年，支持基于国产化芯片的容灾能力，各场景下的容灾能力得到大幅提升，满足了政府、金融客户在一云多芯的需求下的容灾形态要求。

基于全栈云容灾的需求，阿里云飞天企业版容灾解决方案构建起“多边形战士”的能力：

支持产品最多

飞天企业版已完成 IaaS、中间件、数据库、大数据、底座等全栈 60+ 产品在不同场景下的容灾架构设计，可以满足不同行业客户应用层端到端容灾的需求。

支持场景最全

鉴于客户不同的容灾模式需求，飞天企业版支持同城双 AZ、同城三 AZ、异地跨云容灾、异地跨 Region 容灾、异地多活容灾、异地多对一容灾、两地三中心容灾等多种原子容灾场景，可以基于不同业务特点，将上述原子容灾场景进行排列组合，形成更复杂的组合容灾场景，如“同城容灾+异地多活”、“同城容灾+异地多对一容灾”等模式，具备“全场景容灾”的能力。
在这里插入图片描述

容灾管理简单

针对全栈云的容灾管理难题，阿里云在业内开创性地推出业务连续性管理平台 ASR（Apsara Stack Resilience）。ASR 以可视化方式，通过多场景适配，提供容灾状态监控、故障注入与演练、容灾切换与回切、租户隔离等能力，将复杂的“产品切换逻辑、产品间依赖、机房级切换”等内部逻辑进行编排和封装，使运维人员无需关心复杂的内部处理逻辑，可以“一键”完成全栈产品的容灾演练和切换。此外，ASR 大大降低了全栈云容灾演练难度，用户可以按需定期演练，杜渐防萌，确保“故障时刻敢切换”。
在这里插入图片描述

应用友好，降低 RTO

租户通过域名或者 vip 来访问云产品，云产品的容灾切换会保证云产品容灾实例的访问地址不变，因此可以做到容灾切换时产品的容灾能力对应用透明，可以极大降低应用恢复的时间。

RPO=0，满足等高阶容灾要求

金融等对数据可靠性要求较高的行业，往往要求 RPO=0。阿里云率先推出基于云计算分布式技术体系的同城 3AZ 容灾模式，通过在多机房部署数据副本，满足任意条件下的单机房故障 RPO=0，达到《GB20988-2007-T 信息安全技术信息系统灾难恢复规范》和《JR/T 0168-2020 云计算技术金融应用规范-容灾》的最高等级要求。