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

一、過去：集中式架構下的數(shù)據(jù)復制

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

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

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

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

二、現(xiàn)在：論數(shù)據(jù)復制的異地多活不可能定律

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

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

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

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

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

三、現(xiàn)在：互聯(lián)網(wǎng)思維下的災備創(chuàng)新和技術突破

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

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

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

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

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

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

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

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

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

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

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