本文始發於：雲棲社區
時間：2020-06-02
原文鏈接：https://yq.aliyun.com/articles/763323
1 什麼是異地多活？
異地多活，英文Multi-Site High Availability，顧名思義就是分佈在異地多個站點同時對外提供服務。與傳統災備最主要的區別是“多活”裡所有站點都是同時在對外提供服務的，具體有以下幾點不同：
- 傳統的災備中心平時不提供服務，關鍵時刻無法確定切換到災備中心是否可以切換成功。
- 傳統的災備中心平時不提供服務，整個災備資源會處於浪費狀態，成本比較高。
- 傳統的災備中心平時不提供服務，所以平時提供服務的數據中心還停留在單地域，當業務體量大到一定程度時，這種模式無法解決單地域資源瓶頸的問題。
因為通過傳統的災備手段無法解決上述問題，阿里巴巴經過多年研究，成功在2013年的雙十一實現了“絲般柔順”的用戶體驗後，“異地多活”這項基礎技術首次在業界亮相。
2 “多活”和“雙活”有什麼區別？
單從字面上看，“多活”和“雙活”的區別僅是同時提供服務的站點數量的區別。一個是“多個”站點同時提供服務，一個是“兩個”站點同時提供服務。但即使都是“雙活”，也會因為前面加了“同城”還是“異地”而有著本質的區別。如果是“異地雙活”，就是和“異地多活”僅存在站點數量上的差別。但如果是同城雙活，在阿里內部，採用的是不同的技術。阿里的同城雙活，整個模式應用層是雙活的，兩邊的業務都有，用戶訪問過去都會處理請求，一旦進入某個數據中心，流量交付優先在本數據中心封裝。但存儲層都是主備或者本身的高可用模式的，主備模式即主在A機房，備在B機房，不會同時用，嚴格意義上來講，這是偽雙活，因為數據不是真正意義的雙活。但即使是這樣的雙活，阿里巴巴內部也是經歷了很長一段時間的摸索才實現，雙活其實也是一樣的，如果真正做到就意味著同城任何一個機房出問題都要可以高效可靠地切換到另外一個機房，如果沒有經過很多次真正切換的話，沒有人敢說是一定能成功的。這裡不只包含數據庫主備的問題，還涉及到應用的業務依賴梳理、眾多中間件層面的服務路由、調用和集群冗餘的問題。
一句話總結，就是“異地雙活”和“異地多活”僅是數據中心數量的差別，但“同城雙活”則是完全不同的技術。採用哪一種，完全取決自己的多個數據分佈在同城還是異地，以及以後的業務擴展方向問題。
3 多活的設計誤區
3.1 實時異地多活
異地多活本質上是通過異地的數據冗餘，來保證在極端異常的情況下業務也能夠正常提供給用戶，因此數據同步是異地多活設計方案的核心。但由於目前的技術還無法突破數據傳輸與物理距離解耦合，也就是說兩個異地數據中心之間一定存在一定程度的延時，如果業務對實時性要求極高，那就無法實現異地多活。
3.2 所有用戶異地多活
同樣是由於物理距離造成的數據傳輸的延遲，數據只能做到最終一致，在一些極端情況下，部分用戶的數據無法及時同步到新切換到的中心，這時，這部分用戶的業務會受到一定程度的影響。
3.3 所有業務異地多活
異地多活效果看起來很誘人，但如果不假思索貪大求全地要求所有業務都實現異地多活的話，很可能什麼也做不成。原因是異地多活是有成本的，根據業務類型有不太一樣的開發和運維成本，但如果全做加之對業務梳理不到位，會造成整個工期不可控，即使完成，上線後的效果也需多重驗證。阿里第一次做異地多活也只是選取了與“買家”下訂單相關的電商業務做的多活，然後根據業務需求，逐漸有新業務改造上線，到了今天的規模。
3.4 通用的異地多活
異地多活的實現根據業務類型的不同也有一定程度的差異，為了讓業務儘量少的做改動，儘可能把這種能力都封裝在中間件和基礎工具中，但即便如此，也無法保證這些能覆蓋所有的業務類型。遇到特殊的業務類型或者用戶自己實現的基礎組件，仍然需要根據具體的業務特點制定新的多活方案。
4 異地多活的適用場景
異地多活本質上就是通過自上而下的全域流量隔離來解決數據同步延時無法突破物理限制的問題，但異地多活也不是銀彈，且不同的場景來做異地多活的成本也不一樣，不一定適用於所有場景。下面把用戶的業務按數據維度分成三種類型來看異地多活的適用場景：
4.1 讀多寫少型業務
- 業務應用場景：典型的業務場景就是資訊、導購類的服務，比如商品瀏覽、新聞資訊...
- 數據特點：典型的數據特點就是讀多寫少，用戶以瀏覽為主，核心業務場景只讀，單元裡部署的都是隻讀業務
- 多活接入成本：接入成本低，只需要用戶在請求裡標記上分流的標識即可
4.2 流水單據型業務
- 業務應用場景：典型的業務場景就是電商交易、帳單流水類服務，比如用戶的訂單、用戶的通話記錄...
- 數據特點：典型的數據特點就是數據可按照一定的維度進行分片且可以接受最終一致
- 多活接入成本：接入成本略高，用戶需要梳理業務，理出單元內部署的核心業務及其數據，對於單元依賴且無法拆分的業務採用讀寫分離，然後按照多活接入規範重點對服務層及數據層進行相應改造即可
4.3 狀態依賴型業務
- 業務應用場景：典型的業務場景就是銀行賬務，比如A、B在某銀行均有帳戶，A、B數據分片位於不同的數據中心，A和B之間會有轉賬行為
- 數據特點：典型的數據特點就是數據有狀態依賴且無法最終一致，數據還存在跨數據中心的交互
- 多活接入成本：接入成本高
5 異地多活的設計原則
意識到上面這些思維誤區後，我們重新思考異地多活，確定一些設計原則：
- 選取分區維度：選擇一個數據維度來做數據切片，進而實現業務可以分開部署在不同的數據中心
- 確定改造範圍：選擇與上次選取的數據維度相關的業務範圍來做多活
- 單元封閉：儘量讓調用發生在本單元，儘量避免跨數據中心的調用，一方面為了用戶體驗，本地調用RT更短，另一方面為了穩定性，防止一個數據中心出了問題，其它數據中心受影響
- 無法接受最終一致的數據要進行單點寫：對於一些實時性要求極高，無法接受最終一致的數據只能進行單點寫
6 異地多活的價值
雖然最初創造異地多活是為了解決容量和容災的問題，但異地多活發展到今天其價值已遠不止這些了，更大的價值是為阿里新技術演進提供試驗田，甚至可以驅動商業上的一些玩法。
6.1 解決了容災的問題，提升了業務的連續性
現實運行過程中，容災可不只是地震、挖光纖這些低概率事件，同樣還有人為原因等高概率的事件，這些通過異地多活均可以解決。以下羅列一些常見的場景：
- 人為操作失誤：常見的有配置錯誤、應用發佈失敗等等
- 硬件故障：常見的有網絡設備出故障，導致機房或集群內多臺服務器受影響
- 網絡攻擊：DDoS等網絡攻擊
- 斷網/斷電：支付寶光纜被挖斷
- 自然災害：青雲雷擊導致機房電力故障
有了異地多活，以上這些場景出現時，秉承“先恢復，再定位”的原則，可以有效提升業務的連續性。某互聯網公司通過自己的實踐驗證取得了非常不錯的成績，可做到讓“業務恢復時間”和“故障恢復時間”解耦合。
6.2 解決了容量異地擴展的問題
有了異地多活，當機房或者地域容量遇到限制的時候，可以在其它機房或者其它地域快速擴建業務單元，實現快速水平擴容的目的。
圖1：業務多單元化
6.3 為新技術演進提供了試驗田
異地多活本質上是提供了自上而下的一種流量隔離能力，基於這種能力，我們完全可以做到單元之間的隔離，進而完成一個技術上需要的場景：
- 基礎設施的升級
- 大的技術架構升級
- 新技術驗證
阿里巴巴每年進行大促的技術大步演進但又風險可控，完全就是基於這種能力來實現的，每年有多個重大的技術演進，演進過程中難免遇到問題，但卻從未造成大的影響。
6.4 驅動商業上產品創新玩法
同樣基於這種流量隔離能力，商業上也可以產生一些新的玩法：
- 把VIP和普通用戶分開到不同的集群
- 把真實用戶和爬蟲分開
- 新舊機器分成不同的物理集群，做流量隔離，進而做分級別的服務
7 異地多活（MSHA）產品介紹
7.1 產品形態
圖2：多活管控平臺架構圖
異地多活是一個架構屬性比較重的產品，其整個產品由管控+組件組成，同時需要和其它產品結合來完成整個異地多活。一個完整的異地多活應該包括如下組成部分：
A. 控制檯
控制檯提供多活配置及運維閉環的功能：
接入層、應用層、數據層的各層接入多活的初始化操作和日常運維。
發生災難場景的切流操作。
多活場景下的數據監控。
多活切分規則的展示及查看。
B. 接入層
目前這層主要是一個基於Tengine的多活組件，我們稱之為MSFE。
MSFE需要多單元部署，它能承接所有的單元前端流量，並按照路由規則路由到正確單元的後端應用。多活控制檯提供MSFE集群新建、擴容、縮容等常規運維能力。
C. 應用層
應用層主要包括基於EDAS的RPC服務組件和基於MQ的消息隊列組件：
EDAS：EDAS的新增多活參數及處理邏輯支撐多活RPC能力，接入時業務需聲明RPC-Provider的多活屬性及升級EDAS容器版本。
CSB：通過級聯CSB組件實現單元間的RPC服務互通，並在MSHA管控臺進行發佈操作。
ONS：基於ONS的同步能力和多活處理邏輯支持多活MQ能力，接入時需要在多活管控開啟Producer和Consumer的單元屬性及同步鏈路配置。
D. 數據層
目前這層主要是包括一個客戶端和一個基於DRDS的多活組件，兩者共同配合完成對多活數據層的管控：
多活數據Driver：這是一個基於JDBC標準Driver進行二次封裝的Driver，主要是用於傳遞一些標準的元信息給DRDS，同時封裝了一些本地處理的多活邏輯。
DRDS多活組件：該組件需要安裝在DRDS的Server端，主要是與多活的Drvier共同配合完成異地多活的邏輯處理。
除了上述多活數據層的組件外，要想完成異地多活，還需要依賴數據同步相關的雲產品：
DTS：基於DTS的單/雙向同步能力，與多活管控共同配合完成異地多活的數據同步控制邏輯處理。
7.2 產品特點
A. 一站式多活管控
一站式管控主要體現在下述兩個方面：
- 橫向從單元上線，到單元日常（監控、運維、切流），再到單元下線的全生命週期管理。
- 縱向從單元流量入口，到服務化調用，異步化消息，再到數據入庫的全方位管控。
B. 單元化類型自由擴展
單元化類型routeType，描述的是業務類型。以電商場景為例，有買家業務、商家業務等。淘寶的交易單元化是以買家業務做的單元化，分流規則是買家id，也就是說買家的流量能分流到各個單元，而商家卻沒有多活。單元化類型自由擴展，能同時支持買家與商家業務的多活，賦能用戶，使用戶在業務擴展上擁有更大的靈活性。
C. 運維全自動化
- 運維全自動化，主要體現在接入層、服務層、數據層的變更操作自動化以及接入層集群運維的全自動化。
- 在接入層集群運維上，主要包含創建集群、擴縮容服務器、擴縮容SLB等，提供一鍵式運維變更方案，完全無需登錄服務器。
D. 流量調度高可用
- 由於流量分發路由規則在各個機器上，因此其會受如下因素影響：
網絡分發開銷。
配置中心性能。
多個有序規則下發，亂序會導致流量執行邏輯錯亂。
- MSHA與上述影響點解耦：
僅依賴ntp進行實際規則執行，弱化了網絡和配置中心的時效性依賴，同時存在對ntp各機器不一致的容錯時間，保證在切流期間，切流用戶數據強一致的前提下規則執行的最終一致。
多個有序規則合併為一個規則，去除對有序的依賴。
當ntp災難不可用時，啟用容災及時規則下發狀態，即不依賴ntp，此時依賴配置中心下發後，禁寫保切流用戶強一致，而後生效。
8 服務案例
在阿里雲異地多活的服務項目中，較為典型的有餓了麼與國家某部委的專有云項目。其中餓了麼的業務場景、架構與阿里均有較大差異，在阿里的支持下用三個月走完阿里三年的多活改造之路，服務可拓展至多個機房，並且能夠應對整個機房級別的故障。國家某部委的專有云平臺自上線運行以來註冊用戶過億，平日在線用戶數超千萬，日均交易量過千萬，業務系統穩定性至關重要。2019年客戶在廣東、北京兩個中心分別搭建混合雲平臺，整體解決方案實現兩個中心聯機業務“一寫雙讀”，共同對外提供服務，大數據離線業務採用“異地容災”技術進行業務連續性支撐，整個解決方案藉助大量阿里雲先進的技術及產品，為項目提供了業務雙活和大數據容災兩個重要的容災能力。
作者：謝吉寶
阿里雲智能GTS-SRE團隊高級技術專家
阿里雲智能GTS-SRE團隊高級技術專家，阿里雲智能架構組成員，2010年加入阿里，10餘年技術研發和系統架構經驗，見證了阿里巴巴的高可用產品體系從1.0到3.0的整個發展歷程，目前主要負責阿里容災和高可用體系的建設及商業化。
作者：鍾熙耿
阿里雲智能GTS-SRE團隊技術專家
阿里雲智能GTS-SRE團隊技術專家，2017年加入阿里，專注於容災高可用領域探索，持續推動集團多活容災（同城/異地）演進，目前主要負責容災商業化體系和集團容災架構工作。
作者：繆銳
阿里雲智能GTS-SRE團隊技術專家
阿里雲智能GTS-SRE團隊技術專家，2014年加入阿里，多年DevOps及系統高可用架構經驗，深度參與了阿里巴巴的DevOps轉型與異地多活容災架構的發展，目前主要負責阿里服務度量體系以及容災商業化。
我們是阿里雲智能全球技術服務-SRE團隊，我們致力成為一個以技術為基礎、面向服務、保障業務系統高可用的工程師團隊；提供專業、體系化的SRE服務，幫助廣大客戶更好地使用雲、基於雲構建更加穩定可靠的業務系統，提升業務穩定性。我們期望能夠分享更多幫助企業客戶上雲、用好雲，讓客戶雲上業務運行更加穩定可靠的技術，您可用釘釘掃描下方二維碼，加入阿里雲SRE技術學院釘釘圈子，和更多雲上人交流關於雲平臺的那些事。