5月底的那波運維故障余波未了，端午期間阿里云的香港機房又出現了電力故障，很多金融圈的小伙伴紛紛關注和討論數據中心的災備方案。同時，《大話存儲》的作者張冬寫了一篇《淺談容災和雙活數據中心》，從底層和硬件實現的角度深入解析了容災和雙活的原理和觀點，張冬說的“淺談”是謙虛，對底層原理的闡述再淺也不容易。我這篇淺談真的是淺談了，換個角度，從應用和業務的角度，談談我對災備和多活架構演進的一些體會與觀點，更多的是還是拋磚引玉。

一、過去：集中式架構下的數據復制

國內的災備體系建設，起源和最受重視的都是金融行業。 2005 年 4 月：國信辦發布了《重要信息系統災難恢復指南》，是國內第一份針對災難恢復的指南文件。 2008 年2 月：中國人民銀行發布了《銀行業信息系統災難恢復管理規范》（ JR/T0044-2008），是國內金融行業發布的第一份針對災難恢復的金融國家標準。到 2011 年 12 月，銀監會《商業銀行業務連續性監管指引》【 2011 】（ 104 號）的發布，標志著國家和行業監管部門對災備的重視程度已經提升到了一個新的高度，從單純 IT 領域的容災備份上升到了保障業務持續運行的層面，業務連續性管理（ BCM ）成為了一個專業領域受到廣泛重視。

技術架構層面， IBM 引入的“兩地三中心”概念和架構成為了災備的代名詞，標準做法是北京上海建兩個生產數據中心，再在其中一個城市建一個專門的災備中心，滿足生產和災備相隔 1000 公里以上監管要求。過去金融行業普遍采取的是集中式架構，也就是今天常說的“ IOE ”架構，核心業務數據通過集中的數據庫，最終寫入到集中的存儲中去。因此，“兩地三中心”的災備方案就通過數據庫的數據復制或者存儲的數據復制技術，在廣域網上進行數據的復制，最核心的三個要素是：數據庫、存儲、網絡。

這種災備體系體系架構的優點和缺點同樣顯著。優點是基于數據庫和存儲的復制技術的通用性很強，對于應用透明。缺點是這種備份還是數據級別的備份，在 RPO （Recovery Point Objective ，企業能容忍的最大數據丟失量）和 RTO （ Recovery Time Objective ，企業能容忍的恢復時間）這兩個指標中間，更強調的是數據安全。因此，往往投入巨額資金建設的災備中心，只能用于冷備，也叫單活，在需要的時候由人工手工切換生產和災備中心。

這種集中式架構下的數據復制架構，形成很多年了，雖然說是過去，但到今天為止仍然是主流的做法。

二、現在：論數據復制的異地多活不可能定律

在過去兩地三中心的架構下，大家的普遍痛苦是建一個災備中心容易，維護一個災備中心太難了。在單活模式下，為保持生產和災備中心的設備比例，需要不斷的追加災備的硬件投入，對于備份數據的有效性、恢復的及時性也要不斷的進行驗證演練，同時，出于對災備切換之后的數據丟失風險的考慮，不到萬不得已，企業是不敢貿然切換。因此，傳統的災備體系就和核武器一樣，是最后一道防線，不得不建，但建完之后，維護成本非常高，能用到的機會非常少，投入產出比很低。

在這樣的情況下，數據中心多活很自然的成為大家的追求目標，如果能和服務器集群一樣，多個數據中心能同時提供服務，災備中心也同時承載生產中心的職能，自然是最好的災備解決方案。多活方案看上很美，但早在 2008 年，我們在支付寶建第一個災備中心時，就發現基于數據復制異地多活數據中心是不可能實現的。

1. 數據庫的多活模式。 如果通過數據復制的方式，就意味著需要實現雙向數據復制，并通過數據加鎖的方式解決兩邊的寫沖突，無論是數據庫實現還是存儲實現都會帶來性能的急劇下降，對于聯機交易系統是不可接受的。

2. 數據庫單活、應用多活的模式。 數據庫采用傳統單活容災模式，讓應用通過網絡訪問遠程的主數據庫，實現應用層面的多活，這是一個看似合理的解決方案，也是當時支付寶災備的建設目標。當時相隔 100 公里的機房的光纖網絡延時是 2 毫秒，認為能滿足應用對數據庫的訪問。但是真正實施時，才發現應用和數據庫之間請求過于頻繁，一個事務中間往往高達 10 多次交互，總體延時累加之后就發現性能無法支撐。這個結果，對于實時性要求很高的聯機交易系統還是不能接受。

時隔幾年之后，今天又有不少廠商在宣傳基于產品實現的異地多活數據中心方案。雖說技術發展很快，但我們對此可以有個簡單的判斷：不管基于什么方案，數據復制都是依賴網絡的，網絡帶寬可以不斷的擴大，而光纖網絡隨著距離的增長帶來的延時問題是物理學上的限制，除非找到比光速更快的介質，否則在依靠底層數據模式下不可能找到多活的解決方案。

三、現在：互聯網思維下的災備創新和技術突破

基于以上的認識，支付寶在第一個多活數據中心的方案嘗試失敗后，很快以互聯網思維尋找新的解決方案。我們發現，在傳統的兩地三中心的方案里面，異地的備份是要做能切換的應用級備份，而支付寶作為第三方支付機構，對于災備和業務連續性的重視和災備目標等同于銀行，但當時的監管要求沒有銀行那么明確。因此，首先從業務的目標出發，對傳統的災備思維進行了革新，找到了創新的災備解決方案：同城多活加異地數據災備。

該方案主要依賴于以下幾個因素：

1. 同城多數據中心。 在光纖延時的問題上，既然異地的網絡延時無法解決，就繞過該問題。依托于阿里在杭州的企業骨干網，將同城多個機房通過裸光纖連在一起，發展同城多中心。在裸光纖距離不超過 40 公里的情況下，可以視為在一個局域網中間，延時可接受。

2. 數據庫分庫分表。 隨著“去 IOE ”的進行，支付寶的數據庫變成了分布式的 X86 服務器和 Mysql ，數據保護模式也由集中存儲變成“三副本”，每個數據庫的三個副本服務器分布在同城的三個數據中心， 1 主 2 從，由應用進行數據的復制和一致性的保證。

3. 應用層面實現的同城多活。 數據庫實現分布式之后，同城的應用可以跨機房寫數據庫，應用層面的多活就實現了。而在強化了應用層面的容錯和故障處置手段之后，在主數據庫故障時，應用可快速把主數據庫切換到其他機房的從數據庫。在這種機制下，不單可以實現數據庫的多活，而且進一步實現了數據中心層面的同城多活，理論上任何一個數據中心中斷都不會導致業務中斷，切換過程也非常簡單。

4. 異地遠程數據備份。 在相隔 1000 公里的遠程機房，由應用程序進行數據的備份。通常只需要把關鍵的賬務數據變動增量同步過去，由于不用備份應用系統，實現起來較為簡單。

支付寶構建的這一代災備體系，乍一看似乎不符合傳統的金融行業的規范，但確實達到了監管的要求，實踐效果非常好。其最大的改變是在保證金融行業的不丟數據（RPO 趨近于 0 ）的前提下，對 RTO 數據恢復時間做了分類，在最常見的單節點或者單機房的故障場景下， RTO 時間也趨近于 0 ，這是遠遠超過傳統的災備方案效果。而最極端的同城多機房故障，這種概率的可能性極低，真要發生也變成一個需要社會應對的問題，在這個情況下，只要遠程數據備份在， RTO 時間長一點也是完全可以接受的事情。這種務實的災備思路看似簡單和取巧，實際上對技術的要求很高，如果沒有這套分布式架構和應用的配套改造，仍然是無法實現的。

四、未來：超融合的異地多活

基于應用的同城多活實施成功后，阿里從 2013 年就開始嘗試在異地多活方面的突破。要異地多活，就不可避免的遇到跨中心數據交互和網絡延時的問題，其解決思路也很簡單，在同城多活的基礎上進行“單元化”、“服務治理”和“異地數據交互優化”。“單元化”保障每個單元之中的基礎設施、應用系統、數據庫都齊備，大部分業務處理都可以在本單元之中完成；“服務治理”梳理業務之間的耦合關系，盡量減少和降低跨單元之間的數據交互，“異地數據交互優化”則是降低異地數據交互的頻率、提高異地之間數據交互的效率，使業務系統可以適應異地的網絡延時。具體的一些技術背景可以參考阿里巴巴技術保障部畢玄大師前段時間發表的文章。

隨著集中式架構向分布式架構的轉換，以及云計算的實施，未來海量系統的運維模式之下，對于災備和業務連續性的要求會越來越高，多活數據中心一定是未來發展的方向。今天在這個領域，各大 IT 廠商以及 BAT 為代表的互聯網企業都在重點發展，但是趨于兩個極端。傳統廠商局限于硬件和底層層面，把底層做的越來越復雜，互聯網公司則采取軟件定義數據中心的模式，完全拋棄了硬件的高可靠，把自身的業務層做的越來越復雜。最近的幾個運維故障，也表明了當前多活還處于一個探索期，方法論和實施經驗還需要磨合。

未來企業數據中心一定是需要簡單最可靠的多活解決方案。個人淺見，未來一個可能的解決方案是超融合架構下的多活數據中心，總體的復雜度不會降低，但可以多方分工各自負責最擅長的領域，即 IT 廠商提供對于多活的底層技術支撐，互聯網公司提供在應用開發框架層面的最佳實踐和指引，各企業結合各自的業務目標做整合與開發。另外一個可能的趨勢是，隨著云計算實施的深入，未來的生產和災備中心都將在基于云來建立，大部分企業都不再需要單獨建立數據中心。