凌晨3點，在某醫院的自助繳費機前，一位醫患家屬正愁眉緊鎖，手中的醫保卡已經刷了無數遍，可次次都提示繳費失敗，至親的手術已經迫在眉睫…

早上8點，是上班族在通勤途中打開新聞app刷新聞的高峯，而此刻在新聞編輯室內，後台編輯正焦頭爛額，系統上當日熱點大新聞的發佈界面一遍遍顯示“發佈失敗”…

這些畫面簡直是企業IT管理者心中的“災難大片”，而導致這些問題的原因可能是企業數據中心中某個機櫃斷電、某次颱風導致機房故障、某位IT管理員一不小心刪除了數據庫…

天災人禍或許難以避免，但是上述場景卻可以通過IT架構設計來規避預防。在雲計算時代，面對黑天鵝事件，IT人員如何利用容災方案來保證業務連續性？雲平台的容災和傳統IT容災究竟有哪些不同？哪些因素影響着政企雲平台的容災設計？阿里雲又有怎樣的解決方案？這篇文章，將一一給出答案。

一 數智時代的雙刃劍 —— 雲計算的普及讓容災課題變得更為緊迫

隨着全行業的數智化轉型不斷深入，雲原生應用已經成為各界公認的數字化轉型範式，而承載雲原生應用的底座 —— 全棧雲計算平台，則成為政企數智化轉型的堅實底座。

雲計算本身具備的“集約化建設、統一大資源池、統一服務供給”的模式，讓應用天然在雲平台上大量彙集，一方面釋放出平台資源彈性供給和敏捷調配的優勢，另一方面也意味着一旦平台出現故障，影響範圍會更大。為了保證業務層面連續性，雲平台高可用能力成為現在政企IT掌舵者所關注的重中之重。

雖然雲平台在設計之初，已經具備了初步的高可用能力，諸如組件多副本、數據跨服務器機櫃、網絡機架打散等，但這隻能做到“單機房高可用”。對於金融、税務、醫保、能源等行業來説，他們對於系統的業務連續性有更高的要求。比如金融行業有明確的跨機房容災政策要求，且核心業務系統故障達30分鐘則需要上報上級監管單位；國家、省級醫保信息系統必須採用同城容災模式來滿足業務連續性要求。因此，基於全棧雲產品的跨機房容災成為了部分政企客户的強需求。

二 新瓶為何不能裝舊酒？—— 傳統IT容災技術在雲時代面臨的困境

傳統IT容災經過多年的沉澱，目前有兩種常見的技術路線：

1.存儲級容災

這種技術主要以傳統的陣列存儲為主，在兩個機房放置相同的存儲機型，通過陣列間的“同步複製”或“異步複製”等模式，實現數據在雙中心的同步。

典型存儲級容災示意圖

在該模式下，為了避免數據雙寫，備中心的計算節點及應用日常處於停機狀態，即處於“冷備”。這就意味着，當一個數據中心發生故障後，需要先切換到備中心的IT設施，然後再逐個啓動備中心的計算節點和應用程序，結果必然帶來較長的RTO。另外，該模式下還存在着應用無法正常啓動的可能性，進一步延長RTO。

隨着雲原生的發展應用，業務應用一般會被分散到動輒數百甚至數千個節點，對如此規模的節點和應用進行重新啓動，RTO必然會被大幅拉長，也無法滿足最基本的恢復時間要求。另外，傳統陣列在擴展性、成本等維度也不滿足雲計算的基本技術架構要求。

2.產品級容災

這種技術的特點是產品自身可實現“工作節點的跨機房轉移和數據跨機房的複製”，不依賴於底層存儲。對外服務層面，一般採用主備、雙活等模式。數據層面，產品通過自身的機制實現跨機房數據複製，如Mysql的binLog複製等。

典型數據庫容災複製架構

由於備機房產品也是正常的工作節點，只是日常角色為備，不接受流量。當主機房完成切換後，備機房節點立刻可用。因此，不會存在切換到備中心後實例不可用的異常情況，業務的RTO一般要小於存儲級容災架構。

從整個業務維度來看，該模式相比存儲級容災的可控程度更高、RTO更好。但該技術只負責應用的某一層技術棧如DB，缺乏全局業務視角的業務容災能力。

在雲原生條件下，應用會基於IaaS、中間件、數據庫、大數據等全棧雲產品進行構建，數據也分散在大量不同的產品，容災架構也必須基於全棧產品視角，進行端到端的重新設計。

三 給雲上掌舵者的考題 —— 全棧雲容災考量公式

基於上述分析，傳統IT技術架構難以滿足雲原生的業務模式，這時就需要全棧雲容災解決方案登場了。作為IT管理者，全棧雲容災是一個全新的複雜命題，又有哪些問題需要考慮呢？這裏引入一個公式幫助IT掌舵者來進行評估判斷：

全棧雲容災複雜度 =（產品數量 X 產品依賴 X 切換場景X容災指標）/ 容災管理體驗

1.產品數量多

一個業務系統需要使用十幾個甚至幾十個雲產品，業務牽涉到的所有云產品及支撐產品都需要具備容災切換能力。同時，數據存儲類型相比傳統IT大大增加，常見如塊存儲、對象存儲、OLTP數據存儲、OLAP數據存儲、離線大數據存儲、日誌存儲等。為了達到跨機房容災效果，在選擇雲平台時，IT管理者需要確保這些產品均要具備“跨機房數據同步”和“跨機房高可用”的能力。

某阿里雲客户所使用的主要雲產品統計

2.產品依賴多

為了實現雲產品的高可用，降低產品的重複開銷，雲平台在設計時，一般會將產品組件和依賴組件進行拆分，如把DNS、NTP、元數據庫、分佈式協調服務等作為底座組件來統一對上層雲產品提供服務。因此，容災切換需要考慮到底座及產品依賴，避免產品切換後，因為缺少依賴而導致報錯或無法使用。

3.容災場景多

跨機房故障場景類型較多，每種產品都需要同時考慮“機房斷電、腦裂、網絡中斷、故障回切”等多種場景下的數據複製策略和切換預案，以最快的速度實現業務恢復和保障數據安全。

4.容災要求高

雲時代的業務故障影響面更大，容災相比傳統IT架構需要更高的RTO和RPO要求。如中國人民銀行發佈的《雲計算技術金融應用規範容災》中對於RTO和RPO的具體要求如下：

5.容災管理體驗

鑑於上述的“三多一高”問題，全棧雲的容災管理也成為一個難題，容災管理最好能具備如下能力：

a) 簡單切換：一次容災切換可能同時牽涉到幾十款產品的容災協同，無法再通過傳統手工的方式逐個執行產品切換，因此雲平台必須具備高效的演練和切換能力，降低RTO。
b) 全場景覆蓋：容災設計需要兼顧同城、異地、兩地三中心等多種容災場景，且可隨着政企容災架構的演進在各場景持續進行迭代。
c) 租户隔離：在多租户場景中（雲平台需要對外提供運營和服務），需要支持各租户進行自助容災，同時單個客户不同系統可以按需進行切換，且保證容災切換對其他客户的業務無影響。
d) 可控容災：雲平台需要具備完善的容災監控體系，用户可隨時掌握最新容災動態，並與內部的容災預案流程相結合，確保系統時刻處於“可控、可預知”的狀態，避免“非預期切換”造成的數據安全風險。

四 更強實力更有底氣 —— 阿里雲是全棧專有云容災的開創者

從上述全棧雲容災的特點和需求來看，全棧雲容災考驗的是雲廠家對全棧產品的掌控和駕馭能力，需要對所有產品具備代碼級的架構修改和功能迭代能力，以及完善的產品工具支撐體系。唯有如此，才能提供成熟、穩定、可迭代的容災服務能力。這也正是阿里雲全棧自研的優勢所在。

阿里雲於2015年推出飛天企業版，採用與公共雲同樣的技術架構，為政企客户提供全棧產品服務能力。在幫助客户完成“建雲”“上雲”過程後，基於客户普遍的高業務連續性要求，阿里雲在業內率先進行基於專有云的跨機房容災研發。經過廣泛的用户需求調研，阿里雲“採用應用級容災思路、基於全棧產品視角，以應用端到端恢復為出發點”，於2017年正式推出飛天企業版容災解決方案，在業內開創了全棧專有云容災的新範式。

經過多年技術迭代，飛天企業版容災解決方案的能力不斷加強：

• 2017年，支持同城雙AZ容災，支持20+雲產品容災；
• 2018年，在金融、政務等多個客户完成同城容災項目交付，具備生產級容災能力；
• 2019年，支持異地跨雲容災、異地多活容災，並在多個政務客户完成交付；
• 2020年，支持同城3AZ容災，業內率先實現了基於雲原生條件下的數據庫RPO=0，多個銀行客户進入3AZ容災階段；支持多對一異地容災，支持了某省醫保“省級同城容災、省市間多對一異地容災”建設模式；
• 2021年，支持全棧產品級的兩地三中心容災，滿足金融等行業同時具備同城、異地容災的政策要求；
• 2022年，支持基於國產化芯片的容災能力，各場景下的容災能力得到大幅提升，滿足了政府、金融客户在一雲多芯的需求下的容災形態要求。

基於全棧雲容災的需求，阿里雲飛天企業版容災解決方案構建起“多邊形戰士”的能力：

1.支持產品最多

飛天企業版已完成IaaS、中間件、數據庫、大數據、底座等全棧60+ 產品在不同場景下的容災架構設計，可以滿足不同行業客户應用層端到端容災的需求。

2.支持場景最全

鑑於客户不同的容災模式需求，飛天企業版支持同城雙AZ、同城三AZ、異地跨雲容災、異地跨Region容災、異地多活容災、異地多對一容災、兩地三中心容災等多種原子容災場景，可以基於不同業務特點，將上述原子容災場景進行排列組合，形成更復雜的組合容災場景，如“同城容災+異地多活”、“同城容災+異地多對一容災”等模式，具備“全場景容災”的能力。

3.容災管理簡單

針對全棧雲的容災管理難題，阿里雲在業內開創性地推出業務連續性管理平台ASR（Apsara Stack Resilience）。ASR以可視化方式，通過多場景適配，提供容災狀態監控、故障注入與演練、容災切換與回切、租户隔離等能力，將複雜的“產品切換邏輯、產品間依賴、機房級切換”等內部邏輯進行編排和封裝，使運維人員無需關心複雜的內部處理邏輯，可以“一鍵”完成全棧產品的容災演練和切換。此外，ASR大大降低了全棧雲容災演練難度，用户可以按需定期演練，杜漸防萌，確保“故障時刻敢切換”。

4.應用友好，降低RTO

租户通過域名或者vip來訪問雲產品，雲產品的容災切換會保證雲產品容災實例的訪問地址不變，因此可以做到容災切換時產品的容災能力對應用透明，可以極大降低應用恢復的時間。

5.RPO=0，滿足等高階容災要求

金融等對數據可靠性要求較高的行業，往往要求RPO=0。阿里雲率先推出基於雲計算分佈式技術體系的同城3AZ容災模式，通過在多機房部署數據副本，滿足任意條件下的單機房故障RPO=0，達到《GB20988-2007-T 信息安全技術信息系統災難恢復規範》和《JR/T 0168-2020雲計算技術金融應用規範-容災》的最高等級要求。

五 穩中求進 —— 讓全棧雲容災成為數智創新的穩定底盤

阿里雲飛天企業版憑藉在產品支持範圍、功能滿足度、場景覆蓋度、易用性、安全隔離等多方面的成熟度，已經為金融、政務、能源、電力、交通、製造、醫療等各行業數百位客户提供全棧雲平台容災產品服務。

IT架構的演進勢不可擋，隨着政企不斷在雲平台上遷移、構建創新應用和核心應用，由傳統IT容災向全棧雲容災轉身越來越急迫。阿里雲以飛天企業版容災解決方案為各行業數智轉型提供堅實的雲底座支撐，讓“穩定”從一次選擇，變成持續承諾。

原文鏈接

本文為阿里雲原創內容，未經允許不得轉載。