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技術學院釘釘圈子，和更多雲上人交流關于雲平台的那些事。