作者：Tina

互聯(lián)網(wǎng)技術(shù)發(fā)展到了 2021 年，上云也更加普遍，但宕機(jī)事件卻似乎沒怎么減少。

這一年 10 月，擁有 30 億用戶的臉書 (Facebook) 遭遇大規(guī)模宕機(jī)，中斷服務(wù)約 7 小時(shí)后大部分服務(wù)才重新上線。據(jù)說，這是 Facebook 創(chuàng)辦以來最嚴(yán)重的一次網(wǎng)絡(luò)訪問事故，導(dǎo)致臉書一夜之間市值蒸發(fā)約 473 億美元 (約合 3049 億元人民幣)。

而在更早些時(shí)候，國內(nèi)某視頻網(wǎng)站也因機(jī)房故障導(dǎo)致網(wǎng)站崩潰，大量用戶“流浪”到其他網(wǎng)站，巨大的流量洪峰又讓其他平臺也連鎖式癱瘓了。此外，擁有 15 萬家客戶的 Salesforce 在這一年也遭遇了一次長達(dá) 5 個(gè)小時(shí)的全球性質(zhì)的宕機(jī)事故，在線游戲平臺 Roblox 還曾發(fā)生過長達(dá) 73 小時(shí)的宕機(jī)事故......

互聯(lián)網(wǎng)技術(shù)發(fā)展到現(xiàn)在，理論上來說是可以做到“永不宕機(jī)”的，但為什么還有這么多規(guī)模大、時(shí)間長的系統(tǒng)故障發(fā)生？如何減少宕機(jī)事故的發(fā)生？InfoQ 采訪了阿里云全局高可用技術(shù)團(tuán)隊(duì)，談?wù)勅绾伪ＷC復(fù)雜系統(tǒng)中的業(yè)務(wù)可持續(xù)性。

從眾多宕機(jī)事件說開去

云計(jì)算的蓬勃發(fā)展，催生了越來越多的“國民級應(yīng)用”，但傳統(tǒng)的災(zāi)備架構(gòu)已很難滿足業(yè)務(wù)快速恢復(fù)的需要。

有統(tǒng)計(jì)數(shù)據(jù)表明，96% 的企業(yè)曾在過去三年中至少經(jīng)歷過一次系統(tǒng)中斷。對于小型企業(yè)來說，一小時(shí)的宕機(jī)時(shí)間會平均造成 25,000 美元的損失。對于大型企業(yè)來說，平均成本可能高達(dá) 540,000 美元。如今，停機(jī)時(shí)間越長，這意味著產(chǎn)生永久性損失的可能性越大。

然而宕機(jī)事故又不可預(yù)測，因此它也被稱為系統(tǒng)中的“黑天鵝”。阿里云全局高可用技術(shù)團(tuán)隊(duì)負(fù)責(zé)人周洋表示，當(dāng)前大型互聯(lián)網(wǎng)系統(tǒng)架構(gòu)日趨復(fù)雜，穩(wěn)定性風(fēng)險(xiǎn)也在升高，系統(tǒng)中一定會有一些沒被發(fā)現(xiàn)的黑天鵝潛伏著。

雖然預(yù)測不了“黑天鵝”什么時(shí)候會出現(xiàn)，但是能從故障中去尋求一些分類，并有針對性地對一類問題進(jìn)行防御。比如現(xiàn)在的容災(zāi)架構(gòu)就是一種災(zāi)難防御手段，它主要針對的是機(jī)房級的故障場景。

機(jī)房級的故障場景，從 IDC 的維度上看，主要有機(jī)房入口網(wǎng)絡(luò)故障、機(jī)房間網(wǎng)絡(luò)故障以及機(jī)房掉電。如果精細(xì)化到應(yīng)用層，又可以分為接入網(wǎng)關(guān)故障、業(yè)務(wù)應(yīng)用故障以及數(shù)據(jù)庫故障等，背后的故障原因可能是軟件 BUG 或者部分硬件故障，比如機(jī)柜掉電、接入交換機(jī)故障等等。

容災(zāi)架構(gòu)的目標(biāo)是，在單機(jī)房出現(xiàn)任何故障的情況下，能夠快速恢復(fù)業(yè)務(wù)，保障 RTO 和 RPO。

RTO（恢復(fù)時(shí)間目標(biāo)）是指用戶愿意為從災(zāi)難中恢復(fù)而花費(fèi)的最長時(shí)間。一般來說，數(shù)據(jù)量越大，恢復(fù)所需的時(shí)間就越長。

RPO（恢復(fù)點(diǎn)目標(biāo)）是指在發(fā)生災(zāi)難時(shí)用可以承受的最大數(shù)據(jù)丟失量。例如，如果用戶可以承受 1 天的數(shù)據(jù)丟失，RPO 就是 24 小時(shí)。

RTO 和 RPO

針對不同種類的故障，災(zāi)備行業(yè)有三種不同等級的防御方式：數(shù)據(jù)級、應(yīng)用級、業(yè)務(wù)級?，F(xiàn)在業(yè)內(nèi)主流的容災(zāi)架構(gòu)還是災(zāi)備容災(zāi)，屬于數(shù)據(jù)級的容災(zāi)方案。由于災(zāi)備中心平時(shí)不工作，應(yīng)用服務(wù)的完整性和運(yùn)行狀態(tài)未知，在發(fā)生故障的關(guān)鍵時(shí)刻會面臨敢不敢切的問題。

有些企業(yè)會因?yàn)闊o法確定能否承載流量而不敢切，有些決定切換的企業(yè)也可能因?yàn)閭溆脵C(jī)房的應(yīng)用狀態(tài)不對而不能完全恢復(fù)業(yè)務(wù)，最終造成的影響就是 RTO 或者 RPO 較長，反應(yīng)給外界就是大型“宕機(jī)”事件。

來源自阿里實(shí)踐的 AppActive

2021 年，國內(nèi)外多家知名公司、云平臺出現(xiàn)較嚴(yán)重服務(wù)中斷、宕機(jī)事件，為企業(yè)敲響了警鐘，越來越多的企業(yè)把容災(zāi)建設(shè)提上日程。在解決容災(zāi)問題的同時(shí)，為保持對成本的控制、支撐未來的多云架構(gòu)演進(jìn)和災(zāi)難容災(zāi)的確定性，許多企業(yè)選擇嘗試采用多活容災(zāi)的方式。

當(dāng)災(zāi)難發(fā)生時(shí)，多活容災(zāi)可以實(shí)現(xiàn)分鐘級的業(yè)務(wù)流量切換，用戶甚至感受不到災(zāi)難發(fā)生。應(yīng)用多活針對不同的部署場景有三大典型架構(gòu)：在同城機(jī)房物理距離小于 100 公里的場景下建設(shè)同城應(yīng)用多活，在異地機(jī)房物理距離大于 300 公里的場景下建設(shè)異地應(yīng)用多活，在混合云多云融合的場景下建設(shè)混合云應(yīng)用多活。在多活模式下，資源不閑置不浪費(fèi)，而且能夠突破單地域的機(jī)房容量限制，從而獲得跨地域的容量擴(kuò)展性。

多活容災(zāi)在阿里內(nèi)部實(shí)踐了多年。早在 2007 年到 2010 年，阿里巴巴就采用同城多活架構(gòu)支撐業(yè)務(wù)容量和可用性。

到了 2013 年，由于機(jī)房容量有限以及杭州機(jī)房有限電風(fēng)險(xiǎn)，阿里巴巴開始探索異地多活的架構(gòu)方案，那就是后來大家都知道的所謂“單元化”。單元化架構(gòu)在 2014 年完成了試點(diǎn)驗(yàn)證，2015 年正式在千里之外實(shí)現(xiàn)三地四中心，從而具備了生產(chǎn)級別的異地多活能力，2017 年完成了在雙 11 凌晨切流。

2019 年，阿里巴巴系統(tǒng)全面上云，異地多活架構(gòu)跟隨上云的節(jié)奏孵化成阿里云云原生產(chǎn)品 AHAS-MSHA，服務(wù)阿里巴巴和云上客戶，先后幫助數(shù)字政府、物流、能源、通信、互聯(lián)網(wǎng)等十余家不同行業(yè)中的大型企業(yè)成功構(gòu)建應(yīng)用多活架構(gòu)，包括菜鳥鄉(xiāng)村同城應(yīng)用多活、聯(lián)通新客服異地應(yīng)用多活、匯通達(dá)混合云應(yīng)用多活等。

在采訪阿里云全局高可用技術(shù)團(tuán)隊(duì)時(shí)，大家普遍的感受是，“業(yè)內(nèi)對于多活沒有統(tǒng)一的認(rèn)知，并且重視度不夠?！?/p>

首先，不同的人對于“多活”這個(gè)詞會有不同的定義，人人都說自己是“多活”，可當(dāng)故障來臨的時(shí)候，才發(fā)現(xiàn)當(dāng)前系統(tǒng)并不是真正的多活。其次，有些企業(yè)并不了解異地多活，有些了解的企業(yè)會認(rèn)為異地多活的成本高、難落地。還有些企業(yè)在了解“多活”之后，下意識想要先在企業(yè)內(nèi)部投入資源進(jìn)行技術(shù)預(yù)研，抗拒云廠商的商業(yè)化產(chǎn)品輸入。

“多活”的認(rèn)知偏差會讓使用者錯(cuò)用或者不用，從而享受不到“多活”帶來的穩(wěn)定性紅利。

在阿里云全局高可用技術(shù)團(tuán)隊(duì)看來，應(yīng)用多活將成為云原生容災(zāi)領(lǐng)域的趨勢，與其等待趨勢到來，不如通過開源來推動應(yīng)用多活的發(fā)展。他們希望通過開源協(xié)同，形成一套應(yīng)用多活的技術(shù)規(guī)范和標(biāo)準(zhǔn)，使得應(yīng)用多活技術(shù)變得更易用、通用、穩(wěn)定和可擴(kuò)展。

2022 年 1 月 11 日，阿里云將 AHAS-MSHA 代碼正式開源，命名為 AppActive。這也是開源領(lǐng)域首次提出“應(yīng)用多活”概念。

項(xiàng)目地址： https://github.com/alibaba/Appactive

阿里云開源業(yè)內(nèi)首個(gè)應(yīng)用多活項(xiàng)目 AppActive，與社區(qū)共建云原生容災(zāi)標(biāo)準(zhǔn)

AppActive 的實(shí)現(xiàn)與未來規(guī)劃

阿里云也曾在 2019 年開源了自己的混沌工程項(xiàng)目，旨在通過混沌工程幫助企業(yè)解決云原生過程中的高可用問題。AppActive 更偏防御，ChaosBlade 更偏攻擊，攻防結(jié)合，形成更加健全的落地安全生產(chǎn)機(jī)制。

ChaosBlade 項(xiàng)目地址： https://github.com/chaosblade-io/chaosblade

ChaosBlade：從混沌工程實(shí)驗(yàn)工具到混沌工程平臺 浩鯨科技基于ChaosBlade的混沌工程實(shí)踐

AppActive 的設(shè)計(jì)目標(biāo)是多站點(diǎn)生產(chǎn)系統(tǒng)同時(shí)對外提供服務(wù)。為了達(dá)到這一目標(biāo)，技術(shù)實(shí)現(xiàn)上存在流量路由一致性、數(shù)據(jù)讀寫一致性、多活運(yùn)維一致性等難點(diǎn)。

為應(yīng)對以上挑戰(zhàn)，阿里云全局高可用技術(shù)團(tuán)隊(duì)做了各類技術(shù)棧的抽象以及接口標(biāo)準(zhǔn)定義。

周洋介紹，他們將 AppActive 抽象為應(yīng)用層、數(shù)據(jù)層和云平臺 3 個(gè)部分：

應(yīng)用層是業(yè)務(wù)流量鏈路的主路徑，包含接入網(wǎng)關(guān)、微服務(wù)和消息組件，核心要解決的是全局流量路由一致性問題，通過層層路由糾錯(cuò)來保障流量路由的正確性。其中，接入網(wǎng)關(guān)，處于機(jī)房流量的入口，負(fù)責(zé)七層流量調(diào)度，通過識別流量中的業(yè)務(wù)屬性并根據(jù)一定流量規(guī)則進(jìn)行路由糾錯(cuò)。微服務(wù)和消息組件，以同步或異步調(diào)用的方式，通過路由糾錯(cuò)、流量保護(hù)、故障隔離等能力，保障流量進(jìn)入正確的機(jī)房進(jìn)行邏輯處理和數(shù)據(jù)讀寫。

數(shù)據(jù)層核心要解決的是數(shù)據(jù)一致性問題，通過數(shù)據(jù)一致性保護(hù)、數(shù)據(jù)同步、數(shù)據(jù)源切換能力來保障數(shù)據(jù)不臟寫以及具備數(shù)據(jù)容災(zāi)恢復(fù)能力。

云平臺是支撐業(yè)務(wù)應(yīng)用運(yùn)行的基石，由于用云形態(tài)可能包含自建 IDC、多云、混合云、異構(gòu)芯片云等形態(tài)，云平臺容災(zāi)需要進(jìn)行多云集成和數(shù)據(jù)互通，在此基礎(chǔ)來搭建和具備云平臺、云服務(wù) PaaS 層的容災(zāi)恢復(fù)能力。

應(yīng)用多活應(yīng)對的 6 大災(zāi)難故障

目前 AppActive 處于 v0.1 版本，開源內(nèi)容包括上述應(yīng)用層和數(shù)據(jù)層在數(shù)據(jù)平面上的所有標(biāo)準(zhǔn)接口定義，并基于 Nginx、Dubbo、MySQL 提供了基礎(chǔ)實(shí)現(xiàn)。開發(fā)者可基于當(dāng)前的能力，進(jìn)行應(yīng)用多活的基本功能運(yùn)行和驗(yàn)證。

短期內(nèi)，AppActive 的規(guī)劃會對齊應(yīng)用多活標(biāo)準(zhǔn)，提升 AppActive 的完整性，具體包括以下幾點(diǎn)：

1、豐富接入層、服務(wù)層、數(shù)據(jù)層插件，支持更多技術(shù)組件到 AppActive 支持列表。

2、擴(kuò)充應(yīng)用多活的標(biāo)準(zhǔn)和實(shí)現(xiàn)，比如增加消息應(yīng)用多活的標(biāo)準(zhǔn)和實(shí)現(xiàn)。

3、建立 AppActive 控制平面，提升 AppActive 應(yīng)用多活實(shí)現(xiàn)的完整性。

4、遵循應(yīng)用多活 LRA 標(biāo)準(zhǔn)擴(kuò)展支持同城多活形態(tài)。

5、遵循應(yīng)用多活 HCA 標(biāo)準(zhǔn)擴(kuò)展支持混合云多活形態(tài)。

未來，阿里云將不斷打磨 AppActive，努力使之成為應(yīng)用多活標(biāo)準(zhǔn)下的最佳實(shí)踐，以達(dá)到規(guī)?；a(chǎn)可用的嚴(yán)格要求；也會順應(yīng)云的發(fā)展趨勢，探索分布式云，實(shí)現(xiàn)跨云、跨平臺、跨地理位置的應(yīng)用多活全場景覆蓋。

隨著“無容災(zāi)不上云”共識的逐漸達(dá)成，阿里云希望幫助更多企業(yè)的應(yīng)用系統(tǒng)構(gòu)建應(yīng)對災(zāi)難故障的逃逸能力，也希望能跟 GitHub 社區(qū)里的開發(fā)者共建應(yīng)用多活容災(zāi)標(biāo)準(zhǔn)。 發(fā)布云原生技術(shù)最新資訊、匯集云原生技術(shù)最全內(nèi)容，定期舉辦云原生活動、直播，阿里產(chǎn)品及用戶最佳實(shí)踐發(fā)布。與你并肩探索云原生技術(shù)點(diǎn)滴，分享你需要的云原生內(nèi)容。

關(guān)注【阿里巴巴云原生】公眾號，獲取更多云原生實(shí)時(shí)資訊！

總結(jié)

以上是生活随笔為你收集整理的重新理解“无容灾不上云”：应用多活将成为云原生容灾新趋势的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。