采用高可用系統(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)。

一、為什么要做多活

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

1、多活場(chǎng)景

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

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

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

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

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

2、多活方案

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

二、同城雙活

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

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

1、服務(wù)路由

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

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

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

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

MySQL：采用MHA部署方案，主從半同步方案保證數(shù)據(jù)一致性。讀寫分離、讀就近路由到機(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、同城雙活方案評(píng)估

優(yōu)勢(shì)

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

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

劣勢(shì)

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

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

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

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

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

兩地三中心方案評(píng)估

優(yōu)勢(shì)

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

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

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

劣勢(shì)

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

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

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

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

四、異地多活

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

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

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

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

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

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

2、單元化

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

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

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

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

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

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

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

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

4、請(qǐng)求路由

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

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

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

（2）服務(wù)路由

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

public interface ManualInterventionFacade {

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

ManualRecommendResponse getManualRecommendCommodity（ManualRecommendRequest request）;

}

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

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

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

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

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

6、方案評(píng)估

優(yōu)勢(shì)

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

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

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

劣勢(shì)

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

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

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

五、總結(jié)

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

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