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

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

一、為什么要做多活

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

1、多活場景

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

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

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

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

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

2、多活方案

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

二、同城雙活

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

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

1、服務(wù)路由

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

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

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

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

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

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

3、同城雙活方案評估

優(yōu)勢

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

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

劣勢

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

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

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

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

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

兩地三中心方案評估

優(yōu)勢

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

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

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

劣勢

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

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

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

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

四、異地多活

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

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

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

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

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

選擇什么維度來進(jìn)行流量切分，要從業(yè)務(wù)本身入手去分析。例如電商業(yè)務(wù)和金融的業(yè)務(wù)，最重要的流程即下單、支付、交易流程，通過對用戶id進(jìn)行數(shù)據(jù)切分拆分是最好的選擇，買家的相關(guān)操作都會在買家所在的本單元內(nèi)完成。對于商家相關(guān)操作則無法進(jìn)行單元化，需要按照下面介紹的非單元化模式去部署。當(dāng)然用戶操作業(yè)務(wù)并非完全能避免跨單元甚至是跨機(jī)房調(diào)用，例如兩個買家A和B轉(zhuǎn)賬業(yè)務(wù)，A和B所屬數(shù)據(jù)單元不一致的時候，對B進(jìn)行操作就需要跨單元去完成，后面我們會介紹跨單元調(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ù)可以保持一個機(jī)房一份全量數(shù)據(jù)，機(jī)房之間以增量的方式實(shí)時同步，這類應(yīng)用我們暫時稱為QZone。

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

4、請求路由

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

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

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

（2）服務(wù)路由

雖然應(yīng)用已經(jīng)進(jìn)行了單元化，但是依然無法避免跨單元調(diào)用，例如A用戶給B用戶轉(zhuǎn)賬，如果A和B所處單元不同，對B用戶操作需要跨單元去調(diào)用，這個時候需要能將請求路由到B用戶數(shù)據(jù)所在的單元。異地多活情況下RPC、MQ、DB等等中間件都需要提供路由能力，將請求能正確路由到對應(yīng)的單元。下面以RPC路由為例說明異地多活下中間件是如何進(jìn)行路由的，對于其他中間件（數(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ù)只需要保證最終一致性，對于短暫不一致無影響，但是對延時非常銘感，例如一些算法、風(fēng)控、配置等數(shù)據(jù)。這類數(shù)據(jù)基本上都是每個機(jī)房部署一套QZone，然后機(jī)房之間相互同步。

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

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

6、方案評估

優(yōu)勢

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

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

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

劣勢

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

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

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

五、總結(jié)

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

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