作者：Tina

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

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

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

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

從眾多宕機事件說開去

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

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

然而宕機事故又不可預(yù)測，因此它也被稱為系統(tǒng)中的“黑天鵝”。阿里云全局高可用技術(shù)團隊負責人周洋表示，當前大型互聯(lián)網(wǎng)系統(tǒng)架構(gòu)日趨復(fù)雜，穩(wěn)定性風險也在升高，系統(tǒng)中一定會有一些沒被發(fā)現(xiàn)的黑天鵝潛伏著。雖然預(yù)測不了“黑天鵝”什么時候會出現(xiàn)，但是能從故障中去尋求一些分類，并有針對性地對一類問題進行防御。比如現(xiàn)在的容災(zāi)架構(gòu)就是一種災(zāi)難防御手段，它主要針對的是機房級的故障場景。

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

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

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

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

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)備中心平時不工作，應(yīng)用服務(wù)的完整性和運行狀態(tài)未知，在發(fā)生故障的關(guān)鍵時刻會面臨敢不敢切的問題。有些企業(yè)會因為無法確定能否承載流量而不敢切，有些決定切換的企業(yè)也可能因為備用機房的應(yīng)用狀態(tài)不對而不能完全恢復(fù)業(yè)務(wù)，最終造成的影響就是 RTO 或者 RPO 較長，反應(yīng)給外界就是大型“宕機”事件。

來源自阿里實踐的 AppActive

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

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

到了 2013 年，由于機房容量有限以及杭州機房有限電風險，阿里巴巴開始探索異地多活的架構(gòu)方案，那就是后來大家都知道的所謂“單元化”。單元化架構(gòu)在 2014 年完成了試點驗證，2015 年正式在千里之外實現(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)用多活、匯通達混合云應(yīng)用多活等。

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

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

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

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

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

項目地址：

https://github.com/alibaba/Appactive

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

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

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

ChaosBlade 項目地址：

https://github.com/chaosblade-io/chaosblade

ChaosBlade：從混沌工程實驗工具到混沌工程平臺
浩鯨科技基于ChaosBlade的混沌工程實踐

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

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

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

1. 應(yīng)用層是業(yè)務(wù)流量鏈路的主路徑，包含接入網(wǎng)關(guān)、微服務(wù)和消息組件，核心要解決的是全局流量路由一致性問題，通過層層路由糾錯來保障流量路由的正確性。其中，接入網(wǎng)關(guān)，處于機房流量的入口，負責七層流量調(diào)度，通過識別流量中的業(yè)務(wù)屬性并根據(jù)一定流量規(guī)則進行路由糾錯。微服務(wù)和消息組件，以同步或異步調(diào)用的方式，通過路由糾錯、流量保護、故障隔離等能力，保障流量進入正確的機房進行邏輯處理和數(shù)據(jù)讀寫。
   
   
2. 數(shù)據(jù)層核心要解決的是數(shù)據(jù)一致性問題，通過數(shù)據(jù)一致性保護、數(shù)據(jù)同步、數(shù)據(jù)源切換能力來保障數(shù)據(jù)不臟寫以及具備數(shù)據(jù)容災(zāi)恢復(fù)能力。
   
   
3. 云平臺是支撐業(yè)務(wù)應(yīng)用運行的基石，由于用云形態(tài)可能包含自建 IDC、多云、混合云、異構(gòu)芯片云等形態(tài)，云平臺容災(zāi)需要進行多云集成和數(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ù)平面上的所有標準接口定義，并基于 Nginx、Dubbo、MySQL 提供了基礎(chǔ)實現(xiàn)。開發(fā)者可基于當前的能力，進行應(yīng)用多活的基本功能運行和驗證。

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

1. 豐富接入層、服務(wù)層、數(shù)據(jù)層插件，支持更多技術(shù)組件到 AppActive 支持列表。
   
2. 擴充應(yīng)用多活的標準和實現(xiàn)，比如增加消息應(yīng)用多活的標準和實現(xiàn)。
   
3. 建立 AppActive 控制平面，提升 AppActive 應(yīng)用多活實現(xiàn)的完整性。
   
4. 遵循應(yīng)用多活 LRA 標準擴展支持同城多活形態(tài)。
   
5. 遵循應(yīng)用多活 HCA 標準擴展支持混合云多活形態(tài)。
   
   

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

隨著“無容災(zāi)不上云”共識的逐漸達成，阿里云希望幫助更多企業(yè)的應(yīng)用系統(tǒng)構(gòu)建應(yīng)對災(zāi)難故障的逃逸能力，也希望能跟 GitHub 社區(qū)里的開發(fā)者共建應(yīng)用多活容災(zāi)標準。