一、過去：集中式架構下的資料複製

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

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

　　這種災備體系體系架構的優點和缺點同樣顯著。優點是基於資料庫和儲存的複製技術的通用性很強，對於應用透明。缺點是這種備份還是資料級別的備份

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

　　二、現在：論資料複製的異地多活不可能定律

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

　　在這樣的情況下，資料中心多活很自然的成為大家的追求目標，如果能和伺服器叢集一樣，多個數據中心能同時提供服務，災備中心也同時承載生產中心的職能，自然是最好的災備解決方案。多活方案看上很美，但早在 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 廠商提供對於多活的底層技術支撐，網際網路公司提供在應用開發框架層面的最佳實踐和指引，各企業結合各自的業務目標做整合與開發。另外一個可能的趨勢是，隨著雲端計算實施的深入，未來的生產和災備中心都將在基於雲來建立，大部分企業都不再需要單獨建立資料中心。

延伸閱讀：

專訪阿里巴巴畢玄：異地多活資料中心專案的來龍去脈

http://www.infoq.com/cn/articles/interview-alibaba-bixuan?utm_campaign=infoq_content&

張冬：“淺”談容災和雙活資料中心（上）

http://mp.weixin.qq.com/s?__biz=MzAwNzU3NzQ0MA==&mid=208302383&idx=1&sn=77c0d05175b4c2cb241536f595ab3e1a&scene=1&from=singlemessage&isappinstalled=0#rd

張冬：“淺”談容災和雙活資料中心（下）

http://mp.weixin.qq.com/s?__biz=MzAwNzU3NzQ0MA==&mid=208411923&idx=1&sn=b1108eca56e4ba052ccbc51e15fca017&scene=1&from=singlemessage&isappinstalled=0#rd

本文作者：智錦，資深運維從業者，自動化運維和雲端計算倡導者。曾作為支付寶運維團隊創始人，構建上萬臺伺服器的自動化運維體系；後擔任建設銀行總行副處級技術專家，主持了建行私有云管理平臺的開發；目前為杭州雲霽科技有限公司創始人，做運維領域的創業，致力於打造中國最好的資料中心作業系統。

出處：資料中心作業系統