共计 3669 个字符，预计需要花费 10 分钟才能阅读完成。
作者：Tina
互联网技术倒退到了 2021 年，上云也更加广泛，但宕机事件却仿佛没怎么缩小。
这一年 10 月，领有 30 亿用户的脸书 (Facebook) 遭逢大规模宕机，中断服务约 7 小时后大部分服务才从新上线。据说，这是 Facebook 开办以来最重大的一次网络拜访事变，导致脸书一夜之间市值蒸发约 473 亿美元 (约合 3049 亿元人民币)。
而在更早些时候，国内某视频网站也因机房故障导致网站解体，大量用户“漂泊”到其余网站，微小的流量洪峰又让其余平台也连锁式瘫痪了。此外，领有 15 万家客户的 Salesforce 在这一年也遭逢了一次长达 5 个小时的寰球性质的宕机事变，在线游戏平台 Roblox 还曾产生过长达 73 小时的宕机事变 ……
互联网技术倒退到当初，实践上来说是能够做到“永不宕机”的，但为什么还有这么多规模大、工夫长的系统故障产生？如何缩小宕机事变的产生？InfoQ 采访了阿里云全局高可用技术团队，谈谈如何保障简单零碎中的业务可持续性。
从泛滥宕机事件说开去
云计算的蓬勃发展，催生了越来越多的“国民级利用”，但传统的灾备架构已很难满足业务疾速复原的须要。
有统计数据表明，96% 的企业曾在过来三年中至多经验过一次零碎中断。对于小型企业来说，一小时的宕机工夫会均匀造成 25,000 美元的损失。对于大型企业来说，均匀老本可能高达 540,000 美元。现在，停机工夫越长，这意味着产生永久性损失的可能性越大。
然而宕机事变又不可预测，因而它也被称为零碎中的“黑天鹅”。阿里云全局高可用技术团队负责人周洋示意，以后大型互联网零碎架构日趋简单，稳定性危险也在升高，零碎中肯定会有一些没被发现的黑天鹅潜伏着。
尽管预测不了“黑天鹅”什么时候会呈现，然而能从故障中去寻求一些分类，并有针对性地对一类问题进行进攻。比方当初的容灾架构就是一种劫难进攻伎俩，它次要针对的是机房级的故障场景。
机房级的故障场景，从 IDC 的维度上看，次要有机房入口网络故障、机房间网络故障以及机房掉电。如果精细化到应用层，又能够分为接入网关故障、业务利用故障以及数据库故障等，背地的故障起因可能是软件 BUG 或者局部硬件故障，比方机柜掉电、接入交换机故障等等。
容灾架构的指标是，在单机房呈现任何故障的状况下，可能疾速复原业务，保障 RTO 和 RPO。
RTO（复原工夫指标）是指用户违心为从劫难中复原而破费的最长工夫。一般来说，数据量越大，复原所需的工夫就越长。
RPO（复原点指标）是指在产生劫难时用能够接受的最大数据失落量。例如，如果用户能够接受 1 天的数据失落，RPO 就是 24 小时。
RTO 和 RPO
针对不同品种的故障，灾备行业有三种不同等级的进攻形式：数据级、利用级、业务级。当初业内支流的容灾架构还是灾备容灾，属于数据级的容灾计划。因为灾备核心平时不工作，应用服务的完整性和运行状态未知，在产生故障的关键时刻会面临敢不敢切的问题。
有些企业会因为无奈确定是否承载流量而不敢切，有些决定切换的企业也可能因为备用机房的利用状态不对而不能完全恢复业务，最终造成的影响就是 RTO 或者 RPO 较长，反馈给外界就是大型“宕机”事件。
起源自阿里实际的 AppActive
2021 年，国内外多家出名公司、云平台呈现较重大服务中断、宕机事件，为企业敲响了警钟，越来越多的企业把容灾建设提上日程。在解决容灾问题的同时，为放弃对老本的管制、撑持将来的多云架构演进和劫难容灾的确定性，许多企业抉择尝试采纳多活容灾的形式。
当劫难产生时，多活容灾能够实现分钟级的业务流量切换，用户甚至感触不到劫难产生。利用多活针对不同的部署场景有三大典型架构：在同城机房物理间隔小于 100 公里的场景下建设同城利用多活，在异地机房物理间隔大于 300 公里的场景下建设异地利用多活，在混合云多云交融的场景下建设混合云利用多活。在多活模式下，资源不闲置不节约，而且可能冲破单地区的机房容量限度，从而取得跨地区的容量扩展性。
多活容灾在阿里外部实际了多年。早在 2007 年到 2010 年，阿里巴巴就采纳同城多活架构撑持业务容量和可用性。
到了 2013 年，因为机房容量无限以及杭州机房无限电危险，阿里巴巴开始摸索异地多活的架构计划，那就是起初大家都晓得的所谓“单元化”。单元化架构在 2014 年实现了试点验证，2015 年正式在千里之外实现三地四核心，从而具备了生产级别的异地多活能力，2017 年实现了在双 11 凌晨切流。
2019 年，阿里巴巴零碎全面上云，异地多活架构追随上云的节奏孵化成阿里云云原生产品 AHAS-MSHA，服务阿里巴巴和云上客户，先后帮忙数字政府、物流、能源、通信、互联网等十余家不同行业中的大型企业胜利构建利用多活架构，包含菜鸟农村同城利用多活、联通新客服异地利用多活、汇通达混合云利用多活等。
在采访阿里云全局高可用技术团队时，大家广泛的感触是，“业内对于多活没有对立的认知，并且器重度不够。”
首先，不同的人对于“多活”这个词会有不同的定义，人人都说本人是“多活”，可当故障降临的时候，才发现以后零碎并不是真正的多活。其次，有些企业并不理解异地多活，有些理解的企业会认为异地多活的老本高、难落地。还有些企业在理解“多活”之后，下意识想要先在企业外部投入资源进行技术预研，抗拒云厂商的商业化产品输出。
“多活”的认知偏差会让使用者错用或者不必，从而享受不到“多活”带来的稳定性红利。
在阿里云全局高可用技术团队看来，利用多活将成为云原生容灾畛域的趋势，与其期待趋势到来，不如通过开源来推动利用多活的倒退。他们心愿通过开源协同，造成一套利用多活的技术规范和规范，使得利用多活技术变得更易用、通用、稳固和可扩大。
2022 年 1 月 11 日，阿里云将 AHAS-MSHA 代码正式开源，命名为 AppActive。这也是开源畛域首次提出“利用多活”概念。
我的项目地址：
https://github.com/alibaba/Appactive
阿里云开源业内首个利用多活我的项目 AppActive，与社区共建云原生容灾规范
AppActive 的实现与将来布局
阿里云也曾在 2019 年开源了本人的混沌工程项目，旨在通过混沌工程帮忙企业解决云原生过程中的高可用问题。AppActive 更偏进攻，ChaosBlade 更偏攻打，攻防联合，造成更加健全的落地平安生产机制。
ChaosBlade 我的项目地址：
https://github.com/chaosblade-io/chaosblade
ChaosBlade：从混沌工程试验工具到混沌工程平台
浩鲸科技基于 ChaosBlade 的混沌工程实际
AppActive 的设计指标是多站点生产零碎同时对外提供服务。为了达到这一指标，技术实现上存在流量路由一致性、数据读写一致性、多活运维一致性等难点。
为应答以上挑战，阿里云全局高可用技术团队做了各类技术栈的形象以及接口标准定义。
周洋介绍，他们将 AppActive 形象为应用层、数据层和云平台 3 个局部：
应用层是业务流量链路的主门路，蕴含接入网关、微服务和音讯组件，外围要解决的是全局流量路由一致性问题，通过层层路由纠错来保障流量路由的正确性。其中，接入网关，处于机房流量的入口，负责七层流量调度，通过辨认流量中的业务属性并依据肯定流量规定进行路由纠错。微服务和音讯组件，以同步或异步调用的形式，通过路由纠错、流量爱护、故障隔离等能力，保障流量进入正确的机房进行逻辑解决和数据读写。
数据层外围要解决的是数据一致性问题，通过数据一致性爱护、数据同步、数据源切换能力来保障数据不脏写以及具备数据容灾恢复能力。
云平台是撑持业务利用运行的基石，因为用云状态可能蕴含自建 IDC、多云、混合云、异构芯片云等状态，云平台容灾须要进行多星散成和数据互通，在此基础来搭建和具备云平台、云服务 PaaS 层的容灾恢复能力。
利用多活应答的 6 大灾难故障
目前 AppActive 处于 v0.1 版本，开源内容包含上述应用层和数据层在数据立体上的所有规范接口定义，并基于 Nginx、Dubbo、MySQL 提供了根底实现。开发者可基于以后的能力，进行利用多活的基本功能运行和验证。
短期内，AppActive 的布局会对齐利用多活规范，晋升 AppActive 的完整性，具体包含以下几点：
1、丰盛接入层、服务层、数据层插件，反对更多技术组件到 AppActive 反对列表。
2、裁减利用多活的规范和实现，比方减少音讯利用多活的规范和实现。
3、建设 AppActive 管制立体，晋升 AppActive 利用多活实现的完整性。
4、遵循利用多活 LRA 规范扩大反对同城多活状态。
5、遵循利用多活 HCA 规范扩大反对混合云多活状态。
将来，阿里云将一直打磨 AppActive，致力使之成为利用多活规范下的最佳实际，以达到规模化生产可用的严格要求；也会适应云的发展趋势，摸索分布式云，实现跨云、跨平台、跨地理位置的利用多活全场景笼罩。
随着“无容灾不上云”共识的逐步达成，阿里云心愿帮忙更多企业的利用零碎构建应答劫难故障的逃逸能力，也心愿能跟 GitHub 社区里的开发者共建利用多活容灾规范。
