采用高可用系統架構支持重要系統，為關鍵業務提供7x24的不間斷服務，已經成為眾多企業保障業務穩定、持續運轉的主要選擇。

服務多活是高可用架構重要實施手段，本文介紹了一些業界常用的多活手段，例如同城雙活、兩地三中心、異地多活架構設計方案并詳述了各種方案的優缺點。

一、為什么要做多活

隨著移動互聯網的深入發展，用戶增長達到一定規模后，不少企業都會面臨高并發業務和海量數據的挑戰，傳統的單機房在機器容量上存在瓶頸。

在一些極端場景下，有可能所有服務器都出現故障，例如機房斷電、機房火災、地震等這些不可抗因素會導致系統所有服務器都故障從而導致業務整體癱瘓，而且即使有其他地區的備份，把備份業務系統全部恢復到能夠正常提供業務，花費的時間也比較長。

為了滿足中心業務連續性，增強抗風險能力，多活作為一種可靠的高可用部署架構，成為各大互聯網公司的首要選擇。

1、多活場景

多活架構的關鍵點就是指不同地理位置上的系統都能夠提供業務服務，這里的“活”是指實時提供服務的意思。與“活”對應的是字是“備”，備是備份，正常情況下對外是不提供服務的，如果需要提供服務，則需要大量的人工干預和操作，花費大量的時間才能讓“備”變成“活。

單純從描述來看多活很強大，能夠保證在災難的情況下業務都不受影響，是不是意味著不管什么業務，我們都要去實現多活架構呢？其實不是，實現多活架構都要付出一定的代價，具體表現為：

•  不同多活方案實現復雜度不一樣，隨著業務規模和容災級別的提升，多活方案會給業務系統設計帶來更大復雜度；
•  不管采用哪種多活方案都難以完全避免跨機房甚至是跨地區服務調用帶來的耗時增加；
•  多活會帶來成本會上升，畢竟要多在一個或者多個機房搭建獨立的一套業務系統。

因此，多活雖然功能很強大，但也不是每個業務都要上多活。例如，企業內部的IT系統、管理系統、博客站點等，如果無法承受異地多活帶來的復雜度和成本，是可以不做異地多活的，而對于重要的業務例如核心金融、支付、交易等有必要做多活。

2、多活方案

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

下面我們會逐步介紹這幾種多活方案并給出每種方案的優點和缺點。選用哪種方案要結合具體業務規模、當前基礎建設能力、投入產出比等多種因素來決定。

二、同城雙活

同城雙活是在同城或相近區域內建立兩個機房。同城雙機房距離比較近，通信線路質量較好，比較容易實現數據的同步復制 ，保證高度的數據完整性和數據零丟失。

同城兩個機房各承擔一部分流量，一般入口流量完全隨機，內部RPC調用盡量通過就近路由閉環在同機房，相當于兩個機房鏡像部署了兩個獨立集群，數據仍然是單點寫到主機房數據庫，然后實時同步到另外一個機房。

下圖展示了同城雙活簡單部署架構，當然一般真實部署和考慮問題要遠遠比下圖復雜：

服務調用基本在同機房內完成閉環，數據仍然是單點寫到主機房數據儲存，然后實時同步復制到同城備份機房。當機房A出現問題時候運維人員只需要通過GSLB或者其他方案手動更改路由方式將流量路由到B機房。

同城雙活可有效用于防范火災、建筑物破壞、供電故障、計算機系統及人為破壞引起的機房災難。

1、服務路由

•  zk集群：每個機房都部署一個zk集群，機房之間zk數據進行實時雙向同步，每個機房都擁有所有機房zk注冊數據；
•  路由方案：條件路由  > 就近路由 > 跨機房路由，盡量避免跨機房調用；
•  訂閱方案：consumer訂閱所有機房服務，provider只向該機房zk集群進行注冊。

2、數據雙活

• MySQL：采用MHA部署方案，主從半同步方案保證數據一致性。讀寫分離、讀就近路由到機房內數據節點、寫路由到master節點所在機房；
•  Redis：Redis cluster模式主從同步，就近讀、寫路由主節點機房。采用原生主從同步跨機房寫性能較低，也可以依靠CRDT理論構建多節點雙向同步，實現機房就近讀寫，但是整體實現較為復雜。

3、同城雙城方案評估

1）優勢

•  服務同城雙活，數據同城災備，同城不丟失數據情況下跨機房級別容災；
•  架構方案較為簡單，核心是解決底層數據雙活，由于雙機房距離近，通信質量好，底層儲存例如MySQL可以采用同步復制，有效保證雙機房數據一致性。

2）劣勢

•  數據庫寫數據存在跨機房調用，在復雜業務以及鏈路下頻繁跨機房調用增加響應時間，影響系統性能和用戶體驗；
•  保證同城市地區容災，當服務所在的城市或者地區網絡整體故障、發生不可抗拒的自然災害時候有服務故障以及丟失數據風險。對于核心金融業務至少要有跨地區級別的災備能力；
•  服務規模足夠大(例如單體應用超過萬臺機器)，所有機器鏈接一個主數據庫實例會引起連接不足問題。

三、兩地三中心架構

所謂兩地三中心是指同城雙中心 + 異地災備中心。異地災備中心是指在異地的城市建立一個備份的災備中心，用于雙中心的數據備份，數據和服務平時都是冷的，當雙中心所在城市或者地區出現異常而都無法對外提供服務的時候，異地災備中心可以用備份數據進行業務的恢復。

兩地三中心方案評估

1）優勢

•  服務同城雙活，數據同城災備，同城不丟失數據情況下跨機房級別容災；
•  架構方案較為簡單，核心是解決底層數據雙活，由于雙機房距離近，通信質量好，底層儲存例如MySQL可以采用同步復制，有效保證雙機房數據一致性；
•  災備中心能防范同城雙中心同時出現故障時候利用備份數據進行業務的恢復。

2）劣勢

•  數據庫寫數據存在跨機房調用，在復雜業務以及鏈路下頻繁跨機房調用增加響應時間，影響系統性能和用戶體驗；
•  服務規模足夠大(例如單體應用超過萬臺機器)，所有機器鏈接一個主數據庫實例會引起連接不足問題；
•  出問題不敢輕易將流量切往異地數據備份中心，異地的備份數據中心是冷的，平時沒有流量進入，因此出問題需要較長時間對異地災備機房進行驗證。

同城雙活和兩地三中心建設方案建設復雜度都不高，兩地三中心相比同城雙活有效解決了異地數據災備問題，但是依然不能解決同城雙活存在的多處缺點，想要解決這兩種架構存在的弊端就要引入更復雜的解決方案去解決這些問題。

四、異地多活

異地多活指分布在異地的多個站點同時對外提供服務的業務場景。異地多活是高可用架構設計的一種，與傳統的災備設計的最主要區別在于“多活”，即所有站點都是同時在對外提供服務的。

1、異地多活挑戰

•  應用要走向異地，首先要面對的便是物理距離帶來的延時。如果某個應用請求需要在異地多個單元對同一行記錄進行修改，為滿足異地單元間數據庫數據的一致性和完整性，需要付出高昂的時間成本；
•  解決異地高延時即要做到單元內數據讀寫封閉，不能出現不同單元對同一行數據進行修改，所以我們需要找到一個維度去劃分單元；
•  某個單元內訪問其他單元數據需要能正確路由到對應的單元，例如A用戶給B用戶轉賬，A用戶和B用戶數據不在一個單元內，對B用戶的操作能路由到相應的單元；
•  面臨的數據同步挑戰，對于單元封閉的數據需全部同步到對應單元，對于讀寫分離類型的，我們要把中心的數據同步到單元。

2、單元化

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

單元化架構就是把單元作為系統部署的基本單位，在全站所有機房中部署數個單元，每個機房里的單元數目不定，任意一個單元都部署了系統所需的所有的應用。單元化架構下，服務仍然是分層的，不同的是每一層中的任意一個節點都屬于且僅屬于某一個單元，上層調用下層時，僅會選擇本單元內的節點。

選擇什么維度來進行流量切分，要從業務本身入手去分析。

例如電商業務和金融的業務，最重要的流程即下單、支付、交易流程，通過對用戶id進行數據切分拆分是最好的選擇，買家的相關操作都會在買家所在的本單元內完成。

對于商家相關操作則無法進行單元化，需要按照下面介紹的非單元化模式去部署。當然用戶操作業務并非完全能避免跨單元甚至是跨機房調用，例如兩個買家A和B轉賬業務，A和B所屬數據單元不一致的時候，對B進行操作就需要跨單元去完成，后面我們會介紹跨單元調用服務路由問題。

3、非單元化應用和數據

對于無法單元化的業務和應用，會存在下面兩種可能性：

•  延時不敏感但是對數據一致性非常敏感，這類應用只能按照同城雙活方式部署。其他應用調用該類應用的時候會存在跨地區調用可能性，要能容忍延時，這類應用我們稱為MZone應用；
•  對數據調用延時敏感但是可以容忍數據短時間不一致，這類應用和數據可以保持一個機房一份全量數據，機房之間以增量的方式實時同步，這類應用我們暫時稱為QZone。

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

4、請求路由

1）API入口網關

為了保證用戶請求能正確進入自己所屬單元，每一個機房都會部署流量入口網關集群。當用戶請求到達進入機房內最先進入到流量網關，流量網關能感知全局的流量分片情況，計算用戶所處流量單元并將流量轉發到對應的單元，這樣就可以將用戶請求路由到對應的單元內。

采用GateWayr轉發方式可以確定用戶單元從而將用戶流量路由到正確位置，但是HTTP轉發也會造成一定性能損耗。

為了減少HTTP流量轉發量，可以在在用戶請求返回的時候在cookie上帶上該用戶的路由標識信息。當用戶下次在請求的時候請求的時候可以提前獲取到路由標識直接請求到對應的單元，這種方式可以大幅度減少HTTP流量轉發。

2）服務路由

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

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

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

5、數據同步

QZone類型數據：這種數據只需要保證最終一致性，對于短暫不一致無影響，但是對延時非常銘感，例如一些算法、風控、配置等數據。這類數據基本上都是每個機房部署一套QZone，然后機房之間相互同步。

MZone數據：這類數據對一致性非常銘感，不能出現不一致，只能采用同城雙活部署方式，業務需要能容忍異地調用延時。

RZone數據：這類數據每個Zone都有自己的主節點，如果數據不在該單元內需要路由到對應的節點去寫。這類數據部署情況像下面這樣：

6、方案評估

1）優勢

•  容災能力大幅度提高，服務異地多活，數據異地多活；
•  理論上系統服務可以水平擴展，異地多機房突破大幅度提升整體容量，理論上不會有性能擔憂；
•  將用戶流量切分到多個機房和地區去，有效能減少機房和地區級別的故障影響范圍。

2）劣勢

•  架構非常復雜，部署和運維成本很高，需要對公司依賴的中間件、儲存做多方面能力改造；
•  對業務系統有一定的侵入性，由于單元化影響服務調用或者寫入數據要路由到對應的單元，業務系統需要設置路由標識(例如uid)；
•  無法完全避免跨單元、跨地區調用服務，例如上面的轉賬業務。我們要做的是盡力避免跨地區的服務調用。

五、總結

本文討論了一些多活建設的大體思路以及一些關鍵技術點的解決方案，各種不同方案對比。要建立起完整的異地多活能力遠遠比上面討論的要復雜的多，需要對依賴的各種中間件、儲存等做相應的單元化改造并配套完整的流量調度和運維管控能力。

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