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

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

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

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

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

同城雙中心

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

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

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

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

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

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

同城三中心

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

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

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

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

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

進(jìn)行城市級(jí)別的災(zāi)備

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

異地多活

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

跨城雙中心-近鄰城市

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

應(yīng)用場(chǎng)景：

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

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

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

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

應(yīng)用場(chǎng)景

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

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

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

跨城多中心

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

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

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

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

跨國(guó)數(shù)據(jù)中心的基本特點(diǎn)：

（1）全球部署

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

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

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

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

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

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

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

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

異地多活的三種模式

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

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

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

如下圖中的示意圖：

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

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

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

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

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

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

優(yōu)點(diǎn)

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

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

缺點(diǎn)

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

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

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

示意圖

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

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

示意圖

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

3. 存儲(chǔ)通用型異地多活

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

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

缺點(diǎn)就是

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

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

「案例」螞蟻的OceanBase

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

如上圖，簡(jiǎn)單理解：

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

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

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

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

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

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

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

示意圖

如上圖，簡(jiǎn)單理解：

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

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

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

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

4.三種模式對(duì)比

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

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

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

1. 流量調(diào)度

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

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

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

機(jī)房?jī)?nèi)zone隨機(jī)路由

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

容災(zāi)

彈性調(diào)度

壓測(cè)

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

2. LDC路由

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

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

【入口流量路由】

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

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

【服務(wù)路由】

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

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

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

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

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

3. DRC

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

單機(jī)房同步

如上圖所示：

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

異地多活同步

如上圖所示：

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

Node節(jié)點(diǎn)可以有failover / loadBalancer. (每個(gè)機(jī)房的Node節(jié)點(diǎn)，都可以是集群，一臺(tái)或者多臺(tái)機(jī)器)。

4. DAL

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

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

5. 配置中心

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

6. 發(fā)布平臺(tái)

服務(wù)多機(jī)房的發(fā)布?；诹髁空{(diào)度，完成Zone的藍(lán)綠發(fā)布、灰度發(fā)布等。

7. 建站平臺(tái)

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

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

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

1. 異地多活 - 3大原則

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

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

（2）原則上只能做到最終一致性。復(fù)制肯定有時(shí)間窗口，拋棄實(shí)時(shí)一致性的想法?？梢粤私庀隆綪ACELC理論】

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

2. 異地多活 - 4個(gè)步驟

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

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

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

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

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

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

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

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

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

可丟失性

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

可恢復(fù)性

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

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

（4）異常處理

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

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

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

事后補(bǔ)償

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

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

異地雙活實(shí)踐

1. 概述

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

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

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

2. 重點(diǎn)模塊

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

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

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

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

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

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

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

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

RPC服務(wù)框架

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

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

（1）哪些用戶屬于哪個(gè)單元

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

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

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

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

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

緩存失敗

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

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

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

MQ消息

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

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

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

中心訂閱，只在中心消費(fèi)

普通訂閱， 就近消費(fèi)本單元的消息。

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

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

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

（1）切流步驟

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

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

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

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

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

中心機(jī)房故障，當(dāng)前的方案不能解決?？梢栽诤罄m(xù)做到中心故障切換到中心備份環(huán)境，或者說，中心機(jī)房做邏輯機(jī)房，增強(qiáng)中心機(jī)房的抗災(zāi)能力。如下示意圖

【附錄】

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

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

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

可以通過下圖來對(duì)比RTO和RPO。

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

【W(wǎng)RT】(Work Recovery Time)，工作恢復(fù)時(shí)間，指“系統(tǒng)恢復(fù)正常后，恢復(fù)業(yè)務(wù)所需的時(shí)間”，因?yàn)橐M(jìn)行各種業(yè)務(wù)檢查、校驗(yàn)、修復(fù)。

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

審核編輯：湯梓紅