1. 前言
多活容災 MSHA（Multi-Site High Availability），是在阿⾥巴巴電商業務環境演進出來的多活容災架構解決⽅案，可以將業務恢復和故障恢復解耦，有基於靈活的規則調度、跨域跨雲管控、數據保護等能力，保障故障場景下的業務快速恢復，助⼒企業的容災穩定性建設。
多活，顧名思義就是分佈在多個站點同時對外提供服務。與傳統的災備的最主要區別就是多活裡的所有站點同時在對外提供服務，不僅解決了容災本身問題，還提升了業務連續性，並且實現了容量的擴展。
本文結合實際案例來闡述下企業接入多活的架構變化，下文的邏輯業務中心均簡稱為“單元”。
圖1：企業接入多活的架構變化
2. 架構案例
2.1 異地雙讀
2.1.1 客戶背景
國家某政府機構的專有云大數據項目在雲平臺建設完成後，隨著業務規模的不斷增長，數據量級不斷突破預期上線，客戶的 ADB服務壓力隨之增大。在新業務逐個上線的過程中，客戶開展實時數據分析常出現 ADB資源不足的情況，影響線上業務穩定性。
由於客戶本身建立兩個數據中心，前期因為 RT 問題，僅使用一個數據中心，另外一個並未投入使用。客戶期望充分發揮兩個中心的計算資源，基於 MSHA 容災解決方案構建“異地雙讀”體系，以達到保障基於 ADB數據庫的各類查詢業務穩定性的目的。
2.1.2 方案落地
2.1.2.1 選取分區維度
基於實際業務流程，分析得到查詢業務存在核心操作人員，操作人員登錄系統後，進行基礎業務操作行為，確定兩種分片方式進行選型考慮，分別為“按分流標識分流”和“按功能URI分流”。
按分流標識分流
根據實際流量請求中攜帶的分流標識進行分流，是異地雙活解決方案裡的標準方案。業務按照自身實際情況選取合適的分流標識。
原則上選取儘可能分攤均衡的維度進行分流，便於後續動態靈活調控不同數據中心比例。比如：
- 以省份分流。x省、xx省分流到單元A，其他省分流到單元B，控制不同的省流量路由到不同的數據中心。
- 以用戶分流。將一批有規律的用戶分流到單元1，例如尾號為奇數的用戶；其餘用戶分流到單元2。
按分流標識分流的優點為靈活可控，可以通過切流進行精細的流量調控。但也需要關注以下問題：
- 業務側需要進行一定的功能改造，與多活相關的流量必須攜帶分流標識；
- 若單一維度的流量佔流量大頭，則此分流方式仍然做不到精細調控，比如按省分流的情況下某省的流量佔總流量的大部分。
按功能 URI 分流
根據 URI 前綴進行分流，比如某域名的流量存在80個 URI ，將其中40個分流到單元A，另外40個分流到單元B。
按功能 URI 分流的優點是業務無需改造，僅需梳理出所有 URI 即可，但也存在以下問題：
- 可維護性差。URI 會跟隨業務的開發迭代不斷變化，後續無法長期保證 URI 分流配置的正確性。
- 切流變更復雜。每個域名每個 URI 的分流配置都不一樣，切流需要變更到所有域名的配置，變更操作複雜。
- 若單一 URI 佔所有流量的大部分，則此分流方式無法精細調控。
最終選型
經過跟客戶深度溝通交流，由於當前業務操作均按省維度進行登錄操作，改造成本小且不存在一個超大佔比的省份，因此選擇“按分流標識分流”的方式並按省作為分流標識。
2.1.2.2 方案計劃
基於確定的分區維度，雙活項目組指定詳細的落地計劃，大致分為前期準備、業務改造、測試實施、生產實施、技術交流等步驟環節。
圖2：雙活項目組指定詳細的落地計劃
2.1.2.3 架構演進
由於方案確定之時，客戶兩個雲平臺版本一個為 3.5.x，一個為 3.9.0，而相應的多活產品（MSHA）對雲平臺有版本要求，僅其中一個符合要求。考慮業務的高可用能力，我們確定分階段進行，逐步讓業務具備異地雙讀能力。
階段一：僅在符合要求的雲內部署多活產品（MSHA）
優勢：
- 實施簡單。應用改動小，僅需進行域名、URI、多活標識的訂正，接入層接入多活管控體系即可。
- 個性靈活。多活產品支持 URI 精細化控制，可達到業務個性化訴求，部分功能點全部保留在原有的單元，其他功能點按省進行劃分，分流到兩個不通的單元。
- 快速恢復。災難場景下，雙活業務基於多活控制檯（MSHA）可進行快速切流，達到恢復業務的目的。
- 逐步實施。日常場景下，雙活業務具備小規模灰度放量的切流能力。
劣勢：
- 高可用能力無。由於僅一個雲平臺部署多活產品，該雲平臺發生故障時，該雲所有的業務均不可用，高可用能力一般。但，此風險，在沒做雙活的時候，本身也具備。
劣勢解決方案：
- 快恢預案。日常場景維護災難場景的應急預案，當出現劣勢的災難場景，執行預案，另外一朵正常雲的業務VIP下掛在業務域名下。
圖3：僅在符合要求的雲內部署多活產品（MSHA）
階段二：兩朵雲均部署多活產品（MSHA）
優勢：在階段一具備的優勢前提下，規避了其劣勢，保障了災難場景時，多活產品自身高可用能力，進一步提高業務的抗風險能力。
圖4：兩朵雲均部署多活產品（MSHA）
2.2 異地雙讀
2.2.1 客戶背景
國家某政府機構的在線業務雲平臺當前採用單中心單節點的部署模式，集中在同一棟樓中，核心在線業務存在“單點”運行的安全隱患：
- 自然災害。業務所在的數據中心位於颱風、洪澇等自然災害高發地區，一旦因為自然災害造成電力中斷、機房損壞等情況，平臺可能全面癱瘓。
- 網絡風險。業務所在的數據中心目前電力採用雙路供電，與下屬的省系統基於聯通、電信等鏈路進行通信，一旦出現如施工挖斷線纜造成電力中斷、網絡中斷等極端情況，平臺服務將全面中斷。
- 人為操作。人為操作失誤或蓄意破壞導致平臺故障或數據丟失，導致平臺不可用。
雲平臺承載的在線業務系統直接關係到國計民生，影響重大，一旦出現數據篡改丟失和系統長期無法訪問，後果難以承受。為落實各項安全整改建議，確保數據安全、萬無一失，客戶期望在原有的數據中心雲平臺之外，再建設“異地雙活”第二中心，基於“異地雙活”解決方案能力，提高核心業務的業務連續性。
2.2.2 方案落地
上文詳細介紹分區維度和方案計劃，此案例簡要描述，重點在業務改造接入落地。
2.2.2.1 選取分區維度
核心業務進行雙活建設的時候，客戶梳理其核心的業務職能可分為終端用戶和政府機關兩部分分流標識，二者均可以為唯一分流標識進行分流。
- 按終端用戶標識分流。以用戶 ID 為分流標識，由於此字段無法變更，保證了分流標識的確定性，實施成本小。
- 按政府機關標識分流。相當於把用戶聚類到政府機關上，需要每月動態更新用戶身上的標籤。由於用戶存在變更政府機關的可能性，導致標籤動態變更，延伸出變更禁寫、數據保障、標籤映射等一系列複雜問題，若存在部分老標籤沒更新成功，最嚴重會導致規則不一致及數據髒寫，風險較高。
因此，最終選擇“終端用戶”為分流標識。
2.2.3 架構演進
圖5：架構演進
基於雙活解決方案，核心業務的部署模型分為如下三層。
2.2.3.1 接入層
- 用戶訪問域名，隨機cname到某單元的子域名，再A記錄到某單元的接入層負載均衡SLB上。
- 接入層提取流量請求中的路由參數，以確定流量的歸屬單元，如果請求中沒有路由參數，則默認歸屬本單元。
- 接入層按照請求域名，或請求域名+URI前綴，以及請求的單元歸屬，將請求路由到正確單元的相應後端業務SLB。
2.2.3.2 應用層
- 服務RPC組件
基於阿里雲 EDAS-HSF 框架和 CSB 雲服務總線基礎能力，多活產品新增多活插件用於處理單元封閉邏輯，支撐政府機構核心分流業務流量單元內自封閉，數據最終一致的業務跨單元請求到中心單元。
- 消息組件
日常場景。保障“終端用戶”流量在單元內發送的消息自閉環在單元內消費，其他流量產生的消息在中心單元被消費，兼容業務原有的消費體系。
切流場景。為保障消息不丟失，基於消息同步、重置位點、多活管控等核心能力使得用戶流量到新單元后，原有單元堆積的消息不丟失，在新單元繼續消費。
2.2.3.3 數據層
數據層設計遵循CAP理論的保AP模型，什麼是 CAP，可以簡單概括為：
- C（Consistency）:數據強一致
- A（Availability）：高可用性
- P（Partition Tolerance）：分區可容忍性
基於當前業務特性，高可用對於業務來說是至關重要的，同時隨著數據量的增長，分區也難以避免，因此我們對於強一致做了讓步，允許數據最終一致性而放棄強一致性。
在雙活場景中，各個單元按照指定的規則承擔不同比例的流量寫入和讀取，同時中心會通過 dts 同步部分數據到各個單元，使得單元具備快速的業務恢復能力，當某個單元出現任何異常不可用場景時，業務流量隨時可以切換到其餘冗餘當前單元數據的正常單元，保障了業務可持續性和穩定性。
2.3 改造成本
方案實施期間，客戶的改造成本集中在數據平面的代碼依賴及流量染色、管控平面的雙活資源接入管理上，概述如下圖。
圖6：客戶改造成本簡要介紹
3. 後記
本文案例中描述的異地多活產品-MSHA，2019 年基於阿里集團異地多活體系孵化而出，2020年先後在國家某政府機構、某頭部運營商新客服等客戶生產落地，混合雲及公有云產品均對外商業化中，有容災高可用相關訴求的客戶歡迎諮詢和試用。
我們是阿里雲智能全球技術服務-SRE團隊，我們致力成為一個以技術為基礎、面向服務、保障業務系統高可用的工程師團隊；提供專業、體系化的SRE服務，幫助廣大客戶更好地使用雲、基於雲構建更加穩定可靠的業務系統，提升業務穩定性。我們期望能夠分享更多幫助企業客戶上雲、用好雲，讓客戶雲上業務運行更加穩定可靠的技術，您可用釘釘掃描下方二維碼，加入阿里雲SRE技術學院釘釘圈子，和更多雲上人交流關於雲平臺的那些事。
