阿里“三活”數據中心實踐經驗：沒人能做，我們就自己做

發表于2015-10-29 18:11| 4813次閱讀| 來源CSDN| 4 條評論| 作者郭雪梅

阿里云數據中心運維多活數據中心架構設計 width="22" height="16" src="http://hits.sinajs.cn/A1/weiboshare.html?url=http%3A%2F%2Fwww.csdn.net%2Farticle%2F2015-10-29%2F2826079&type=3&count=&appkey=&title=%E4%BB%8E%E5%8D%95%E6%9C%BA%E6%88%BF%E5%88%B0%E5%A4%9A%E5%8D%95%E5%85%83%EF%BC%8C%E2%80%9C%E5%90%8C%E5%9F%8E%E5%8F%8C%E6%9C%BA%E6%88%BF%E2%80%9D%E3%80%81%E2%80%9C%E5%BC%82%E5%9C%B0%E5%8F%8C%E6%B4%BB%E2%80%9D%EF%BC%8C%E5%86%8D%E5%88%B0%E2%80%9C%E5%BC%82%E5%9C%B0%E5%A4%9A%E6%B4%BB%E2%80%9D%EF%BC%88%E7%AC%AC%E4%B8%89%E4%B8%AA%E7%82%B9%E8%B7%9D%E7%A6%BB1000%E5%85%AC%E9%87%8C%E4%BB%A5%E4%B8%8A%EF%BC%89%E3%80%82%E9%98%BF%E9%87%8C%E5%B7%B4%E5%B7%B4%E6%8A%80%E6%9C%AF%E4%BF%9D%E9%9A%9C%E9%83%A8%E6%AF%95%E7%8E%84%E8%AF%A6%E8%A7%A3%E9%9D%A2%E5%AF%B9%E8%B7%9D%E7%A6%BB%E5%B8%A6%E6%9D%A5%E7%9A%84%E5%BB%B6%E6%97%B6%E5%92%8C%E6%95%B0%E6%8D%AE%E4%B8%80%E8%87%B4%E6%80%A7%E7%9A%84%E6%8C%91%E6%88%98%EF%BC%8C%E4%BB%A5%E5%8F%8A%E6%B2%A1%E6%9C%89%E5%85%88%E4%BE%8B%E5%8F%AF%E4%BB%A5%E5%AD%A6%E4%B9%A0%E4%BA%A4%E6%B5%81%E6%97%B6%EF%BC%8C%E5%A6%82%E4%BD%95%E6%9D%A5%E7%AA%81%E7%A0%B4%EF%BC%9F&pic=&ralateUid=&language=zh_cn&rnd=1446210073078" frameborder="0" scrolling="no" allowtransparency="true">摘要：從單機房到多單元，“同城雙機房”、“異地雙活”，再到“異地多活”（第三個點距離1000公里以上）。阿里巴巴技術保障部畢玄詳解面對距離帶來的延時和數據一致性的挑戰，以及沒有先例可以學習交流時，如何來突破？

關于阿里巴巴技術保障部在集團內部的地位，與阿里云的密切關系，為何連續多年天貓雙十一總指揮都是技術保障部負責人劉振飛（現阿里巴巴集團首席風險官），以及他們今年在數據中心領域的突破性實踐，可以先看下這三篇文章 《阿里技術保障部：阿里云的幕后英雄》、 《阿里11.11第六年,用我們的視角直播技術與數據》和 《千島湖數據中心詳解》。而對今年支持天貓雙十一背后最新技術的觀察，這篇或是一個新的窗口。

當在2015杭州云棲大會上看到阿里巴巴技術保障部研究員畢玄時，首先閃過腦海的就是又有“干貨”了。

畢玄，2007年加入阿里，到現在已經8年時間。其中，2008-2010年在淘寶平臺架構部負責HSF的設計和實現，2011年在數據平臺部負責Hbase改進和落地，2012年在核心系統部負責淘寶虛擬化產品和技術，2013年到技術保障部，專注于應用可維護性、穩定性、軟硬結合，主要負責能容量架構、異地多活項目（以確保當故障出現時快速恢復）和研究如何通過軟件來降低總體成本（硬件是另外一位保障部門同事負責）。

?

在他看來，當阿里集團的雙十一規模越來越大，與平時量差距越來越多時；當因雙十一而產生的投入成本越來越高，且不可控因素提升時；當數據已經積累到絕對的大數據時……，如何減掉雙十一的峰值投入成本？如何計算出更多的數據價值？是技術保障部門所要重點考慮和實踐的。而實踐成果已有很多，其中最奪目的是“三活”。

CSDN：2015天貓雙十一指揮部將移師北京，但作戰部還在杭州。對技術保障部有影響么？你在其中會負責什么？

畢玄：影響不大。我現在負責技術保障性能架構團隊,今年負責的最重要的項目就是多活，去年我們做到了異地雙活（詳見阿里超大數據中心“異地雙活”實踐），今年是異地三活。和去年雙活相比，今年最大變化是去年兩個點相隔的距離比較近，今年第三個點距離非常遠（1000公里以上）。我們真正從比較近的異地，走到了更遠的異地，也證明我們在全國范圍內已經可以選任意點部署阿里交易系統。從技術來看，2到3是質的變化，挑戰極大。而未來從3到4，相信就會比較順暢了。

CSDN：從“兩地三中心”、“同城雙活”到“異地雙活”，這方面的嘗試很多企業都在做。但“三活”很少。分享下其中遇到的困難和挑戰？

畢玄：除了我們，確實還沒有看到國內其他企業做出“三活”。挑戰很多，也很大。第一大問題就是距離帶來的延時問題，去年雙活的情況下兩點的延時是在10毫秒以內，今年的距離物理延時會比去年多好幾倍。我們的系統是一個巨大的分布式系統，訪問任何一個淘寶的頁面，其實背后的交互都在上百次，單點延時再乘上這個倍數，如果不能很好的解決延時問題，說不定用戶連頁面都打不開，更不要說雙十一那么高的訪問量的情況下。所以延時問題是多活中一定要解決的核心問題。因為隨著距離越遠這個問題會越大，去年的距離不算太遠，有些問題沒有足夠的暴露出來。而在今年在建設另外一個較遠的點的時候，就已經看到去年忽視的某些問題被再次放大出來，必須解決。

第二大問題是數據一致性?；詈鸵郧敖鹑谛袠I的冷備做法不一樣，冷備其實只有一個數據庫是可寫的，因為只有一個點是可以寫的，保證了數據不會錯亂。多活以后則變成多個點都可以寫，如果兩個點同時寫了一個用戶的同一行數據，那這個時候就無法判斷合過來的時候，到底哪邊的數據是對的，這是一個很大的問題。阿里平臺上都是交易，和社交及搜索都不一樣，因為涉及到資金，任何錯誤都會影響用戶信任。

所以在多活實踐中，延遲問題相對可控，也許只是用戶響應時間從1秒變成3秒，影響體驗，但數據一致性是最要保住的點，因為這影響信任。當然我們希望都能保證。

實際上，去年雙活中已經積累了很多經驗，但雙活數據復制的復雜程度比多活要低，因為兩點是對等的，兩邊都100%，為了能夠切走，流量可以從這個中心切到另外一個數據中心去。但是在三點的情況下一定不是這樣的，一定會變成不對等的狀況，數據復制的邏輯就更加復雜，所以我們做了很多架構設計和開發工作，并且已經很好解決這些困難了。

CSDN：剛提到雙活沒有暴漏出的問題，還有哪些？

畢玄：主要解決延時問題，盡管去年用戶層面感知不到，但今年距離變長，延時會增加好幾倍。比如測試階段向第三個點引流的時候，我們發現某些功能點明顯不能用，會超時。解決這個問題的方法就是盡量避免跨數據中心調用，我們就通過工具軟件分析，比如你訪問這次頁面背后要交互100次，這100次交互有多少次是要跨出數據中心去訪問的，然后再做應用調整，確保用戶單次操作背后的所有調用都在同一個數據中心內。因此解決延時問題的挑戰不在于技術難度，而在于技術的復雜度，因為會涉及的幾百甚至上千個系統，要通過有效的工具和反復的演練確保沒有遺漏。

CSDN：多系統演練一向是雙十一技術預案的重點（去年雙11，阿里準備500多套技術預案，前年是2000多套）。今年的多活演練已經完成？

畢玄：多活搭建遠早雙十一，基本在雙活完成以后我們就開始做多活的規劃了。剛才介紹，延時最大的問題在于一個頁面展現的過程中有多少次在跨出數據中心去訪問，需要強大的系統而不是靠人解決，所以我們不僅靠預案，更要靠精密的雷達系統，這套系統實時告訴我們那些調用跨機房了。然后再由經驗非常豐富的工程師介入分析，為什么會出現跨機房調用，怎么解決。簡單的情況只需要做一下部署，復雜的情況就需要認真分析怎么處理數據。

對于異地多活架構，在雙十一當天不會因為延時去啟動預案，必須在雙十一之前就要把這些問題全部解掉。在阿里，我們現在已經不太談災備的概念了，而是通過多活的架構保障高可用性，原因是災備主要靠冷備，真的出現問題的時候，基本沒人敢做切換的決策，因為不知道切換一次要多久，也不知道切過去能不能用，一旦切換也不能恢復業務，那就悲劇了。但異地多活架構不一樣，因為每個數據中心都一直在提供服務的，我們現在每天都可以根據業務需要，在多個數據中心之間調度淘寶的流量，我今天中午來之前就剛剛做過一次切流。但我們的動作，用戶是不會有任何感受的。所以對多活架構來說，我們能做到如果一個數據中心出問題，就敢把流量直接全部遷走。

實際上，雙活2014年8月就完成了，也成功了支撐了去年的雙11，三活其實也跑了很久了，基本沒有什么問題。我們很早就啟動了今年的雙11技術準備，包括數據中心布局、軟件重構等，都已經落地并作了多次演練，現在主要是打磨細節。

CSDN：具體技術細節舉例分析下？

畢玄：保證數據一致性，多點同時寫就必須把數據庫做切片，確保這個用戶在這個時間必須寫入這個數據中心，保證邏輯正確不變。但要確保這件事的發生，我們在技術上做了多層保護。首先，一個用戶的流量進來后會有很多應用層，每一層都有可能進來之后可能進到不同數據中心，我們在每一層都做好攔截保護，每一層都看看你是不是應該在這一層，如果不在的話我們就把你引到正確的一邊，即使你進來的時候訪問錯了，比如你應該在B數據中心，但是你進到A的數據中心去了，但當你訪問一個頁面，你進來我們會發現你不在這個數據中心，就會把你跳過去。其次，容易引發數據錯亂的另一個原因是多活的情況下如果要做到可以切流量，就意味著我的每個數據中心一定會有數據的冗余，那在一定冗余的情況下怎么來保證。為什么雙活的情況下問題會更加簡單，是因為雙活兩邊數據中心是對等的，就不會循環復制。但在三活的情況下則要注意避免這個問題，保證數據復制的方向正確、路徑正確，我們會層層保護用戶數據寫入正確的數據中心。

第三，切流量的過程也需要注意，避免數據錯亂。如果沒有控制好這個過程，你認為在那個數據中心還繼續寫，事實上那個數據中心已經不用了，這個時候永遠看不到你的數據。怎么保證這個過程一定不會出問題？分布式系統的整個切換過程是非常復雜的，意味著層層都要感應到這一次切換，如果沒感應到可能出問題，也可能不會出問題，我們為了做到數據保護在背后做了很多的事情。我們會檢查每個點的數據是不是符合我們想要的規則，假如我希望這個數據中心有一定百分比的數據，還有可能是特定用戶的數據，那我們都會去檢查，如果你合適的話，那我們會立刻知道是有問題的。除了數據檢測之外還會做業務層面的檢查，如果發現你在A數據中心和在B數據中心買的兩個東西的價格是不一樣的，同等的兩個身份的人，如果兩個點看到的價格是不一樣的，顯然是有問題的。我們從業務層面以及本身數據層面都會做這些處理。

CSDN：雷達系統和監控監測系統是基于什么開發的？

畢玄：雷達系統和監控監測系統不基于任何平臺，沒有任何外部的系統，就我們純粹自研的系統。雷達系統是阿里自研的eagleeye。eagleeye和監控監測系統都是基于Java自研的。為什么對阿里而言，雙活和多活都是大的技術挑戰。就是因為淘寶之前的架構改造是有一定參考對象的。但在雙活和三活改造中，我們碰到的所有的問題都是沒有參考對象的，只能靠自研的，在自研的過程中碰到問題知能自己解決，開源軟件都不涉足這個領域。

CSDN：從規模和復雜度來說，谷歌、Facebook是否有相關經驗？

畢玄：谷歌、Facebook在多活架構上面臨和我們一樣的挑戰。但阿里的業務類型要比社交和搜索都復雜。對社交而言，一個用戶的數據其實都是你用戶之間相關的數據，但是一個電商網站數據的特征是除了你自己的數據以外，比如我訪問淘寶除了我自己的數據以外，我需要知道商品的數據，知道賣家的數據，而社交并不需要如此，所以他們可以采用異步，而延時對異步是沒有影響的，但是對同步就是很大的挑戰。但交易網站，整個過程必須同步的，因為只要不同步，這個用戶就喪失購買興趣了。比如你拍一個東西，點了購買，告訴你要稍等一下讓我后面確認一下，然后我再給你展示，你再來買，用戶立刻就不買了。

CSDN：要實現雙活或者多活的技術朋友們分享下你的經驗？

畢玄：做這件事情我們用了三年，從單機房到多單元，到同城雙機房，到異地雙活，再到今年異地多活，整個投入非常巨大，而且要有很好的節奏控制。畢竟，這對于我們來講，是為一個飛行的飛機換引擎的過程，在做這么大規模的架構改造的同時，不能對業務有任何影響。異地多活，確實會影響數據中心的布局，所以隨著變化要控制好節奏。技術經驗方面，要有強大的分析系統來控制延時問題，如果連跨出去多少都不知道，是無法處理的。此外，業務方面，如果要做到在本地的數據中心完成動作，一定意味著除了訪問之外，怎么讓依賴的數據盡可能在本地。

CSDN：可以再詳細展開下？

畢玄：也許我們前一輪的架構改造對更多企業有更多的意義。異地雙活除了數據中心、網絡層，軟件層面的技術投入也是巨大的。因為其不是一個通用方案，而是結合業務所做的動作，這就需要原有的基礎軟件都要改造才能支持。所以人力和投入都是很大的技術改造。對很多規模略小的企業而言，在業務沒有迫切需求的時候，異地雙活只是需要關注的方向。而同城雙活比較現實，意義也更大。因為很多創業公司最害怕的是服務不可用，比如之前滴滴快的打仗的時候就很明顯，一旦一家出現服務問題，用戶量很快就會飄移到另一家。好多情況為了打這一仗前期已經投入了很多市場的費用，錢已經花出去了，結果“軍火”（技術平臺能力）不夠。在同城雙活的時候，地址訪問是要特別重視的問題。兩個機房之間的交互，以前的簡單方案是我要訪問什么系統，就用一個地址去訪問的，但在雙活的架構架構，地址訪問絕對不能出現，因為一旦出現就意味著我切不了，所以這些地方全部都要改造，把跟地址相關的部分被收攏到系統里，這個切換系統是可以全部操作的。像這種項目中最大的其實不是一個技術難度問題，而是一個復雜度的問題，因為當要做這個事情的時候，通常意味著這家公司有一定的規模了，肯定不是一開始就做了。當你有了一定的規模的時候，意味著各種現象都已經出現了，怎么把所有的現象全部解決掉，這是一個最復雜的問題。我們以前做同城雙活也花了很長的時間，是經常演練的，我們是靠演練證明我們是可以的，演練了非常多次才成功。

阿里云上的持續交付平臺（CRP，Continuous Release Platform)

CSDN：未來會不會將這些開發的系統和經驗能夠變成標準化產品在云平臺上輸出？

畢玄：云棲大會上會看到持續交付平臺（CRP，Continuous Release Platform)，供軟件生命周期全環節服務。包括項目管理，需求管理，缺陷管理，代碼托管，開發環境管理，全量構件庫管理，持續交付流水線，構建管理，依賴管理，測試管理，一鍵部署，監控管理，團隊協作等功能，就是從開發一直到上線整個過程的云產品。我們的思路不是對外輸出一份文檔或者講一個PPT，而是將所有的變成云產品去對外輸出，持續交付是其中的一個。而異地多活中，為了保證多點數據同步以及解決時延的自研產品，已經變成阿里云的商業產品——DTS數據傳輸。我們會慢慢將這些內部已經經過大規模驗證過的技術逐步變成云產品對外部的用戶開放。實際上，在我們從同城雙活走向異地多活中，基本將所有軟件都全部改造了一輪，其中也添加了很多基礎產品，如DTS，還有內部服務、系統交互、消息服務，都已經在云上。所以對用戶而言，不用向我們一樣自己摸索在改造，而是直接可以選擇這些能夠達到異地多活的產品，難度會降低很多。

馬上就是雙十一，期待阿里巴巴技術保障及其他技術部門更多的精彩分享，也期待更多電商企業的技術實戰分享。

總結

以上是生活随笔為你收集整理的阿里“三活”数据中心实践经验：没人能做，我们就自己做的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。