作者：中西（github @zhongxig），AppActive 負責人，來自阿里云云原生高可用架構團隊，從事容災架構和故障快恢的研發和開源工作。
摘要： 繼高可用架構團隊的 Sentinel、Chaosblade 開源後，第三個重磅高可用產品：應用多活 AppActive 正式開源，形成高可用的三架馬車，幫助企業構建穩定可靠的企業級生產系統，提高企業面對容災、容錯、容量等問題的穩態系統建設能力。
1 月 11 日，在上海的雲原生實戰峰會上，阿里雲智慧研究員丁宇釋出了「應用多活技術白皮書」，同時為了推動業界容災的發展，建立雲原生業務容災標準，阿里雲對外開源「應用多活」中介軟體：AppActive。
什麼是 AppActive
「業務大規模擴充套件機房資源不可用怎麼辦？機房掛了怎麼辦？業務突然奔潰怎麼辦？颱風地震導致斷電怎麼辦？」
2013 年，當時淘寶完成去 O 沒多久，雙十一的規模較上年進一步飛增。阿里的工程師正面臨著上述的這一系列問題，一方面是機房資源非常緊張，容量不足，另一方面是杭州出現罕見的高溫天氣，機房面臨斷電的風險。異地多活架構在這個背景下孵化出來，它的載體是集團版本的 UnitRouter&UnitBrain 。
隨著淘寶的業務規模演進，異地多活也從近距離同城雙機房到遠距離異地雙活，再到三地四單元、多地多活，沉澱了豐富的機房級應用多活經驗。
2019 年，阿里巴巴系統全面上雲，異地多活架構也跟著上雲的節奏孵化出阿里云云產品 AHAS-MSHA，服務集團和雲上客戶
2022 年 1 月 11 日，AHAS-MSHA 程式碼正式開源，命名為 AppActive 。
AppActive 是一個面向業務應用構建雲原生高可用多活容災架構的開源中介軟體，它的主要價值：
-
分鐘級 RTO。 恢復時間快，阿里內部生產級別恢復時間平均在 30s 以內，外部客戶生產系統恢復時間平均在 1 分鐘。
-
資源充分利用。 資源不存在閒置的問題，多機房多資源充分利用，避免資源浪費。
-
切換成功率高。 依託於成熟的多活技術架構和視覺化運維平臺，相較於現有容災架構，切換成功率高，阿里內部年切流數千次的成功率高達 99.9% 以上。
-
流量精準控制。 應用多活支援流量自頂到底封閉，依託精準引流能力將特定業務流量打入對應機房，企業可基於此優勢能力孵化全域灰度、重點流量保障等特性。
為什麼開源
通過服務阿里集團近 9 年實戰經驗及服務雲上客戶 2 年多的商業化迭代積累，AHAS-MSHA 已經在涵蓋阿里的十餘家大型企業的容災場景中落地，使用量在持續增長，程式碼的穩定性和功能特性也經過充分的檢驗。
2021 年，國內外多家知名公司、雲平臺出現較嚴重服務中斷、宕機事件。這也為企業敲響警鐘，越來越多的企業把容災建設提上日程。在解決容災問題的同時，為了保持對成本的控制、支撐未來的多雲架構演進和災難容災的確定性，許多企業選擇以多活容災的方式進行嘗試。
但是業內對於多活沒有統一的認知，對於「多活」這個詞不同企業有不同的定義，很多企業往往以為已經實現了「多活」，可當故障來臨的時候，才發現當前系統的故障逃逸能力非常弱，業務恢復和故障定位無法解耦，拖累了企業生產，造成了外部輿情、資金損失等問題；另外，有的企業在瞭解「多活」之後，下意識想要企業內部先投入資源進行技術預演，但由於缺少經驗，往往會造成人力物力等資源的重複浪費。隨著雲原生技術發展，越來越多的客戶採用雲原生技術進行系統構建。如何在雲原生上構建穩定高可用的系統，是一個核心挑戰。「多活」的認知偏差會加劇企業在基礎設施成本、應用改造成本、運維成本等成本面的投入，但存在效率低下、錯用甚至無用或者不用的問題，從而享受不到「多活」帶來的穩定性紅利。因此「多活」需要一個相對統一的標準與認知，加深使用者對它的理解和使用，從而提高業務系統的穩定性。
在當前雲原生髮展的現狀和市場認知下，AppActive 的專案負責人中西表示，應用多活的開源和解讀，可以初步定義「多活」的標準和實現，幫助開發者形成統一的「多活」認知。在企業構建多活架構時，基於應用多活共用已有的成熟經驗，避免多餘的資源浪費。同時，不同的企業具備不同的業務場景和優勢，反向推動應用多活進一步完善和演進成熟的多活形態及能力。希望依靠社群的力量，讓「多活」成為一項事實意義的普惠技術，而不是望而卻步的部分人可用技術，幫助更多的企業和個人構建生產級別的高可用架構。
開源的內容
AppActive 標準介紹
在應用多活的標準定義裡有 LRA（同城多活）、UDA（異地多活）、HCA（混合雲多活）和 BFA（業務流量多活），詳細見《應用多活技術白皮書》。在 AppActive v0.1 版本中，我們優先實現 BFA 和 UDA 的基礎能力，在後續版本中完善 BFA 和 UDA 的同時，新增 LRA、HCA 能力。本文重點介紹 BFA、UDA。
1. 業務流量多活（BFABusiness Flow Active）
BFA，指的是應用多活的最終呈現是業務，多活容災系統具備按照業務特徵進行生產流量的精細化調配。
AppActive 在 BFA 指標中，支援流量自動糾偏，強路由到指定機房自閉環，屬於流量的精細化調配。
在非法流量打入機房時，機房的各層外掛均會依託於統一的排程規則進行處理：
-
接入層識別錯誤流量，自動糾錯到正確的機房。
-
服務層識別錯誤流量，自動糾錯到正確的機房。
-
資料層識別錯誤流量，為保證資料品質，丟擲異常，寫入失敗。
2. 異地多活（UDA，Ultra Distance Active）
UDA，指的是在超遠距離（機房間距超過 300 公里）時，業務系統仍具備較好的存取效能。進入容災態時，RTO、RPO 在分鐘級。
AppActive 在 UDA 指標中，支援存取效能良好。
在接入層支援流量解析，將請求流量進行解析，將流量打入機房的應用機器。基於 應用側 Servlet 外掛、Dubbo 外掛、MySQL 外掛的能力，業務流量請求在單一機房裡面自閉環，最終讀寫到本機房的資料庫。
在超遠距離場景下，由於流量封閉在機房內部，因此業務系統仍舊具備較好的存取效能。
進入容災態的 RPO 由開源資料同步元件或商業化同步工具進行保障，RTO 在 AppActive 0.1 版本中僅提供初級的流量切換能力，後續版本會演進到生產級別 RTO 保障工具。
AppActive 模組介紹
AppActive 屬於應用多活的一種定義和實現，它有資料平面和管控平面的整體實現。資料平面分為 4 部分，均支援在不變更原有企業使用技術元件基礎上，以外掛的形式增加能力：
-
接入閘道器。接入閘道器作為業務流量打入機房的第一跳，負責應用多活入口流量的識別和分發，具備機房路由和應用路由兩個核心能力。
-
服務層。業務流量在機房內部和跨機房的同步呼叫方式，一般有 Consumer、Provider、註冊中心等角色，具備流量路由、流量保護、故障隔離三個核心能力，避免呼叫錯誤導致的資料髒寫，加速切流期間的業務恢復。
-
訊息層。業務流量在機房內部和跨機房的非同步呼叫方式，基於訊息削峰填谷，一般有 Producer、Consumer、Broker 等角色，具備流量路由、流量保護、故障隔離三個核心能力，避免訊息錯投導致的資料髒寫，保護切流期間訊息不丟。
-
資料層：涵蓋業務應用資料讀寫、資料儲存和資料同步，其具備流量路由、資料一致性保護、資料同步三個核心能力。
管控平面核心涵蓋多活容災規則的日常運維和災難場景的流量切換。
當前 AppActive 處於 v0.1 版本，開源：
-
上述的資料平面所有層的定義基礎實現。
-
接入層閘道器的 Nginx 外掛實現。
-
服務層 Dubbo2.x 外掛實現。
-
資料層開源 MySQL 外掛實現。
-
管控平面流量切換的基礎能力。
開發者可基於 v0.1 的能力，進行 應用多活的基本功能執行和驗證。
AppActive 後續規劃
-
豐富接入層、服務層、資料層外掛，支援更多技術元件到 AppActive 支援的列表中。
-
增加訊息層的外掛實現，支援訊息應用多活能力。
-
增加其他層在應用多活的標準和實現。
-
支援 Web 白屏化，follow 應用多活 UDA 的標準，提升 RTO。
-
遵循應用多活 HCA 標準支援混合雲多活形態。
-
遵循應用多活 LRA 標準支援同城多活形態
起點
「異地多活」和「單元化」源於阿里，也受到了業界的認可。阿里也一直希望應用多活的產品生態可以做到標準和開放，對業界做出貢獻。
基於應用多活的標準技術，業務應用在不同的雲廠商之間，不同的基礎設施之間，不同的晶片之間都可以實現互通互聯。業務應用在資源充分利用的同時，達到分鐘級甚至秒級的 RTO 指標，真正意義的做到不懼故障。
今天，AppActive 開源的第一個版本只是應用多活領域的一個起點，歡迎大家參與進來一起共建應用多活生態。想要了解更多 AppActive，釘釘搜尋群號：34222602，加入 AppActive 開源討論群參與討論吧！
點選，立即前往下載《應用多活技術白皮書》。