畢玄是阿裏巴巴技術保障部的研究員，負責性能容量架構。數據中心異地多活項目就是他主導的。

InfoQ：首先請介紹一下數據中心異地多活這個項目。

畢玄：這個項目在我們內部的另外一個名字叫做單元化，雙活是它的第二個階段，多活是第三個階段。所以我們把這個項目分成三年來實現。所謂異地多活，故名思義，就是在不同地點的數據中心起多個我們的交易，並且每個地點的那個交易都是用來支撐流量的。
InfoQ：當時為什麽要做這件事呢？

畢玄：其實我們大概在2009還是2010年左右的時候，就開始嘗試在異地去做一個數據中心，把我們的業務放過去。更早之前，我們做過同城，就是在同一個城市建多個數據中心，應用部署在多個數據中心裏面。同城的好處就是，如果同城的任何一個機房掛掉了，另外一個機房都可以接管。做到這個以後，我們就在想，異地是不是也能做到這樣？整個業界傳統的做法，異地是用來做一個冷備份的，等這邊另外一個城市全部掛掉了，才會切過去。我們當時也是按照這個方式去嘗試的，嘗試了一年左右，我們覺得冷備的方向對我們來講有兩個問題：第一個問題是成本太高。我們需要備份全站，而整個阿裏巴巴網站，包括淘寶、天貓、聚劃算等等，所有加起來，是一個非常大的量，備份成本非常高。第二個問題是，冷備並不是一直在跑流量的，所以有個問題，一旦真的出問題了，未必敢切過去。因為不知道切過去到底能不能起來，而且整個冷備恢復起來要花多長時間，也不敢保證。因此在嘗試之後，我們發現這個方向對我們而言並不好。那為什麽我們最後下定決心去做異地多活呢？最關鍵的原因是，我們在2013年左右碰到了幾個問題。首先，阿裏巴巴的機房不僅僅給電商用，我們有電商，有物流，有雲，有大數據，所有業務共用機房。隨著各種業務規模的不斷增長，單個城市可能很難容納下我們，所以我們面臨的問題是，一定需要去不同的城市建設我們的數據中心。其次是我們的伸縮規模的問題。整個淘寶的量，交易量不斷攀升，每年的雙十一大家都看到了，增長非常快。而我們的架構更多還是在2009年以前確定的一套架構，要不斷的加機器，這套架構會面臨風險。如果能夠做到異地部署，就可以把伸縮規模縮小。雖然原來就是一套巨大的分布式應用，但是其實可以認為是一個集群，然後不斷的加機器。但是在這種情況下，隨著不斷加機器，最終在整個分布式體系中，一定會有一個點是會出現風險的，會再次到達瓶頸，那時就無法解決了。這兩個問題讓我們下定決心去做異地多活這個項目。為什麽我們之前那麽糾結呢？因為整個業界還沒有可供參考的異地多活實現，這就意味著我們必須完全靠自己摸索。而且相對來講，它的風險以及周期可能也是比較大的。

畢玄：以去年雙十一為例，當時我們在杭州有一個數據中心，在另外一個城市還有個數據中心，一共是兩個，分別承擔50%用戶的流量。就是有50%的用戶會進入杭州，另外50%會進入到另外一個城市。當用戶進入以後，比如說在淘寶上看商品，瀏覽商品，搜索、下單、放進購物車等等操作，還包括寫數據庫，就都是在所進入的那個數據中心中完成的，而不需要跨數據中心。
InfoQ：這樣的優勢是？

畢玄：異地部署，從整個業界的做法上來講，主要有幾家公司，比如Google、Facebook，這兩家是比較典型的，Google做到了全球多個數據中心，都是多活的。但是Google具體怎麽做的，也沒有多少人了解。另外一家就是Facebook，我們相對更了解一些，Facebook在做多個數據中心時，比如說美國和歐洲兩個數據中心，確實都在支撐流量。但是歐洲的用戶有可能需要訪問美國的數據中心，當出現這種狀況時，整個用戶體驗不是很好。國內的情況，我們知道的像銀行，還有其他一些行業，傾向於做異地災備。銀行一般都會有兩地，一個地方是熱點，另一個地方是冷備。2013年工商銀行出現故障時，就沒有辦法做出決定，到底要不要切到災備數據中心，他們會碰到我們以前摸索時所面對的問題，就是不確定切換過程到底要多久，災備中心到底多久才能把流量接管起來。而且接管以後，整個功能是不是都正常，也可能無法確定。剛才也提到過，冷備的話，我們要備份全站，成本是非常高的。如果每個地點都是活的，這些數據中心就可以實時承擔流量，任何一點出問題，都可以直接切掉，由另外一點直接接管。相對冷備而言，這是一套可以運行的模式，而且風險非常低。

畢玄：沒錯。因為在異地或同城建多個數據中心時，建設過程中一定都會保有一定的冗余量。因為要考慮其他數據中心出現故障時加以接管。不過隨著數據中心建設的增多，這個成本是可以控制的。如果有兩個異地的數據中心，冗余量可能是一倍，因為要接管全量。但是如果有三個數據中心，互為備份，就不需要冗余兩倍了。
InfoQ：這個項目挑戰還是比較大的。您可以介紹一下研發過程中遇到的挑戰嗎？又是怎樣克服的？

畢玄：對於我們來講，異地項目最大的挑戰是延時。跨城市一定會有延時的問題。在中國範圍內，延時可能在一百毫秒以內。看起來單次好像沒什麽，但是像淘寶是個很大的分布式系統，一次頁面的展現，背後的交互次數可能在一兩百次。如果這一兩百次全部是跨城市做的，整個響應時間會增加很多，所以延時帶來的挑戰非常大。在解決挑戰的過程中，我們會面臨更細節的一些問題。怎樣降低延時的影響，我們能想到的最簡單、最好的辦法，就是讓操作全部在同一機房內完成，那就不存在延時的挑戰了。所以最關鍵的問題，就是怎樣讓所有操作在一個機房內完成。這就是單元化。為什麽叫單元化，而沒有叫其他名字呢？原因在於，要在異地部署我們的網站，首先要做一個決定。比如說，冷備是把整個站全部備過去，這樣可以確保可以全部接管。但是多活的情況下，要考慮成本，所以不能部署全站。整個淘寶的業務非常豐富，其實有很多非交易類型的應用，這些功能可能大家平時用的不算很多。但對我們來講，又是不能缺失的。這部分流量可能相對很小。如果這些應用也全國到處部署，冗余量就太大了。所以我們需要在異地部署的是流量會爆發式增長的，流量很大的那部分。雖然有冗余，但是因為流量會爆發式增長，成本比較好平衡。異地部署，我們要在成本之間找到一個平衡點。所以我們決定在異地只部署跟買家交易相關的核心業務，確保一個買家在淘寶上瀏覽商品，一直到買完東西的全過程都可以完成。其他一些功能就會缺失，所以我們在異地部署的並非全站，而是一組業務，這組業務就成為單元。比如說我們現在做的就是交易單元。這時淘寶會面臨一個比Google、Facebook等公司更大的一個挑戰。像Facebook目前做的全球化數據中心，因為Facebook更多的是用戶和用戶之間發消息，屬於社交領域。但淘寶是電商領域，對數據的一致性要求非常高，延時要求也非常高。還有個更大的挑戰，那就是淘寶的數據。如果要把用戶操作封閉在一個單元內完成，最關鍵的是數據。跟冷備相比，異地多活最大的風險在於，它的數據會同時在多個地方寫，冷備則不存在數據會寫錯的問題。如果多個地方在寫同一行數據，那就沒有辦法判斷哪條數據是正確的。在某個點，必須確保單行的數據在一個地方寫，絕對不能在多個地方寫。為了做到這一點，必須確定數據的維度。如果數據只有一個維度，就像Facebook的數據，可以認為只有一個緯度，就是用戶。但是像淘寶，如果要在淘寶上買一個東西，除了用戶本身的信息以外，還會看到所有商品的數據、所有賣家的數據，面對的是買家、賣家和商品三個維度。這時就必須做出一個選擇，到底用哪個維度作為我們唯一的一個封閉的維度。單元化時，走向異地的就是買家的核心鏈路，所以我們選擇了買家這個維度。但是這樣自然會帶來一個問題，因為我們有三個維度的數據，當操作賣家商品數據時，就無法封閉了，因為這時一定會出現需要集中到一個點去寫的現象。從我們的角度看，目前實現整個單元化項目最大的幾個難點是：第一個是路由的一致性。因為我們是按買家維度來切分數據的，就是數據會封閉在不同的單元裏。這時就要確保，這個買家相關的數據在寫的時候，一定是要寫在那個單元裏，而不能在另外一個單元，否則就會出現同一行數據在兩個地方寫的現象。所以這時一定要保證，一個用戶進到淘寶，要通過一個路由規則來決定這個用戶去哪裏。這個用戶進來以後，到了前端的一組Web頁面，而Web頁面背後還要訪問很多後端服務，服務又要訪問數據庫，所以最關鍵的是要保障這個用戶從進來一直到訪問服務，到訪問數據庫，全鏈路的路由規則都是完全一致的。如果說某個用戶本來應該進A城市的數據中心，但是卻因為路由錯誤，進入了B城市，那看到的數據就是錯的了。造成的結果，可能是用戶看到的購買列表是空的，這是不能接受的。所以如何保障路由的一致性，非常關鍵。第二個是挑戰是數據的延時問題。因為是異地部署，我們需要同步賣家的數據、商品的數據。如果同步的延時太長，就會影響用戶體驗。我們能接受的範圍是有限的，如果是10秒、30秒，用戶就會感知到。比如說賣家改了一個價格，改了一個庫存，而用戶隔了很久才看到，這對買家和賣家都是傷害。所以我們能接受的延時必須要做到一秒內，即在全國的範圍內，都必須做到一秒內把數據同步完。當時所有的開源方案，或者公開的方案，包括MySQL自己的主備等，其實都不可能做到一秒內，所以數據延時是我們當時面臨的第二個挑戰。第三個挑戰，在所有的異地項目中，雖然冷備成本很高，多活可以降低成本，但是為什麽大家更喜歡冷備，而不喜歡多活呢？因為數據的正確性很難保證。數據在多點同時寫的時候，一定不能寫錯。因為數據故障跟業務故障還不一樣，跟應用層故障不一樣。如果應用出故障了，可能就是用戶不能訪問。但是如果數據寫錯了，對用戶來說，就徹底亂了。而且這個故障是無法恢復的，因為無法確定到底那裏寫的才是對的。所以在所有的異地多活項目中，最重要的是保障某個點寫進去的數據一定是正確的。這是最大的挑戰，也是我們在設計整個方案中的第一原則。業務這一層出故障我們都可以接受，但是不能接受數據故障。還有一個挑戰是數據的一致性。多個單元之間一定會有數據同步。一方面，每個單元都需要賣家的數據、商品的數據；另一方面，我們的單元不是全量業務，那一定會有業務需要這個單元，比如說買家在這個單元下了一筆定單，而其他業務有可能也是需要這筆數據，否則可能操作不了，所以需要同步該數據。所以怎樣確保每個單元之間的商品、賣家的數據是一致的，然後買家數據中心和單元是一致的，這是非常關鍵的。這幾個挑戰可能是整個異地多活項目中最復雜的。另外還有一點，淘寶目前還是一個高速發展的業務，在這樣的過程中，去做一次比較純技術的改造，怎樣確保對業務的影響最小，也是一個挑戰。

畢玄：如果網絡帶寬質量不好，1秒是不可能做到的。我們在每個城市的數據中心之間，會以一個點做成自己的骨幹網，所以可以保障不同城市之間的網絡質量。但是要保證到1秒，還必須自己再去做東西來實現數據的同步，這個很關鍵。這個東西現在也在阿裏雲上有開放了。
InfoQ：異地多活其實也是實現高可用。阿裏技術保障的梁耀斌（花名追源）老師會在4月23日~25日的QCon北京2015大會上分享《你的網站是高可用的嗎？》，因為當時的題目和內容也是您參與擬定的。您可以先談一下其中的一些標準嗎？

畢玄：其實每家比較大的互聯網公司，每年可能都會對外公開說，我們今年的可用性做到了多少，比如4個9或者5個9。但是每家公司對可用性的定義可能並不一樣。比如說，有的公司可能認為業務響應時間超過多少才叫可用性損失，而其他公司可能認為業務受損多少就是可用性損失。我們希望大家以後有一個統一的定義，這樣就比較好比較了。我們發現，真正所有做到高可用的網站，最重要的一點是故障恢復時間的控制。因為出故障是不可避免的，整個網站一定會出現各種各樣的故障，關鍵是在故障出現以後，應對能力有多強，恢復時間可以做到多短。追源會在QCon上分享，我們在應對不同類型的故障時，我們是怎樣去恢復的，恢復時間能控制到多短，為什麽能控制到那麽短。在不同的技術能力，以及不同的技術設施的情況下，能做到的恢復時間可能是不一樣的，所以我們會定義一個在不同的技術能力和不同的技術設施的情況下，恢復時間的標準。如果恢復時間能控制得非常好，可能整個故障控制力就非常強。舉個例子，比如淘寶因為能夠做到異地多活，並且流量是可以隨時切換的，所以對於我們來講，如果一地出現故障，不管是什麽原因，最容易的解決方案，就是把這一地的流量全部切走。這樣可以把故障控制在一分鐘以內，整個可用性是非常高的。關於系統的容災能力，國家也有一個標準，最重要的一點就是故障的恢復時間。如果大家都以故障恢復時間控制到哪個級別來衡量，那所有網站就有了一套標準。
InfoQ：好的，異地多活我們就聊到這裏。您現在在維護一個叫做HelloJava的微信公共帳號，您在工作中還是會去調優一些具體的Java問題嗎？

畢玄：沒錯。我在阿裏巴巴這些年來，很多問題有一些會流轉到我這裏，或者有人會反饋到我這裏，所以我會介入到很多問題的排查，現在也是一樣，有些問題我可能就會介入，直接去排查。為什麽有HelloJava那個微信公共賬號呢？最大的原因也是因為，我們都知道很多人會排查故障，有些人可能只是一眼掃過去就已經知道原因是什麽。為什麽呢？他可能已經排查過很多的故障，積累出了經驗，並不一定是這個人的能力比你強，可能就是因為他見的比你多，他對工具使用的熟悉程度比你強。比如說我們看到故障很多，排查故障很厲害的人，他可能就是會善於用各種各樣的工具，而且用的非常熟練。所以我做自己的HelloJava，就是希望有更多的人看到，我們在面對一個故障的時候是怎樣處理的。希望大家即使沒有處理過這個故障，至少也看過一篇文章，也許在下次面對這個故障時，至少有點思路，知道應該怎麽去處理。這個也是阿裏巴巴分享給外面的一些經驗，很多時候就是經驗的積累。
InfoQ：您最近在HelloJava裏提到了一些期待的Java特性，您這邊會將它們反饋給Oracle，讓他們加入嗎？

畢玄：我們跟Oracle官方有過一些交流，談到我們期望的JVM的一些改進。但是說實話，因為我們看到的很多JVM的問題，可能是因為我們流量比較大，我們對Java的性能、高並發有很高的期望。如果能夠突破一點，對於我們整個網站來講，提升可能就是巨大的。但是對於Oracle來講，因為OpenJDK不僅僅是為大公司做的，而是為所有不同的用戶，比如中小企業、大用戶，所以他們必須衡量需求的分布。所以有可能我們的需求，對於Orcale的官方JVM團隊而言，只是小眾需求，他們不大會投入很大精力去做。
InfoQ：所以您這邊的團隊會做一些定制？

畢玄：對。很多人知道，趙海平加入了我們的團隊，如果知道他背景的話，知道他以前做過PHP運行引擎的開放，不僅僅是HipHop的翻譯，還包括怎麽運行整個PHP應用程序。其實你可以認為也會類似VM，因為我們已經看到在Java、JVM的哪些點上如果有突破，可以給我們帶來巨大提升，所以既然官方很難往前推進，那我們就自己來推進。另外趙海平在Facebook做過一套很完善的Profiling系統，他加入阿裏巴巴之後，我們也會做一套。
喜歡小編輕輕點個關系哦！

專訪阿裏巴巴畢玄：異地多活數據中心項目的來龍去脈