業(yè)界常用的多活手段及各方案優(yōu)缺點

采用高可用系統(tǒng)架構(gòu)支持重要系統(tǒng)，為關(guān)鍵業(yè)務(wù)提供7x24的不間斷服務(wù)，已經(jīng)成為眾多企業(yè)保障業(yè)務(wù)穩(wěn)定、持續(xù)運轉(zhuǎn)的主要選擇。服務(wù)多活是高可用架構(gòu)重要實施手段，本文介紹了一些業(yè)界常用的多活手段例如同城雙活、兩地三中心、異地多活架構(gòu)設(shè)計方案并詳述了各種方案的優(yōu)缺點。

一、為什么要做多活

隨著移動互聯(lián)網(wǎng)的深入發(fā)展，用戶增長達到一定規(guī)模后，不少企業(yè)都會面高并發(fā)業(yè)務(wù)和臨海量數(shù)據(jù)的挑戰(zhàn)，傳統(tǒng)的單機房在機器容量上存在瓶頸。在一些極端場景下，有可能所有服務(wù)器都出現(xiàn)故障，例如機房斷電、機房火災、地震等這些不卡抗拒因素會導致系統(tǒng)所有服務(wù)器都故障從而導致業(yè)務(wù)整體癱瘓，而且即使有其他地區(qū)的備份，把備份業(yè)務(wù)系統(tǒng)全部恢復到能夠正常提供業(yè)務(wù)，花費的時間也比較長。為了滿足中心業(yè)務(wù)連續(xù)性，增強抗風險能力，多活作為一種可靠的高可用部署架構(gòu)，成為各大互聯(lián)網(wǎng)公司的首要選擇。

1、多活場景

多活架構(gòu)的關(guān)鍵點就是指不同地理位置上的系統(tǒng)都能夠提供業(yè)務(wù)服務(wù)，這里的“活”是指實時提供服務(wù)的意思。與“活”對應(yīng)的是字是“備”，備是備份，正常情況下對外是不提供服務(wù)的，如果需要提供服務(wù)，則需要大量的人工干預和操作，花費大量的時間才能讓“備”變成“活。單純從描述來看多活很強大，能夠保證在災難的情況下業(yè)務(wù)都不受影響，是不是意味著不管什么業(yè)務(wù)，我們都要去實現(xiàn)多活架構(gòu)呢？其實不是，實現(xiàn)多活架構(gòu)都要付出一定的代價，具體表現(xiàn)為：

不同多活方案實現(xiàn)復雜度不一樣，隨著業(yè)務(wù)規(guī)模和容災級別的提升，多活方案會給業(yè)務(wù)系統(tǒng)設(shè)計帶來更大復雜度。

不管采用哪種多活方案都難以完全避免跨機房甚至是跨地區(qū)服務(wù)調(diào)用帶來的耗時增加。

多活會帶來成本會上升，畢竟要多在一個或者多個機房搭建獨立的一套業(yè)務(wù)系統(tǒng)。

因此，多活雖然功能很強大，但也不是每個業(yè)務(wù)都要上多活。例如，企業(yè)內(nèi)部的 IT 系統(tǒng)、管理系統(tǒng)、博客站點等，如果無法承受異地多活帶來的復雜度和成本，是可以不做異地多活的，而對于重要的業(yè)務(wù)例如核心金融、支付、交易等有必要做多活。

2、多活方案

常見的多活方案有同城雙活、兩地三中心、三地五中心、異地多活等多種技術(shù)方案，不同多活方案技術(shù)要求、建設(shè)成本、運維成本都不一樣，下面我們會逐步介紹這幾種多活方案并給出每種方案的優(yōu)點和缺點。選用哪種方案要結(jié)合具體業(yè)務(wù)規(guī)模、當前基礎(chǔ)建設(shè)能力、投入產(chǎn)出比等多種因素來決定。

二、同城雙活

同城雙活是在同城或相近區(qū)域內(nèi)建立兩個機房。同城雙機房距離比較近，通信線路質(zhì)量較好，比較容易實現(xiàn)數(shù)據(jù)的同步復制 ，保證高度的數(shù)據(jù)完整性和數(shù)據(jù)零丟失。同城兩個機房各承擔一部分流量，一般入口流量完全隨機，內(nèi)部RPC調(diào)用盡量通過就近路由閉環(huán)在同機房，相當于兩個機房鏡像部署了兩個獨立集群，數(shù)據(jù)仍然是單點寫到主機房數(shù)據(jù)庫，然后實時同步到另外一個機房。下圖展示了同城雙活簡單部署架構(gòu)，當然一般真實部署和考慮問題要遠遠比下圖復雜。

服務(wù)調(diào)用基本在同機房內(nèi)完成閉環(huán)，數(shù)據(jù)仍然是單點寫到主機房數(shù)據(jù)儲存，然后實時同步復制到同城備份機房。當機房A出現(xiàn)問題時候運維人員只需要通過GSLB或者其他方案手動更改路由方式將流量路由到B機房。同城雙活可有效用于防范火災、建筑物破壞、供電故障、計算機系統(tǒng)及人為破壞引起的機房災難。

1、服務(wù)路由

zk集群：每個機房都部署一個zk集群，機房之間zk數(shù)據(jù)進行實時雙向同步，每個機房都擁有所有機房zk注冊數(shù)據(jù)。

路由方案：條件路由 》 就近路由 》 跨機房路由，盡量避免跨機房調(diào)用。

訂閱方案：consumer訂閱所有機房服務(wù)，provider只向該機房zk集群進行注冊。

2、數(shù)據(jù)雙活

MySQL：采用MHA部署方案，主從半同步方案保證數(shù)據(jù)一致性。讀寫分離、讀就近路由到機房內(nèi)數(shù)據(jù)節(jié)點、寫路由到master節(jié)點所在機房。

Redis： Redis cluster模式主從同步，就近讀、寫路由主節(jié)點機房。采用原生主從同步跨機房寫性能較低，也可以依靠CRDT理論構(gòu)建多節(jié)點雙向同步，實現(xiàn)機房就近讀寫，但是整體實現(xiàn)較為復雜。

3、同城雙活方案評估

優(yōu)勢

服務(wù)同城雙活，數(shù)據(jù)同城災備，同城不丟失數(shù)據(jù)情況下跨機房級別容災。

架構(gòu)方案較為簡單，核心是解決底層數(shù)據(jù)雙活，由于雙機房距離近，通信質(zhì)量好，底層儲存例如mysql可以采用同步復制，有效保證雙機房數(shù)據(jù)一致性。

劣勢

數(shù)據(jù)庫寫數(shù)據(jù)存在跨機房調(diào)用，在復雜業(yè)務(wù)以及鏈路下頻繁跨機房調(diào)用增加響應(yīng)時間，影響系統(tǒng)性能和用戶體驗。

保證同城市地區(qū)容災，當服務(wù)所在的城市或者地區(qū)網(wǎng)絡(luò)整體故障、發(fā)生不可抗拒的自然災害時候有服務(wù)故障以及丟失數(shù)據(jù)風險。對于核心金融業(yè)務(wù)至少要有跨地區(qū)級別的災備能力。

服務(wù)規(guī)模足夠大（例如單體應(yīng)用超過萬臺機器），所有機器鏈接一個主數(shù)據(jù)庫實例會引起連接不足問題。

三、兩地三中心架構(gòu)

所謂兩地三中心是指 同城雙中心 + 異地災備中心。異地災備中心是指在異地的城市建立一個備份的災備中心，用于雙中心的數(shù)據(jù)備份，數(shù)據(jù)和服務(wù)平時都是冷的，當雙中心所在城市或者地區(qū)出現(xiàn)異常而都無法對外提供服務(wù)的時候，異地災備中心可以用備份數(shù)據(jù)進行業(yè)務(wù)的恢復。

兩地三中心方案評估

優(yōu)勢

服務(wù)同城雙活，數(shù)據(jù)同城災備，同城不丟失數(shù)據(jù)情況下跨機房級別容災。

架構(gòu)方案較為簡單，核心是解決底層數(shù)據(jù)雙活，由于雙機房距離近，通信質(zhì)量好，底層儲存例如mysql可以采用同步復制，有效保證雙機房數(shù)據(jù)一致性。

災備中心能防范同城雙中心同時出現(xiàn)故障時候利用備份數(shù)據(jù)進行業(yè)務(wù)的恢復。

劣勢

數(shù)據(jù)庫寫數(shù)據(jù)存在跨機房調(diào)用，在復雜業(yè)務(wù)以及鏈路下頻繁跨機房調(diào)用增加響應(yīng)時間，影響系統(tǒng)性能和用戶體驗。

服務(wù)規(guī)模足夠大（例如單體應(yīng)用超過萬臺機器），所有機器鏈接一個主數(shù)據(jù)庫實例會引起連接不足問題。

出問題不敢輕易將流量切往異地數(shù)據(jù)備份中心，異地的備份數(shù)據(jù)中心是冷的，平時沒有流量進入，因此出問題需要較長時間對異地災備機房進行驗證。

同城雙活和兩地三中心建設(shè)方案建設(shè)復雜度都不高，兩地三中心相比同城雙活有效解決了異地數(shù)據(jù)災備問題，但是依然不能解決同城雙活存在的多處缺點，想要解決這兩種架構(gòu)存在的弊端就要引入更復雜的解決方案去解決這些問題。

四、異地多活

異地多活指分布在異地的多個站點同時對外提供服務(wù)的業(yè)務(wù)場景。異地多活是高可用架構(gòu)設(shè)計的一種，與傳統(tǒng)的災備設(shè)計的最主要區(qū)別在于“多活”，即所有站點都是同時在對外提供服務(wù)的。

1、異地多活挑戰(zhàn)

（1）應(yīng)用要走向異地，首先要面對的便是物理距離帶來的延時。如果某個應(yīng)用請求需要在異地多個單元對同一行記錄進行修改，為滿足異地單元間數(shù)據(jù)庫數(shù)據(jù)的一致性和完整性，需要付出高昂的時間成本。

（2）解決異地高延時即要做到單元內(nèi)數(shù)據(jù)讀寫封閉，不能出現(xiàn)不同單元對同一行數(shù)據(jù)進行修改，所以我們需要找到一個維度去劃分單元。

（3）某個單元內(nèi)訪問其他單元數(shù)據(jù)需要能正確路由到對應(yīng)的單元，例如A用戶給B用戶轉(zhuǎn)賬，A用戶和B用戶數(shù)據(jù)不在一個單元內(nèi)，對B用戶的操作能路由到相應(yīng)的單元。

（4）面臨的數(shù)據(jù)同步挑戰(zhàn)，對于單元封閉的數(shù)據(jù)需全部同步到對應(yīng)單元，對于讀寫分離類型的，我們要把中心的數(shù)據(jù)同步到單元。

2、單元化

所謂單元（下面我們用RZone代替），是指一個能完成所有業(yè)務(wù)操作的自包含集合，在這個集合中包含了所有業(yè)務(wù)所需的所有服務(wù)，以及分配給這個單元的數(shù)據(jù)。

單元化架構(gòu)就是把單元作為系統(tǒng)部署的基本單位，在全站所有機房中部署數(shù)個單元，每個機房里的單元數(shù)目不定，任意一個單元都部署了系統(tǒng)所需的所有的應(yīng)用。單元化架構(gòu)下，服務(wù)仍然是分層的，不同的是每一層中的任意一個節(jié)點都屬于且僅屬于某一個單元，上層調(diào)用下層時，僅會選擇本單元內(nèi)的節(jié)點。

選擇什么維度來進行流量切分，要從業(yè)務(wù)本身入手去分析。例如電商業(yè)務(wù)和金融的業(yè)務(wù)，最重要的流程即下單、支付、交易流程，通過對用戶id進行數(shù)據(jù)切分拆分是最好的選擇，買家的相關(guān)操作都會在買家所在的本單元內(nèi)完成。對于商家相關(guān)操作則無法進行單元化，需要按照下面介紹的非單元化模式去部署。當然用戶操作業(yè)務(wù)并非完全能避免跨單元甚至是跨機房調(diào)用，例如兩個買家A和B轉(zhuǎn)賬業(yè)務(wù)，A和B所屬數(shù)據(jù)單元不一致的時候，對B進行操作就需要跨單元去完成，后面我們會介紹跨單元調(diào)用服務(wù)路由問題。

3、非單元化應(yīng)用和數(shù)據(jù)

對于無法單元化的業(yè)務(wù)和應(yīng)用，會存在下面兩種可能性：

（1）延時不銘感但是對數(shù)據(jù)一致性非常銘感，這類應(yīng)用只能按照同城雙活方式部署。其他應(yīng)用調(diào)用該類應(yīng)用的時候會存在跨地區(qū)調(diào)用可能性，要能容忍延時，這類應(yīng)用我們稱為MZone應(yīng)用。

（2）對數(shù)據(jù)調(diào)用延時銘感但是可以容忍數(shù)據(jù)短時間不一致，這類應(yīng)用和數(shù)據(jù)可以保持一個機房一份全量數(shù)據(jù)，機房之間以增量的方式實時同步，這類應(yīng)用我們暫時稱為QZone。

加上兩種以上非單元化應(yīng)用我們的機房部署可能是下面這樣，每個機房有兩個RZone，MZone保持類似兩地三中心部署方式，異地機房調(diào)用MZone服務(wù)需要跨地區(qū)、跨機房調(diào)用。而QZone每個機房都保持一份完整數(shù)據(jù)，機房之間通過數(shù)據(jù)鏈路實時相互同步。

4、請求路由

（1）Api入口網(wǎng)關(guān)

為了保證用戶請求能正確進入自己所屬單元，每一個機房都會部署流量入口網(wǎng)關(guān)集群。當用戶請求到達進入機房內(nèi)最先進入到流量網(wǎng)關(guān)，流量網(wǎng)關(guān)能感知全局的流量分片情況，計算用戶所處流量單元并將流量轉(zhuǎn)發(fā)到對應(yīng)的單元，這樣就可以將用戶請求路由到對應(yīng)的單元內(nèi)。

采用GateWayr轉(zhuǎn)發(fā)方式可以確定用戶單元從而將用戶流量路由到正確位置，但是HTTP轉(zhuǎn)發(fā)也會造成一定性能損耗。為了減少HTTP流量轉(zhuǎn)發(fā)量，可以在在用戶請求返回的時候在cookie上帶上該用戶的路由標識信息。當用戶下次在請求的時候請求的時候可以提前獲取到路由標識直接請求到對應(yīng)的單元，這種方式可以大幅度減少HTTP流量轉(zhuǎn)發(fā)。

（2）服務(wù)路由

雖然應(yīng)用已經(jīng)進行了單元化，但是依然無法避免跨單元調(diào)用，例如A用戶給B用戶轉(zhuǎn)賬，如果A和B所處單元不同，對B用戶操作需要跨單元去調(diào)用，這個時候需要能將請求路由到B用戶數(shù)據(jù)所在的單元。異地多活情況下RPC、MQ、DB等等中間件都需要提供路由能力，將請求能正確路由到對應(yīng)的單元。下面以RPC路由為例說明異地多活下中間件是如何進行路由的，對于其他中間件（數(shù)據(jù)庫中間件、緩存中間、消息中間件等）也是一樣方法。

public interface ManualInterventionFacade {

@ZoneRoute（zoneType= ZoneType.RZone，uidClass = UidParseClass.class）

ManualRecommendResponse getManualRecommendCommodity（ManualRecommendRequest request）;

}

上面展示了多活下的RPC接口定義方法，需要注明該RPC類型，如果是RZone服務(wù)必須要提供解析uid方法。下圖展示了RPC注冊中心路由尋址過程，和同城雙活有一定的差異性。

5、數(shù)據(jù)同步

（1）QZone類型數(shù)據(jù)：這種數(shù)據(jù)只需要保證最終一致性，對于短暫不一致無影響，但是對延時非常銘感，例如一些算法、風控、配置等數(shù)據(jù)。這類數(shù)據(jù)基本上都是每個機房部署一套QZone，然后機房之間相互同步。

（2）MZone數(shù)據(jù)：這類數(shù)據(jù)對一致性非常銘感，不能出現(xiàn)不一致，只能采用同城雙活部署方式，業(yè)務(wù)需要能容忍異地調(diào)用延時。

（3）RZone數(shù)據(jù)：這類數(shù)據(jù)每個Zone都有自己的主節(jié)點，如果數(shù)據(jù)不在該單元內(nèi)需要路由到對應(yīng)的節(jié)點去寫。這類數(shù)據(jù)部署情況像下面這樣

6、方案評估

優(yōu)勢

容災能力大幅度提高，服務(wù)異地多活，數(shù)據(jù)異地多活。

理論上系統(tǒng)服務(wù)可以水平擴展，異地多機房突破大幅度提升整體容量，理論上不會有性能擔憂。

將用戶流量切分到多個機房和地區(qū)去，有效能減少機房和地區(qū)級別的故障影響范圍。

劣勢

架構(gòu)非常復雜，部署和運維成本很高，需要對公司依賴的中間件、儲存做多方面能力改造。

對業(yè)務(wù)系統(tǒng)有一定的侵入性，由于單元化影響服務(wù)調(diào)用或者寫入數(shù)據(jù)要路由到對應(yīng)的單元，業(yè)務(wù)系統(tǒng)需要設(shè)置路由標識（例如uid）。

無法完全避免跨單元、跨地區(qū)調(diào)用服務(wù)，例如上面的轉(zhuǎn)賬業(yè)務(wù)。我們要做的是盡力避免跨地區(qū)的服務(wù)調(diào)用。

五、總結(jié)

本文討論了一些多活建設(shè)的大體思路以及一些關(guān)鍵技術(shù)點的解決方案，各種不同方案對比。要建立起完整的異地多活能力遠遠比上面討論的要復雜的多，需要對依賴的各種中間件、儲存等做相應(yīng)的單元化改造并配套完整的流量調(diào)度和運維管控能力 。

由于篇幅限制本文并未詳細介紹各種儲存（例如Redis、MySQL）在多活下數(shù)據(jù)同步復制以及高可用方案，有興趣的同學可以去深入了解這方面知識。
編輯：hfy