作者 | 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 年開源了自己的混沌工程項目 ChaosBlade（https://github.com/chaosblade-io/chaosblade），旨在通過混沌工程幫助企業解決雲原生過程中的高可用問題。AppActive 更偏防禦，ChaosBlade 更偏攻擊，攻防結合，形成更加健全的落地安全生産機制。
AppActive 的設計目标是多站點生産系統同時對外提供服務。為了達到這一目标，技術實作上存在流量路由一緻性、資料讀寫一緻性、多活運維一緻性等難點。
為應對以上挑戰，阿裡雲全局高可用技術團隊做了各類技術棧的抽象以及接口标準定義。
周洋介紹，他們将 AppActive 抽象為應用層、資料層和雲平台 3 個部分：
應用層是業務流量鍊路的主路徑，包含接入網關、微服務和消息元件，核心要解決的是全局流量路由一緻性問題，通過層層路由糾錯來保障流量路由的正确性。其中，接入網關，處于機房流量的入口，負責七層流量排程，通過識别流量中的業務屬性并根據一定流量規則進行路由糾錯。微服務和消息元件，以同步或異步調用的方式，通過路由糾錯、流量保護、故障隔離等能力，保障流量進入正确的機房進行邏輯處理和資料讀寫。
資料層核心要解決的是資料一緻性問題，通過資料一緻性保護、資料同步、資料源切換能力來保障資料不髒寫以及具備資料容災恢複能力。
雲平台是支撐業務應用運作的基石，由于用雲形态可能包含自建 IDC、多雲、混合雲、異構晶片雲等形态，雲平台容災需要進行多雲內建和資料互通，在此基礎來搭建和具備雲平台、雲服務 PaaS 層的容災恢複能力。
應用多活應對的 6 大災難故障
目前 AppActive 處于 v0.1 版本，開源内容包括上述應用層和資料層在資料平面上的所有标準接口定義，并基于 Nginx、Dubbo、MySQL 提供了基礎實作。開發者可基于目前的能力，進行應用多活的基本功能運作和驗證。
短期内，AppActive 的規劃會對齊應用多活标準，提升 AppActive 的完整性，具體包括以下幾點：
豐富接入層、服務層、資料層插件，支援更多技術元件到 AppActive 支援清單。
擴充應用多活的标準和實作，比如增加消息應用多活的标準和實作。
建立 AppActive 控制平面，提升 AppActive 應用多活實作的完整性。
遵循應用多活 LRA 标準擴充支援同城多活形态。
遵循應用多活 HCA 标準擴充支援混合雲多活形态。
未來，阿裡雲将不斷打磨 AppActive，努力使之成為應用多活标準下的最佳實踐，以達到規模化生産可用的嚴格要求；也會順應雲的發展趨勢，探索分布式雲，實作跨雲、跨平台、跨地理位置的應用多活全場景覆寫。
随着“無容災不上雲”共識的逐漸達成，阿裡雲希望幫助更多企業的應用系統建構應對災難故障的逃逸能力，也希望能跟 GitHub 社群裡的開發者共建應用多活容災标準，
延展閱讀：
阿裡雲《應用多活技術白皮書》：
https://developer.aliyun.com/topic/download?spm=a2c6h.12873639.0.0.5b222e55fukQsa&id=8266