采用高可用系統(tǒng)架構(gòu)支持重要系統(tǒng)，為關(guān)鍵業(yè)務(wù)提供7x24的不間斷服務(wù)，已經(jīng)成為眾多企業(yè)保障業(yè)務(wù)穩(wěn)定、持續(xù)運(yùn)轉(zhuǎn)的主要選擇。

站在用戶(hù)的角度思考問(wèn)題，與客戶(hù)深入溝通，找到鐘樓網(wǎng)站設(shè)計(jì)與鐘樓網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗(yàn)，讓設(shè)計(jì)與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個(gè)性化、用戶(hù)體驗(yàn)好的作品，建站類(lèi)型包括：做網(wǎng)站、成都做網(wǎng)站、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣、域名申請(qǐng)、網(wǎng)頁(yè)空間、企業(yè)郵箱。業(yè)務(wù)覆蓋鐘樓地區(qū)。

服務(wù)多活是高可用架構(gòu)重要實(shí)施手段，本文介紹了一些業(yè)界常用的多活手段，例如同城雙活、兩地三中心、異地多活架構(gòu)設(shè)計(jì)方案并詳述了各種方案的優(yōu)缺點(diǎn)。

一、為什么要做多活

隨著移動(dòng)互聯(lián)網(wǎng)的深入發(fā)展，用戶(hù)增長(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)。

為了滿(mǎn)足中心業(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í)間才能讓“備”變成“活。

單純從描述來(lái)看多活很強(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ì)帶來(lái)更大復(fù)雜度；
•  不管采用哪種多活方案都難以完全避免跨機(jī)房甚至是跨地區(qū)服務(wù)調(diào)用帶來(lái)的耗時(shí)增加；
•  多活會(huì)帶來(lái)成本會(huì)上升，畢竟要多在一個(gè)或者多個(gè)機(jī)房搭建獨(dú)立的一套業(yè)務(wù)系統(tǒng)。

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

2、多活方案

常見(jiàn)的多活方案有同城雙活、兩地三中心、三地五中心、異地多活等多種技術(shù)方案，不同多活方案技術(shù)要求、建設(shè)成本、運(yùn)維成本都不一樣。

下面我們會(huì)逐步介紹這幾種多活方案并給出每種方案的優(yōu)點(diǎn)和缺點(diǎn)。選用哪種方案要結(jié)合具體業(yè)務(wù)規(guī)模、當(dāng)前基礎(chǔ)建設(shè)能力、投入產(chǎn)出比等多種因素來(lái)決定。

二、同城雙活

同城雙活是在同城或相近區(qū)域內(nèi)建立兩個(gè)機(jī)房。同城雙機(jī)房距離比較近，通信線(xiàn)路質(zhì)量較好，比較容易實(shí)現(xiàn)數(shù)據(jù)的同步復(fù)制 ，保證高度的數(shù)據(jù)完整性和數(shù)據(jù)零丟失。

同城兩個(gè)機(jī)房各承擔(dān)一部分流量，一般入口流量完全隨機(jī)，內(nèi)部RPC調(diào)用盡量通過(guò)就近路由閉環(huán)在同機(jī)房，相當(dāng)于兩個(gè)機(jī)房鏡像部署了兩個(gè)獨(dú)立集群，數(shù)據(jù)仍然是單點(diǎn)寫(xiě)到主機(jī)房數(shù)據(jù)庫(kù)，然后實(shí)時(shí)同步到另外一個(gè)機(jī)房。

下圖展示了同城雙活簡(jiǎn)單部署架構(gòu)，當(dāng)然一般真實(shí)部署和考慮問(wèn)題要遠(yuǎn)遠(yuǎn)比下圖復(fù)雜：

服務(wù)調(diào)用基本在同機(jī)房?jī)?nèi)完成閉環(huán)，數(shù)據(jù)仍然是單點(diǎn)寫(xiě)到主機(jī)房數(shù)據(jù)儲(chǔ)存，然后實(shí)時(shí)同步復(fù)制到同城備份機(jī)房。當(dāng)機(jī)房A出現(xiàn)問(wèn)題時(shí)候運(yùn)維人員只需要通過(guò)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ù)一致性。讀寫(xiě)分離、讀就近路由到機(jī)房?jī)?nèi)數(shù)據(jù)節(jié)點(diǎn)、寫(xiě)路由到master節(jié)點(diǎn)所在機(jī)房；
•  Redis：Redis cluster模式主從同步，就近讀、寫(xiě)路由主節(jié)點(diǎn)機(jī)房。采用原生主從同步跨機(jī)房寫(xiě)性能較低，也可以依靠CRDT理論構(gòu)建多節(jié)點(diǎn)雙向同步，實(shí)現(xiàn)機(jī)房就近讀寫(xiě)，但是整體實(shí)現(xiàn)較為復(fù)雜。

3、同城雙城方案評(píng)估

1）優(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ù)一致性。

2）劣勢(shì)

•  數(shù)據(jù)庫(kù)寫(xiě)數(shù)據(jù)存在跨機(jī)房調(diào)用，在復(fù)雜業(yè)務(wù)以及鏈路下頻繁跨機(jī)房調(diào)用增加響應(yīng)時(shí)間，影響系統(tǒng)性能和用戶(hù)體驗(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)用超過(guò)萬(wàn)臺(tái)機(jī)器)，所有機(jī)器鏈接一個(gè)主數(shù)據(jù)庫(kù)實(shí)例會(huì)引起連接不足問(wèn)題。

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

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

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

1）優(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ù)。

2）劣勢(shì)

•  數(shù)據(jù)庫(kù)寫(xiě)數(shù)據(jù)存在跨機(jī)房調(diào)用，在復(fù)雜業(yè)務(wù)以及鏈路下頻繁跨機(jī)房調(diào)用增加響應(yīng)時(shí)間，影響系統(tǒng)性能和用戶(hù)體驗(yàn)；
•  服務(wù)規(guī)模足夠大(例如單體應(yīng)用超過(guò)萬(wàn)臺(tái)機(jī)器)，所有機(jī)器鏈接一個(gè)主數(shù)據(jù)庫(kù)實(shí)例會(huì)引起連接不足問(wèn)題；
•  出問(wèn)題不敢輕易將流量切往異地?cái)?shù)據(jù)備份中心，異地的備份數(shù)據(jù)中心是冷的，平時(shí)沒(méi)有流量進(jìn)入，因此出問(wèn)題需要較長(zhǎng)時(shí)間對(duì)異地災(zāi)備機(jī)房進(jìn)行驗(yàn)證。

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

四、異地多活

異地多活指分布在異地的多個(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)

•  應(yīng)用要走向異地，首先要面對(duì)的便是物理距離帶來(lái)的延時(shí)。如果某個(gè)應(yīng)用請(qǐng)求需要在異地多個(gè)單元對(duì)同一行記錄進(jìn)行修改，為滿(mǎn)足異地單元間數(shù)據(jù)庫(kù)數(shù)據(jù)的一致性和完整性，需要付出高昂的時(shí)間成本；
•  解決異地高延時(shí)即要做到單元內(nèi)數(shù)據(jù)讀寫(xiě)封閉，不能出現(xiàn)不同單元對(duì)同一行數(shù)據(jù)進(jìn)行修改，所以我們需要找到一個(gè)維度去劃分單元；
•  某個(gè)單元內(nèi)訪(fǎng)問(wèn)其他單元數(shù)據(jù)需要能正確路由到對(duì)應(yīng)的單元，例如A用戶(hù)給B用戶(hù)轉(zhuǎn)賬，A用戶(hù)和B用戶(hù)數(shù)據(jù)不在一個(gè)單元內(nèi)，對(duì)B用戶(hù)的操作能路由到相應(yīng)的單元；
•  面臨的數(shù)據(jù)同步挑戰(zhàn)，對(duì)于單元封閉的數(shù)據(jù)需全部同步到對(duì)應(yīng)單元，對(duì)于讀寫(xiě)分離類(lèi)型的，我們要把中心的數(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)。

選擇什么維度來(lái)進(jìn)行流量切分，要從業(yè)務(wù)本身入手去分析。

例如電商業(yè)務(wù)和金融的業(yè)務(wù)，最重要的流程即下單、支付、交易流程，通過(guò)對(duì)用戶(hù)id進(jìn)行數(shù)據(jù)切分拆分是最好的選擇，買(mǎi)家的相關(guān)操作都會(huì)在買(mǎi)家所在的本單元內(nèi)完成。

對(duì)于商家相關(guān)操作則無(wú)法進(jìn)行單元化，需要按照下面介紹的非單元化模式去部署。當(dāng)然用戶(hù)操作業(yè)務(wù)并非完全能避免跨單元甚至是跨機(jī)房調(diào)用，例如兩個(gè)買(mǎi)家A和B轉(zhuǎn)賬業(yè)務(wù)，A和B所屬數(shù)據(jù)單元不一致的時(shí)候，對(duì)B進(jìn)行操作就需要跨單元去完成，后面我們會(huì)介紹跨單元調(diào)用服務(wù)路由問(wèn)題。

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

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

•  延時(shí)不敏感但是對(duì)數(shù)據(jù)一致性非常敏感，這類(lèi)應(yīng)用只能按照同城雙活方式部署。其他應(yīng)用調(diào)用該類(lèi)應(yīng)用的時(shí)候會(huì)存在跨地區(qū)調(diào)用可能性，要能容忍延時(shí)，這類(lèi)應(yīng)用我們稱(chēng)為MZone應(yīng)用；
•  對(duì)數(shù)據(jù)調(diào)用延時(shí)敏感但是可以容忍數(shù)據(jù)短時(shí)間不一致，這類(lèi)應(yīng)用和數(shù)據(jù)可以保持一個(gè)機(jī)房一份全量數(shù)據(jù)，機(jī)房之間以增量的方式實(shí)時(shí)同步，這類(lèi)應(yīng)用我們暫時(shí)稱(chēng)為QZone。

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

4、請(qǐng)求路由

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

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

采用GateWayr轉(zhuǎn)發(fā)方式可以確定用戶(hù)單元從而將用戶(hù)流量路由到正確位置，但是HTTP轉(zhuǎn)發(fā)也會(huì)造成一定性能損耗。

為了減少HTTP流量轉(zhuǎn)發(fā)量，可以在在用戶(hù)請(qǐng)求返回的時(shí)候在cookie上帶上該用戶(hù)的路由標(biāo)識(shí)信息。當(dāng)用戶(hù)下次在請(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)行了單元化，但是依然無(wú)法避免跨單元調(diào)用，例如A用戶(hù)給B用戶(hù)轉(zhuǎn)賬，如果A和B所處單元不同，對(duì)B用戶(hù)操作需要跨單元去調(diào)用，這個(gè)時(shí)候需要能將請(qǐng)求路由到B用戶(hù)數(shù)據(jù)所在的單元。異地多活情況下RPC、MQ、DB等等中間件都需要提供路由能力，將請(qǐng)求能正確路由到對(duì)應(yīng)的單元。下面以RPC路由為例說(shuō)明異地多活下中間件是如何進(jìn)行路由的，對(duì)于其他中間件(數(shù)據(jù)庫(kù)中間件、緩存中間、消息中間件等）也是一樣方法。

 
 
 
 

  
  
  
  
public interface ManualInterventionFacade {  
  
  
  
  
    @ZoneRoute(zoneType= ZoneType.RZone,uidClass = UidParseClass.class)  
  
  
  
  
    ManualRecommendResponse getManualRecommendCommodity(ManualRecommendRequest request);  
  
  
  
  
} 
 
 
 
 

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

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

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

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

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

6、方案評(píng)估

1）優(yōu)勢(shì)

•  容災(zāi)能力大幅度提高，服務(wù)異地多活，數(shù)據(jù)異地多活；
•  理論上系統(tǒng)服務(wù)可以水平擴(kuò)展，異地多機(jī)房突破大幅度提升整體容量，理論上不會(huì)有性能擔(dān)憂(yōu)；
•  將用戶(hù)流量切分到多個(gè)機(jī)房和地區(qū)去，有效能減少機(jī)房和地區(qū)級(jí)別的故障影響范圍。

2）劣勢(shì)

•  架構(gòu)非常復(fù)雜，部署和運(yùn)維成本很高，需要對(duì)公司依賴(lài)的中間件、儲(chǔ)存做多方面能力改造；
•  對(duì)業(yè)務(wù)系統(tǒng)有一定的侵入性，由于單元化影響服務(wù)調(diào)用或者寫(xiě)入數(shù)據(jù)要路由到對(duì)應(yīng)的單元，業(yè)務(wù)系統(tǒng)需要設(shè)置路由標(biāo)識(shí)(例如uid)；
•  無(wú)法完全避免跨單元、跨地區(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ì)依賴(lài)的各種中間件、儲(chǔ)存等做相應(yīng)的單元化改造并配套完整的流量調(diào)度和運(yùn)維管控能力。

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

本文標(biāo)題：高可用架構(gòu)怎么選？常見(jiàn)多活建設(shè)這么一對(duì)比就懂了
文章路徑：http://uogjgqi.cn/article/djshedg.html