共计 4370 个字符，预计需要花费 11 分钟才能阅读完成。
凌晨 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 容灾向全栈云容灾转身越来越急切。阿里云以飞天企业版容灾解决方案为各行业数智转型提供松软的云底座撑持，让“稳固”从一次抉择，变成继续承诺。
原文链接
本文为阿里云原创内容，未经容许不得转载。
