互聯網常見的高可用手段。比如服務冗余部署、異步化設計、負載均衡、服務限流降級熔斷、架構拆分、服務治理、分布式存儲等等，今天主要是一起聊下，多機房部署的災備架構模式，來確保服務的高可用。

常見的架構模式

災備架構比較常見的幾種模式，基本分為同城多中心、跨城多中心、跨國多中心。從字面上看，這幾個架構模式好像差不多的，只是距離上的差異，其他的感覺都差不多的。但，就是簡單的距離上的差異，就會導致在架構上關鍵的應用場景以及技術本質上有較大的區別。

1. 同城多中心架構

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

同城雙中心

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

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

（2）光纖互聯

（3）機房網絡延遲<2ms?

同城雙中心的架構本質是同城雙中心可以當做一個邏輯機房。也就是將同一個集群上的節點，部署在兩個物理機房。這樣可以應對機房級別的災難。如下圖所示

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

同城三中心

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

下圖只是示意圖，實際的架構要復雜得多。

2.跨城多中心架構

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

跨城雙中心主要的應用場景是 :

進行城市級別的災備

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

異地多活

并不是所有的跨城多中心架構都能滿足 這幾個應用場景，不同的跨城雙中心架構有不同的應用的場景。從城市的距離上，分為近鄰城市和遠端城市場景。

跨城雙中心-近鄰城市

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

應用場景：

避免城市級別的災難，但是無法避免區域性災難

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

跨城雙中心-遠端城市

遠端城市架構模式的關鍵特征是選擇兩個遠距離的城市；機房延時>30ms，不能當作同一邏輯機房；

應用場景

避免城市級別和區域性級別的災難

適應異地多活架構

可以做分區架構

跨城多中心

跨城多中心的一般應用場景，就是用戶分區、就近接入、異地多活。

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

3.跨國數據中心架構

跨國數據中心

跨國數據中心的基本特點：

（1）全球部署

（2）合規和監管，不同的地區的數據法規不一樣，比如用戶的隱私信息之類的

（3）區域用戶分區

（4）不能做異地多活。一個原因是時間延遲問題，另外還是在于合規跟監管，不同地區的合規跟監管數據隱私保護的不一樣，沒辦法做異地多活。

可以看下Google和Facebook的跨國數據中心，上面的圖是Google的下圖是Facebook的

跨國數據中心。主要部署在北美、歐洲、亞洲區。

4.五種架構對比

主要從應用場景維度看下幾種架構的區別

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

異地多活的三種模式

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

1.業務定制型異地多活

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

如下圖中的示意圖：

A業務通過數據庫+消息隊列同步的方式實現，

B業務通過數據庫+算法的方式實現異地多活。

兩種業務的實現方式是根據自身的業務場景來決定的。

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

2.業務通用型異地多活

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

優點

a. 對硬件基礎設施沒有強要求，例如機房部署、存儲系統、時延等，一般部署在遠距離的兩個城市，可以支持區域級別的故障處理。

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

缺點

a. 配套服務復雜，包括流量調度、容災切換、建站平臺、配置管理等

b. 存在全局單點業務。例如庫存、賣家等相關業務

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

示意圖

「案例 」淘寶的單元化架構

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

示意圖

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

3. 存儲通用型異地多活

基于業務通用性架構去做，有的業務不能滿足base理論，就不能實現異地多活。那有沒有一種方法，與業務不強相關，實現多活的架構設計呢？答案肯定是有的，從存儲系統來實現，采用本身已經支持一致性的存儲系統，實現存儲通用型異地多活。

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

缺點就是

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

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

「案例」螞蟻的OceanBase

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

如上圖，簡單理解：

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

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

（3）OBServer 上會運行 SQL 引擎、事務引擎和存儲引擎，用戶的 SQL 查詢經過 SQL 引擎 解析優化后轉化為事務引擎和存儲引擎的內部調用。

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

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

「案例」螞蟻的LDC架構

結合淘寶單元化的架構+OceanBase

示意圖

如上圖，簡單理解：

RZone(Region Zone):部署按用戶維度拆分 的關鍵業務系統。核心業務和數據單元化拆分，每個單元內盡量調用閉環， 擁有自己的數據，能完成所有業務。一個可用區可以有多個RZone。

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

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

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

4.三種模式對比

從應用場景和實現成本上看下三種模式各有優缺點

異地多活架構關鍵技術（通用型）

大廠一般常用的方案是通用型的技術方案。我們重點說下業務通用性的架構上的一些關鍵實現。

1. 流量調度

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

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

下圖是spanner在三地五中心架構中的流量調度的場景，也可以發現，通過流量調度可實現：

機房內zone隨機路由

Cookie zone轉發

容災

彈性調度

壓測

灰度、藍綠發布

2. LDC路由

異地多活架構下的路由中心，一般分三層。第一層是判斷決定訪問哪個機房或單元。第二層是在服務間調用的時候，來判斷請求應該到哪個單元。第三層是到訪問數據層，最后一層的兜底，決定訪問到哪個DB.

結合螞蟻的架構，看下路由情況

【入口流量路由】

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

箭頭2:不在本 IDC 處理的請求，Spanner 可以轉發至其他 IDC 的 Spanner。

【服務路由】

RPC調用、MQ的一些場景，有些場景來說，A 用戶的一個請求可能關聯了對 B 用戶數據的訪問，比如 A 轉賬給 B，A 扣 完錢后要調用賬務系統去增加 B 的余額。這時候就涉及到:

箭頭3:跳轉到其他 IDC 的 RZone;

箭頭4:跳轉到本 IDC 的其他 RZone。

【數據路由】

RZ 訪問哪個數據庫，是可以配置的，對應圖中箭頭5。

3. DRC

(Data Replication Center)：數據復制中心，主要是支持異構數據庫實時同步，數據記錄變更訂閱服務。為業務跨域實時同步、實時增量分發、異地雙活、數據雙向同步、數據巡檢、redis invaild等場景提供支持。可以參考otter的架構設計。

單機房同步

如上圖所示：

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

異地多活同步

如上圖所示：

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

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

4. DAL

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

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

5. 配置中心

負責Zone的配置和容災切換，例如RZone的業務范圍，Zone訪問哪些數據庫等。

6. 發布平臺

服務多機房的發布。基于流量調度，完成Zone的藍綠發布、灰度發布等。

7. 建站平臺

快速新建一個完整的單元，包含機器搭建、基礎設施搭建，服務部署等，目前基本都是基于容器技術實現的。

異地多活架構設計的方法

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

1. 異地多活 - 3大原則

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

（1）只保證核心業務。不同業務的數據特性不同，無法全部做到異地多活

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

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

2. 異地多活 - 4個步驟

（1）業務定級

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

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

（2）數據分類

分析TOP3中的每個業務的關鍵數據特點，將數據分類。

數據是否可恢復，例如：用戶恢復，系統提供恢復（密碼找回）、內部恢復（例如編輯和運營重發）

數據修改量
數據被修改的數量和頻率，包括新增、刪除、修改。

一致性
數據的一致性要求，例如：強一致性（余額、庫存）、最終一致性（動態、興趣）。

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

可丟失性

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

可恢復性

（3）數據同步

針對不同的數據分類設計不同的數據同步方式。

（4）異常處理

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

業務兼容

體驗不好優于無法體驗。比如數據短時間不一致，數據暫時無法獲取。

事后補償

少量用戶損失，可以用錢解決。適當補償優惠券。

人工修復
人工修訂數據，達到最終一致。

異地雙活實踐

1. 概述

下圖是當前得物雙活架構的業務示意圖，包含了路由中心、DRC、DAL、配置中心等基礎設施。

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

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

2. 重點模塊

數據拆分

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

數據架構示意圖

數據同步

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

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

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

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

RPC服務框架

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

一般的單元化規則：

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

（2）哪些應用屬于單元

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

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

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

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

緩存失敗

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

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

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

MQ消息

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

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

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

中心訂閱，只在中心消費

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

單元訂閱，各單元消費各單元的消息。DMQ會根據路由規則路由到所屬單元消費

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

3. 容災能力&策略

（1）切流步驟

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

DRC按照時間節點，確認同步是否完成。

數據同步完成后，按照最新的路由規則開始進行路由。

（2）容災場景

單元機房出現故障，可以將流量切到中心新房

中心機房故障，當前的方案不能解決。可以在后續做到中心故障切換到中心備份環境，或者說，中心機房做邏輯機房，增強中心機房的抗災能力。如下示意圖

【附錄】

常見的幾個核心指標含義

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

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

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

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

【WRT】(Work Recovery Time)，工作恢復時間，指“系統恢復正常后，恢復業務所需的時間”，因為要進行各種業務檢查、校驗、修復。

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

審核編輯：湯梓紅