互聯(lián)網(wǎng)常見的高可用手段。比如服務(wù)冗余部署、異步化設(shè)計、負(fù)載均衡、服務(wù)限流降級熔斷、架構(gòu)拆分、服務(wù)治理、分布式存儲等等，今天主要是一起聊下，多機房部署的災(zāi)備架構(gòu)模式，來確保服務(wù)的高可用。

常見的架構(gòu)模式

災(zāi)備架構(gòu)比較常見的幾種模式，基本分為同城多中心、跨城多中心、跨國多中心。從字面上看，這幾個架構(gòu)模式好像差不多的，只是距離上的差異，其他的感覺都差不多的。但，就是簡單的距離上的差異，就會導(dǎo)致在架構(gòu)上關(guān)鍵的應(yīng)用場景以及技術(shù)本質(zhì)上有較大的區(qū)別。

1. 同城多中心架構(gòu)

同城多中心最典型的就是雙中心跟三中心。

同城雙中心

簡單來說就是在同一個城市部署兩個機房。如下圖中，IDC-1和IDC-2。兩個機房之間通過高速光纖進行連接。它的一些關(guān)鍵特征是：

（1）相同城市，距離在50km以上。為什么需要在50km以上呢？如果從機房的建設(shè)上講，沒有什么不可以，相距5km也可以建設(shè)。但我們做雙機房，是為了高可用災(zāi)備或者備份。一個簡單的例子，如果距離過近，很可能是屬于一個片區(qū)。如果遇到停電，很可能是一個片區(qū)的停電。這樣兩個機房都不可用了。

（2）光纖互聯(lián)

（3）機房網(wǎng)絡(luò)延遲<2ms?

同城雙中心的架構(gòu)本質(zhì)是同城雙中心可以當(dāng)做一個邏輯機房。也就是將同一個集群上的節(jié)點，部署在兩個物理機房。這樣可以應(yīng)對機房級別的災(zāi)難。如下圖所示

要注意，同一個集群，部署在兩個數(shù)據(jù)中心，一般要用多條光纖線路，不然容易出現(xiàn)腦裂。此外還有些特別情況，如下圖，可以發(fā)現(xiàn)，如果IDC-2掛了，IDC-1能正常服務(wù)。但如果IDC-1整個掛了，DIC-2的Redis集群是不可用的。這是因為sentinel節(jié)點不能完成選舉，這里要從架構(gòu)上進行考慮設(shè)計。當(dāng)然也有個辦法，就是在idc-3部署一個節(jié)點，只部署sentinel集群，來避免這個問題。在IDC-3不需要搭建完整機房,只需要部署部分決策選舉相關(guān)的服務(wù)，有一定成本，但整體成本還是比較低的。

同城三中心

相比同城雙中心，三中心就是在同一個城市部署三個機房，相互之間通過高速光纖連接。三中心，每個中心的定位跟職責(zé)都是一樣的，比如業(yè)務(wù)要部署的話，三個都會部署。事實上，很少有公司采用這種架構(gòu)。主要的原因是這種同城三中心的成本是比較高的，但是高可用并沒有提高多少，如果發(fā)生城市級別的災(zāi)難，比如地震、臺風(fēng)等，這三個機房都會受到影響。所以說，想做三機房，一般都是一個同城雙中心，然后另外一個機房部署到其他城市。

下圖只是示意圖，實際的架構(gòu)要復(fù)雜得多。

2.跨城多中心架構(gòu)

跨城多中心也分為跨城雙中心和跨城三中心或者四中心等。看下圖跨城雙中心的架構(gòu)跟同城雙中心的架構(gòu)是類似的，區(qū)別就是機房所在城市不一樣。跨城雙中心的一些關(guān)鍵特征是：不同城市、光纖互聯(lián)。

跨城雙中心主要的應(yīng)用場景是 :

進行城市級別的災(zāi)備

用戶分區(qū)，比如兩個城市部署在比較遠(yuǎn)的地方，城市A在北京，城市B在深圳，那可以南方用戶接入深圳機房，北方用戶接入到北京機房；

異地多活

并不是所有的跨城多中心架構(gòu)都能滿足 這幾個應(yīng)用場景，不同的跨城雙中心架構(gòu)有不同的應(yīng)用的場景。從城市的距離上，分為近鄰城市和遠(yuǎn)端城市場景。

跨城雙中心-近鄰城市

這個架構(gòu)的關(guān)鍵點就是選擇兩個相近的城市，比如上海杭州、北京天津、廣東深圳這種。機房的延時要<10ms，可以當(dāng)做同一邏輯機房使用。?

應(yīng)用場景：

避免城市級別的災(zāi)難，但是無法避免區(qū)域性災(zāi)難

做異地多活，但不能做用戶分區(qū)。距離比較近，用戶分區(qū)訪問沒有意義

跨城雙中心-遠(yuǎn)端城市

遠(yuǎn)端城市架構(gòu)模式的關(guān)鍵特征是選擇兩個遠(yuǎn)距離的城市；機房延時>30ms，不能當(dāng)作同一邏輯機房；

應(yīng)用場景

避免城市級別和區(qū)域性級別的災(zāi)難

適應(yīng)異地多活架構(gòu)

可以做分區(qū)架構(gòu)

跨城多中心

跨城多中心的一般應(yīng)用場景，就是用戶分區(qū)、就近接入、異地多活。

可以結(jié)合OceanBase 官方推薦架構(gòu)來理解。如下圖，采用兩近（延遲10ms）一遠(yuǎn)（延遲30~50ms）的部署模式，可以應(yīng)對城市級別故障，可靠性是最高的；不過成本也是最高的。為什么要2近1遠(yuǎn)？其實這跟oceanBase本身的技術(shù)實現(xiàn)有關(guān)系，底層為了保證一致性，是通過proxy協(xié)議不斷的進行通信、投票來保障的，必須要保證服務(wù)之間通信的性能。一遠(yuǎn)是為了保證應(yīng)對城市級別的故障。

3.跨國數(shù)據(jù)中心架構(gòu)

跨國數(shù)據(jù)中心

跨國數(shù)據(jù)中心的基本特點：

（1）全球部署

（2）合規(guī)和監(jiān)管，不同的地區(qū)的數(shù)據(jù)法規(guī)不一樣，比如用戶的隱私信息之類的

（3）區(qū)域用戶分區(qū)

（4）不能做異地多活。一個原因是時間延遲問題，另外還是在于合規(guī)跟監(jiān)管，不同地區(qū)的合規(guī)跟監(jiān)管數(shù)據(jù)隱私保護的不一樣，沒辦法做異地多活。

可以看下Google和Facebook的跨國數(shù)據(jù)中心，上面的圖是Google的下圖是Facebook的

跨國數(shù)據(jù)中心。主要部署在北美、歐洲、亞洲區(qū)。

4.五種架構(gòu)對比

主要從應(yīng)用場景維度看下幾種架構(gòu)的區(qū)別

像常見的冷備、雙機熱備、同城雙活、異地雙活、異地多活基本都是集合自己的業(yè)務(wù)場景及發(fā)展階段對以上幾種架構(gòu)模式的應(yīng)用。我們下面主要說下異地多活的集中模式。

異地多活的三種模式

異地多活的落地可以概括為有三種大的模式，業(yè)務(wù)定制型異地多活、業(yè)務(wù)通用型異地多活、業(yè)務(wù)存儲型異地多活。

1.業(yè)務(wù)定制型異地多活

簡單來說，業(yè)務(wù)定制型異地多活，就是按照業(yè)務(wù)的優(yōu)先級進行排序，優(yōu)先保證核心業(yè)務(wù)異地多活。然后基于核心業(yè)務(wù)的流程和數(shù)據(jù)，設(shè)計定制化的異地多活架構(gòu)。但是A業(yè)務(wù)做的方案，并不能直接用到B業(yè)務(wù)上。比如說電商業(yè)務(wù)做的雙活，不能用到社交的業(yè)務(wù)上，架構(gòu)的方案并不通用。

如下圖中的示意圖：

A業(yè)務(wù)通過數(shù)據(jù)庫+消息隊列同步的方式實現(xiàn)，

B業(yè)務(wù)通過數(shù)據(jù)庫+算法的方式實現(xiàn)異地多活。

兩種業(yè)務(wù)的實現(xiàn)方式是根據(jù)自身的業(yè)務(wù)場景來決定的。

這種模式的優(yōu)點就是：對基礎(chǔ)設(shè)施沒有強要求，例如機房部署、存儲系統(tǒng)、時延等，一般是部署在遠(yuǎn)距離的兩個城市，可以支持區(qū)域級別故障處理。
缺點也比較明顯，不通用，每個業(yè)務(wù)都需要單獨來做異地多活，業(yè)務(wù)需要改造。難擴展，核心業(yè)務(wù)如果有重大變化，異地多活方案需要重新設(shè)計。

2.業(yè)務(wù)通用型異地多活

這種方式一般是通過配套服務(wù)來支持異地多活。相對于業(yè)務(wù)定制型架構(gòu)，一般無需按照優(yōu)先級排序來挑選某些業(yè)務(wù)實現(xiàn)異地多活，只需要判斷業(yè)務(wù)是否能異地多活，當(dāng)然，業(yè)務(wù)實際落地的時候可能會有階段或者灰度過程，并不是一步到位。這種架構(gòu)的優(yōu)缺點：

優(yōu)點

a. 對硬件基礎(chǔ)設(shè)施沒有強要求，例如機房部署、存儲系統(tǒng)、時延等，一般部署在遠(yuǎn)距離的兩個城市，可以支持區(qū)域級別的故障處理。

b. 業(yè)務(wù)基本不做改造或做較小的改造，只需要判斷業(yè)務(wù)是否支持BASE,支持就可以做異地多活，不支持就單點部署。這個也是要依賴業(yè)務(wù)系統(tǒng)前期的設(shè)計。

缺點

a. 配套服務(wù)復(fù)雜，包括流量調(diào)度、容災(zāi)切換、建站平臺、配置管理等

b. 存在全局單點業(yè)務(wù)。例如庫存、賣家等相關(guān)業(yè)務(wù)

機房距離較遠(yuǎn)的時候，RTO比較大，可能達(dá)到分鐘級。異地多活基礎(chǔ)理論是Base，一定時間內(nèi)達(dá)到最終一致，這個時間范圍可能會較長，有可能會達(dá)到分鐘級。

示意圖

「案例 」淘寶的單元化架構(gòu)

把業(yè)務(wù)分成很多個單元，每個業(yè)務(wù)絕大部分請求都可以在本單元內(nèi)完成。不同的用戶劃分到不同的單元。除了單元還有個中心點。比如庫存信息，全量的商品及賣家數(shù)據(jù)。再把數(shù)據(jù)復(fù)制到各個單元去。

示意圖

【單元】單元（即單元化應(yīng)用服務(wù)產(chǎn)品層的部署單元），是指一個能完成所有業(yè)務(wù)操作的自包含集合，在這個集合中包含了所有業(yè)務(wù)所需的所有服務(wù)，以及分配給這個單元的數(shù)據(jù)。單元化架構(gòu)就是將單元作為部署的基本單位，在全站所有機房中部署多個單元，每個機房內(nèi)單元數(shù)目不固定，任一單元均部署系統(tǒng)所需的全部應(yīng)用，數(shù)據(jù)則是全量數(shù)據(jù)按照某種維度劃分后的一部分。

3. 存儲通用型異地多活

基于業(yè)務(wù)通用性架構(gòu)去做，有的業(yè)務(wù)不能滿足base理論，就不能實現(xiàn)異地多活。那有沒有一種方法，與業(yè)務(wù)不強相關(guān)，實現(xiàn)多活的架構(gòu)設(shè)計呢？答案肯定是有的，從存儲系統(tǒng)來實現(xiàn)，采用本身已經(jīng)支持一致性的存儲系統(tǒng)，實現(xiàn)存儲通用型異地多活。

存儲通用型異地多活架構(gòu)方案的優(yōu)點就是天然支持異地多活，業(yè)務(wù)除了切換存儲系統(tǒng)外，其他基本不做改造。也不需要分析自己的業(yè)務(wù)場景、優(yōu)先級。

缺點就是

（1）需要分布式一致性的存儲系統(tǒng)支持。目前這樣的存儲系統(tǒng)可選不多，例如zookeeper、etcd、OceanBase。實際上zookeeper、etcd不適合存儲大量數(shù)據(jù)的。

（2）對機房部署有強要求，如果實現(xiàn)異地多活，只能采用近鄰部署。分布式一致性框架，是需要通過協(xié)議通信的，這個對性能跟速度要求是有要求的，如果是分布式存儲系統(tǒng)之間的節(jié)點，通信性能很差的話，那么會導(dǎo)致這個系統(tǒng)的讀寫性能會很差，就滿足不了業(yè)務(wù)需求了。

「案例」螞蟻的OceanBase

目前為止，OceanBase是比較典型的一個分布式存儲，而且是真正落地的一個分布式一致性存儲系統(tǒng)。簡單理解OceanBase就是一個基于Paxos算法來實現(xiàn)的分布式一致性存儲系統(tǒng)。【參考官方介紹】

如上圖，簡單理解：

（1） Zone 是一個機房內(nèi)的一組服務(wù)器，包含多臺 OceanBase 數(shù)據(jù)庫服務(wù)器(OBServer)， 一般會把數(shù)據(jù)的多個副本分布在不同的 Zone 上，可以實現(xiàn)單個 Zone 故障不影響數(shù)據(jù)庫 服務(wù)。

（2）每臺 OBServer 包含 SQL 引擎、事務(wù)引擎和存儲引擎，并服務(wù)多個數(shù)據(jù)分區(qū)，其中，每 個 Zone 有一臺 OBServer 會同時使能總控服務(wù)(RootService)，用于執(zhí)行集群管理、服 務(wù)器管理、自動負(fù)載均衡等操作。

（3）OBServer 上會運行 SQL 引擎、事務(wù)引擎和存儲引擎，用戶的 SQL 查詢經(jīng)過 SQL 引擎 解析優(yōu)化后轉(zhuǎn)化為事務(wù)引擎和存儲引擎的內(nèi)部調(diào)用。

（4）OceanBase 數(shù)據(jù)庫還會執(zhí)行強一致的分布式事務(wù)，從而在分布式集群上實現(xiàn)數(shù)據(jù)庫事務(wù) ACID。(參考鏈接 //zhuanlan.zhihu.com/p/41139701）

參考下圖理解，部署上一般要求2近1遠(yuǎn)，距離相近的兩個城市，每個城市的機房都要部署2個Zone，較遠(yuǎn)的城市部署一個Zone.

「案例」螞蟻的LDC架構(gòu)

結(jié)合淘寶單元化的架構(gòu)+OceanBase

示意圖

如上圖，簡單理解：

RZone(Region Zone):部署按用戶維度拆分 的關(guān)鍵業(yè)務(wù)系統(tǒng)。核心業(yè)務(wù)和數(shù)據(jù)單元化拆分，每個單元內(nèi)盡量調(diào)用閉環(huán)， 擁有自己的數(shù)據(jù)，能完成所有業(yè)務(wù)。一個可用區(qū)可以有多個RZone。

GZone(Global Zone):部署未按用戶維度拆分的系統(tǒng)，全局只有一份，被 RZone 依賴，提供不可拆分的數(shù)據(jù)和 服務(wù)，如配置型的業(yè)務(wù)。數(shù)據(jù)庫可以和 RZone 共享，多租戶隔離，全局只有一組，可以配置流量權(quán)重。

CZone(City Zone):部署未按用戶維度拆分的系統(tǒng)，被 RZone 高頻訪問 ，解決跨域通信延時問 題。為了解決異地延遲問題而特別設(shè)計，適合讀多寫少且不可拆分的業(yè)務(wù)。以城市為單位部署的單元，一般每個城市一套應(yīng)用和數(shù)據(jù)，是 GZone 的只讀副本。

可以自行看下支付寶的案例介紹。（支付寶案例鏈接：https://www.sohu.com/a/406634738_99940985）

4.三種模式對比

從應(yīng)用場景和實現(xiàn)成本上看下三種模式各有優(yōu)缺點

異地多活架構(gòu)關(guān)鍵技術(shù)（通用型）

大廠一般常用的方案是通用型的技術(shù)方案。我們重點說下業(yè)務(wù)通用性的架構(gòu)上的一些關(guān)鍵實現(xiàn)。

1. 流量調(diào)度

主要是負(fù)責(zé)將用戶的請求流量分配到對應(yīng)的單元,例如螞蟻的Spanner。Spanner 是螞蟻金服的七層網(wǎng)絡(luò)代理 ，承載了螞蟻金服所有的業(yè)務(wù)流量，包括支付寶 App、Web、商戶等的終端訪問。

如下圖，用戶通過螞蟻金服的網(wǎng)絡(luò)入口進來，通過多協(xié)議接入，到 LVS 和 Spanner，Spanner 作為統(tǒng)一七層網(wǎng)關(guān)把請求分發(fā)給后面的應(yīng)用。在 Spanner 上有很多業(yè)務(wù)邏輯、協(xié)議支持，比如 TLS 1.3、QUIC、HTTP 以及螞蟻自研的協(xié)議等。螞蟻的所有業(yè)務(wù)，包括支付寶錢包、其他頁面都是通過這個入口進來。

下圖是spanner在三地五中心架構(gòu)中的流量調(diào)度的場景，也可以發(fā)現(xiàn)，通過流量調(diào)度可實現(xiàn)：

機房內(nèi)zone隨機路由

Cookie zone轉(zhuǎn)發(fā)

容災(zāi)

彈性調(diào)度

壓測

灰度、藍(lán)綠發(fā)布

2. LDC路由

異地多活架構(gòu)下的路由中心，一般分三層。第一層是判斷決定訪問哪個機房或單元。第二層是在服務(wù)間調(diào)用的時候，來判斷請求應(yīng)該到哪個單元。第三層是到訪問數(shù)據(jù)層，最后一層的兜底，決定訪問到哪個DB.

結(jié)合螞蟻的架構(gòu)，看下路由情況

【入口流量路由】

箭頭1:對于應(yīng)該在本 IDC 處理的請求，就直接映射到對應(yīng)的 RZ 即可;

箭頭2:不在本 IDC 處理的請求，Spanner 可以轉(zhuǎn)發(fā)至其他 IDC 的 Spanner。

【服務(wù)路由】

RPC調(diào)用、MQ的一些場景，有些場景來說，A 用戶的一個請求可能關(guān)聯(lián)了對 B 用戶數(shù)據(jù)的訪問，比如 A 轉(zhuǎn)賬給 B，A 扣 完錢后要調(diào)用賬務(wù)系統(tǒng)去增加 B 的余額。這時候就涉及到:

箭頭3:跳轉(zhuǎn)到其他 IDC 的 RZone;

箭頭4:跳轉(zhuǎn)到本 IDC 的其他 RZone。

【數(shù)據(jù)路由】

RZ 訪問哪個數(shù)據(jù)庫，是可以配置的，對應(yīng)圖中箭頭5。

3. DRC

(Data Replication Center)：數(shù)據(jù)復(fù)制中心，主要是支持異構(gòu)數(shù)據(jù)庫實時同步，數(shù)據(jù)記錄變更訂閱服務(wù)。為業(yè)務(wù)跨域?qū)崟r同步、實時增量分發(fā)、異地雙活、數(shù)據(jù)雙向同步、數(shù)據(jù)巡檢、redis invaild等場景提供支持。可以參考o(jì)tter的架構(gòu)設(shè)計。

單機房同步

如上圖所示：

數(shù)據(jù)on-Fly，盡可能不落地，更快地進行數(shù)據(jù)同步。(開啟node loadBalancer算法，如果Node節(jié)點S+ETL落在不同的Node上，數(shù)據(jù)會有個網(wǎng)絡(luò)傳輸過程)。Node節(jié)點可以有failover / loadBalancer。

異地多活同步

如上圖所示：

數(shù)據(jù)涉及網(wǎng)絡(luò)傳輸，S/E/T/L幾個階段會分散在2個或者更多Node節(jié)點上，多個Node之間通過zookeeper進行協(xié)同工作 (一般是Select和Extract在一個機房的Node，Transform/Load落在另一個機房的Node)。

Node節(jié)點可以有failover / loadBalancer. (每個機房的Node節(jié)點，都可以是集群，一臺或者多臺機器)。

4. DAL

DAL是proxy型的數(shù)據(jù)庫中間件，支持mysql協(xié)議。在多活項目中，DAL責(zé)無旁貸扮演起保護數(shù)據(jù)正確性最后一道防線的角色。

對于個別一致性要求很高的應(yīng)用，一般提供了一種強一致的方案，比如餓了么的架構(gòu)中的Global Zone，Globa Zone 是一種跨機房的讀寫分離機制，所有的寫操作被定向到一個 Master 機房進行，以保證一致性，讀操作可以在每個機房的 Slave 庫執(zhí)行，也可以 bind 到 Master 機房進行，這一切都基于數(shù)據(jù)庫訪問層(DAL)完成，業(yè)務(wù)基本無感知。

5. 配置中心

負(fù)責(zé)Zone的配置和容災(zāi)切換，例如RZone的業(yè)務(wù)范圍，Zone訪問哪些數(shù)據(jù)庫等。

6. 發(fā)布平臺

服務(wù)多機房的發(fā)布。基于流量調(diào)度，完成Zone的藍(lán)綠發(fā)布、灰度發(fā)布等。

7. 建站平臺

快速新建一個完整的單元，包含機器搭建、基礎(chǔ)設(shè)施搭建，服務(wù)部署等，目前基本都是基于容器技術(shù)實現(xiàn)的。

異地多活架構(gòu)設(shè)計的方法

在實際的落地過程中，還是有一些通用的架構(gòu)設(shè)計方法來做參考。

1. 異地多活 - 3大原則

完美是優(yōu)秀的敵人，不能過于追求完美。在落地異地多活的時候，一般要遵守3個原則

（1）只保證核心業(yè)務(wù)。不同業(yè)務(wù)的數(shù)據(jù)特性不同，無法全部做到異地多活

（2）原則上只能做到最終一致性。復(fù)制肯定有時間窗口，拋棄實時一致性的想法。可以了解下【PACELC理論】

（3）只能保證絕大部分用戶。不能為了0.01%的用戶，影響到99.99%的用戶。

2. 異地多活 - 4個步驟

（1）業(yè)務(wù)定級

將業(yè)務(wù)按照某個維度進行優(yōu)先級排序，有限保證Top3業(yè)務(wù)異地多活。一般定級的方向，可以從訪問量、核心場景、收入來源看。

訪問量：登錄>注冊>修改密碼 核心場景：交易>社區(qū) 收入來源：訂單>搜索>編輯

（2）數(shù)據(jù)分類

分析TOP3中的每個業(yè)務(wù)的關(guān)鍵數(shù)據(jù)特點，將數(shù)據(jù)分類。

數(shù)據(jù)是否可恢復(fù)，例如：用戶恢復(fù)，系統(tǒng)提供恢復(fù)（密碼找回）、內(nèi)部恢復(fù)（例如編輯和運營重發(fā)）

數(shù)據(jù)修改量
數(shù)據(jù)被修改的數(shù)量和頻率，包括新增、刪除、修改。

一致性
數(shù)據(jù)的一致性要求，例如：強一致性（余額、庫存）、最終一致性（動態(tài)、興趣）。

唯一性
數(shù)據(jù)的唯一性要求，例如：全局唯一（用戶ID），可重復(fù)（昵稱）

可丟失性

數(shù)據(jù)是否可丟失，例如不可丟失（賬戶余額、訂單）、可丟失（tocken、session）

可恢復(fù)性

（3）數(shù)據(jù)同步

針對不同的數(shù)據(jù)分類設(shè)計不同的數(shù)據(jù)同步方式。

（4）異常處理

針對極端異常的情況，考慮如何處理，可以是技術(shù)手段，也可以是非技術(shù)手段。

業(yè)務(wù)兼容

體驗不好優(yōu)于無法體驗。比如數(shù)據(jù)短時間不一致，數(shù)據(jù)暫時無法獲取。

事后補償

少量用戶損失，可以用錢解決。適當(dāng)補償優(yōu)惠券。

人工修復(fù)
人工修訂數(shù)據(jù)，達(dá)到最終一致。

異地雙活實踐

1. 概述

下圖是當(dāng)前得物雙活架構(gòu)的業(yè)務(wù)示意圖，包含了路由中心、DRC、DAL、配置中心等基礎(chǔ)設(shè)施。

如圖所示，用戶在app發(fā)起請求后，客戶端會先根據(jù)緩存的信息，判斷該用戶應(yīng)該訪問到哪臺SLB，然后SLB將請求轉(zhuǎn)發(fā)到DLB，DLB會根據(jù)最新的路由規(guī)則，判斷該用戶是否屬于本單元，如果是繼續(xù)在本單元流轉(zhuǎn)，如果不是，將請求轉(zhuǎn)發(fā)到相應(yīng)單元。如圖中綠色請求所示，該用戶實際規(guī)則應(yīng)該路由到B機房，實際請求到A機房后，在DLB層也會將請求轉(zhuǎn)發(fā)到B機房。應(yīng)用服務(wù)注冊的時候會標(biāo)記自己的地址、服務(wù)類型。以便通過RPC服務(wù)間調(diào)用的時候進行路由。

在異地雙活落地的過程中，重點說下需關(guān)注的幾個點。

2. 重點模塊

數(shù)據(jù)拆分

從業(yè)務(wù)角度分析，最主要的是數(shù)據(jù)拆分。每個單元有部分用戶的數(shù)據(jù)，用戶盡可能地在本單元完成所有的行為操作。對于非用戶維度的數(shù)據(jù)，部署在中心單元（機房），向單元機房做單向同步。為了災(zāi)備，用戶維度的數(shù)據(jù)，單元機房和中心機房之間會雙向同步。

數(shù)據(jù)架構(gòu)示意圖

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

按照業(yè)務(wù)的拆分規(guī)則，單元模式的數(shù)據(jù)，不同的用戶會在不同的單元進行寫入。單元和中心之間會雙向同步。另外一種是中心模式的數(shù)據(jù)，這部分?jǐn)?shù)據(jù)在中心寫，全量同步到單元。可在單元進行訪問。如果當(dāng)前庫既有單元模式的物理表又有中心模式的物理表，不建議混合在一起，最好進行拆分。

單元化模式：兩邊都會寫入，雙向進行同步，保證兩邊都有全量數(shù)據(jù)。保證在流量切流后，用戶訪問數(shù)據(jù)不受影響。

單向復(fù)制模式：只在中心寫入，向單元全量同步，屬于單元只讀。

還有一種是僅在中心部署的，比如庫存數(shù)據(jù)，有強一致性要求，只在中心部署。數(shù)據(jù)的同步是通過DRC來完成的。

RPC服務(wù)框架

主要是通過rpc框架，讓開發(fā)者不需要關(guān)心調(diào)用服務(wù)的細(xì)節(jié)。provider 將自己的服務(wù)，注冊到注冊中心，consumer從注冊中心拉取服務(wù)，并進行消費調(diào)用。在rpc框架內(nèi)部，緩存了路由策略。可以直接在consumer獲取服務(wù)時，根據(jù)規(guī)則進行篩選。讓服務(wù)間的調(diào)用較簡單。而且也提高了路由調(diào)度的靈活性。比如機房就近調(diào)用，單元化路由調(diào)用等。這也是上述LDC路由中的第二層路由。

一般的單元化規(guī)則：

（1）哪些用戶屬于哪個單元

（2）哪些應(yīng)用屬于單元

但實際應(yīng)用中，還有比較復(fù)雜的場景，從應(yīng)用場景上，目前主要是分為三種：普通服務(wù)，單元服務(wù)，中心服務(wù)。

【普通模式】的服務(wù)就是沒有做單元化改造的服務(wù)，沒有單元的概念。服務(wù)間調(diào)用是就近調(diào)用，也就是本單元優(yōu)先調(diào)用，如果本單元沒有，會去中心調(diào)用。中心對普通服務(wù)的調(diào)用，也是直接調(diào)用中心的普通服務(wù)。

【單元模式】的服務(wù)是單元化路由服務(wù)，會根據(jù)路由key(用戶ID)，將請求進行路由到正確的單元。

【中心模式】的服務(wù)，盡管在中心和單元的注冊中心都會注冊，但請求最終只會路由到中心去。

緩存失敗

做了雙活之后，緩存失效的邏輯也會有一定變化。大部分應(yīng)用，原緩存失效邏輯是：應(yīng)用發(fā)起數(shù)據(jù)更新操作，先更新DB的數(shù)據(jù)，再進行緩存失效的處理，下次有請求的時候，數(shù)據(jù)從DB加載到緩存。

但做了雙活之后，中心的數(shù)據(jù)發(fā)生變更，單元的緩存也要做失效處理。但單元的緩存失效不能直接依賴中心DB的變更消息。如果直接依賴中心DB的變更消息，單元的緩存失效有可能在單元DB 變更之前失效，此時用戶來訪問，可能把舊數(shù)據(jù)寫入緩存，導(dǎo)致數(shù)據(jù)不一致。

所以目前的解決方案是，通過DRC，將中心的DB數(shù)據(jù)同步到單元，單元DB變更后，會通過DRC把binlog發(fā)送到MQ，應(yīng)用再去操作緩存失效或更新。

MQ消息

MQ中間件也是需要做改造的，要保證消息能夠落到正確的單元，并在正確的單元消費。

做雙活前原有的的邏輯，大部分是接受消息后，對數(shù)據(jù)進行插入或更新操作。如果做了單元改造的庫，部分?jǐn)?shù)據(jù)已經(jīng)根據(jù)相應(yīng)策略劃到對應(yīng)單元寫入，這時消息卻在中心進行消費，這會導(dǎo)致兩邊雙寫，出現(xiàn)臟數(shù)據(jù)。這就需要MQ也有有路由的能力，讓消息路由到正確的單元，不僅僅是依賴RPC框架或DAL 層的路由限制。

目前的方案，消息會雙向復(fù)制。根據(jù)消費方配置的訂閱方式，進行訂閱消費。

中心訂閱，只在中心消費

普通訂閱， 就近消費本單元的消息。

單元訂閱，各單元消費各單元的消息。DMQ會根據(jù)路由規(guī)則路由到所屬單元消費

全單元訂閱，發(fā)到所有單元，所有單元都會消費一次

3. 容災(zāi)能力&策略

（1）切流步驟

禁寫切流部分用戶的請求。在流量入口、RPC框架、DAL層都會進行攔截，將請求丟棄，并拋異常。

DRC按照時間節(jié)點，確認(rèn)同步是否完成。

數(shù)據(jù)同步完成后，按照最新的路由規(guī)則開始進行路由。

（2）容災(zāi)場景

單元機房出現(xiàn)故障，可以將流量切到中心新房

中心機房故障，當(dāng)前的方案不能解決。可以在后續(xù)做到中心故障切換到中心備份環(huán)境，或者說，中心機房做邏輯機房，增強中心機房的抗災(zāi)能力。如下示意圖

【附錄】

常見的幾個核心指標(biāo)含義

【RTO】（Recovery Time Objective），即恢復(fù)時間目標(biāo)。主要指的是所能容忍的業(yè)務(wù)停止服務(wù)的最長時間，也就是從災(zāi)難發(fā)生到業(yè)務(wù)系統(tǒng)恢復(fù)服務(wù)功能所需要的最短時間周期。RTO描述了恢復(fù)過程需要花費的時間。例如：假設(shè)在時間點t1啟動恢復(fù)過程并且在時間點t2完成恢復(fù)，那么RTO就等于t2-t1。RTO值越小，代表容災(zāi)系統(tǒng)的數(shù)據(jù)恢復(fù)能力越強。RTO=0就意味著在任何情況下都不允許目標(biāo)業(yè)務(wù)有任何運營停頓。

【RPO】（Recovery Point Object)恢復(fù)點目標(biāo)，指一個過去的時間點，當(dāng)災(zāi)難或緊急事件發(fā)生時，數(shù)據(jù)可以恢復(fù)到的時間點，是業(yè)務(wù)系統(tǒng)所能容忍的數(shù)據(jù)丟失量。例如每天00：00進行數(shù)據(jù)備份，那么如果今天發(fā)生了宕機事件，數(shù)據(jù)可以恢復(fù)到的時間點（RPO）就是今天的00：00，如果凌晨3點發(fā)生災(zāi)難或宕機事件，損失的數(shù)據(jù)就是三個小時，如果23：59發(fā)生災(zāi)難，那么損失的數(shù)據(jù)就是約24小時，所以該用戶的RPO就是24小時，即用戶最大的數(shù)據(jù)損失量是24小時。所以RPO指的是用戶允許損失的最大數(shù)據(jù)量。這和數(shù)據(jù)備份的頻率有關(guān)，為了改進RPO，必然要增加數(shù)據(jù)備份的頻率才行。RPO指標(biāo)主要反映了業(yè)務(wù)連續(xù)性管理體系下備用數(shù)據(jù)的有效性，即RPO取值越小，表示系統(tǒng)對數(shù)據(jù)完整性的保證能力越強。

可以通過下圖來對比RTO和RPO。

從圖中不難看出，RPO指標(biāo)來自于故障發(fā)生前，而RTO指標(biāo)來自故障發(fā)生后，兩者的數(shù)值越小，就能有效縮短業(yè)務(wù)正常到業(yè)務(wù)過渡期的時間間隔，單一地提升RTO或RPO指標(biāo)也可以縮減業(yè)務(wù)故障到過渡期的時間，具體從哪個指標(biāo)上來改善，就要結(jié)合的實際情況分析，提升那個指標(biāo)代價最小，效果更明顯。

【W(wǎng)RT】(Work Recovery Time)，工作恢復(fù)時間，指“系統(tǒng)恢復(fù)正常后，恢復(fù)業(yè)務(wù)所需的時間”，因為要進行各種業(yè)務(wù)檢查、校驗、修復(fù)。

【MTD】(Maximum Tolerable Downtime)，最大可容忍宕機時間，等于 RTO + WRT。

審核編輯：湯梓紅