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

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

國內(nèi)的災備體系建設，起源和最受重視的都是金融行業(yè)。 2005 年 4 月：國信辦發(fā)布了《重要信息系統(tǒng)災難恢復指南》，是國內(nèi)第一份針對災難恢復的指南文件。 2008 年2 月：中國人民銀行發(fā)布了《銀行業(yè)信息系統(tǒng)災難恢復管理規(guī)范》（ JR/T0044-2008），是國內(nèi)金融行業(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è)領域受到廣泛重視。

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

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

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

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

在過去兩地三中心的架構(gòu)下，大家的普遍痛苦是建一個災備中心容易，維護一個災備中心太難了。在單活模式下，為保持生產(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)性能無法支撐。這個結(jié)果，對于實時性要求很高的聯(lián)機交易系統(tǒng)還是不能接受。

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

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

基于以上的認識，支付寶在第一個多活數(shù)據(jù)中心的方案嘗試失敗后，很快以互聯(lián)網(wǎng)思維尋找新的解決方案。我們發(fā)現(xiàn)，在傳統(tǒng)的兩地三中心的方案里面，異地的備份是要做能切換的應用級備份，而支付寶作為第三方支付機構(gòu)，對于災備和業(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)起來較為簡單。

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

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