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

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

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

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

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

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

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

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

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

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

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

1. 存储级容灾

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

典型存储级容灾示意图

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

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

2. 产品级容灾

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

典型数据库容灾复制架构

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

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

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

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

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

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

1. 产品数量多

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

某阿里云客户所使用的主要云产品统计

2. 产品依赖多

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

3. 容灾场景多

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

4. 容灾要求高

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

5. 容灾管理体验

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

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

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

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

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

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

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

1. 支持产品最多

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

2. 支持场景最全

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

3. 容灾管理简单

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

4. 应用友好，降低RTO

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

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

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

五 稳中求进 —— 让全栈云容灾成为数智创新的稳定底盘

阿里云飞天企业版凭借在产品支持范围、功能满足度、场景覆盖度、易用性、安全隔离等多方面的成熟度，已经为金融、政务、能源、电力、交通、制造、医疗等各行业数百位客户提供全栈云平台容灾产品服务。

IT架构的演进势不可挡，随着政企不断在云平台上迁移、构建创新应用和核心应用，由传统IT容灾向全栈云容灾转身越来越急迫。阿里云以飞天企业版容灾解决方案为各行业数智转型提供坚实的云底座支撑，让“稳定”从一次选择，变成持续承诺。

原文链接

本文为阿里云原创内容，未经允许不得转载。