作者：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 的實現與未來規劃
阿里雲也曾在 2019 年開源了自己的混沌工程專案，旨在透過混沌工程幫助企業解決雲原生過程中的高可用問題。AppActive 更偏防禦，ChaosBlade 更偏攻擊，攻防結合，形成更加健全的落地安全生產機制。
ChaosBlade 專案地址：
https://github.com/chaosblade-io/chaosbladeAppActive
的設計目標是多站點生產系統同時對外提供服務。為了達到這一目標，技術實現上存在流量路由一致性、資料讀寫一致性、多活運維一致性等難點。為應對以上挑戰，阿里雲全域性高可用技術團隊做了各類技術棧的抽象以及介面標準定義。周洋介紹，他們將 AppActive 抽象為應用層、資料層和雲平臺 3 個部分：
- 應用層是業務流量鏈路的主路徑，包含接入閘道器、微服務和訊息元件，核心要解決的是全域性流量路由一致性問題，透過層層路由糾錯來保障流量路由的正確性。其中，接入閘道器，處於機房流量的入口，負責七層流量排程，透過識別流量中的業務屬性並根據一定流量規則進行路由糾錯。微服務和訊息元件，以同步或非同步呼叫的方式，透過路由糾錯、流量保護、故障隔離等能力，保障流量進入正確的機房進行邏輯處理和資料讀寫。
- 資料層核心要解決的是資料一致性問題，透過資料一致性保護、資料同步、資料來源切換能力來保障資料不髒寫以及具備資料容災恢復能力。
- 雲平臺是支撐業務應用執行的基石，由於用雲形態可能包含自建 IDC、多雲、混合雲、異構晶片雲等形態，雲平臺容災需要進行多雲整合和資料互通，在此基礎來搭建和具備雲平臺、雲服務 PaaS 層的容災恢復能力。
應用多活應對的 6 大災難故障目前 AppActive 處於 v0.1 版本，開源內容包括上述應用層和資料層在資料平面上的所有標準介面定義，並基於 Nginx、Dubbo、MySQL 提供了基礎實現。開發者可基於當前的能力，進行應用多活的基本功能執行和驗證。短期內，AppActive 的規劃會對齊應用多活標準，提升 AppActive 的完整性，具體包括以下幾點：
- 豐富接入層、服務層、資料層外掛，支援更多技術元件到 AppActive 支援列表。
- 擴充應用多活的標準和實現，比如增加訊息應用多活的標準和實現。
- 建立 AppActive 控制平面，提升 AppActive 應用多活實現的完整性。
- 遵循應用多活 LRA 標準擴充套件支援同城多活形態。
- 遵循應用多活 HCA 標準擴充套件支援混合雲多活形態。
未來，阿里雲將不斷打磨 AppActive，努力使之成為應用多活標準下的最佳實踐，以達到規模化生產可用的嚴格要求；也會順應雲的發展趨勢，探索分散式雲，實現跨雲、跨平臺、跨地理位置的應用多活全場景覆蓋。
隨著“無容災不上雲”共識的逐漸達成，阿里雲希望幫助更多企業的應用系統構建應對災難故障的逃逸能力，也希望能跟 GitHub 社群裡的開發者共建應用多活容災標準。（正文完）
