作者：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 社區里的開發者共建應用多活容災標準。 發布云原生技術最新資訊、匯集云原生技術最全內容，定期舉辦云原生活動、直播，阿里產品及用戶最佳實踐發布。與你并肩探索云原生技術點滴，分享你需要的云原生內容。

關注【阿里巴巴云原生】公眾號，獲取更多云原生實時資訊！

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。