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團隊技術專家，2014年加入阿裡，多年DevOps及系統高可用架構經驗，深度參與了阿裡巴巴的DevOps轉型與異地多活容災架構的發展，目前主要負責阿裡服務度量體系以及容災商業化。
我們是阿裡雲智能全球技術服務-SRE團隊，我們緻力成為一個以技術為基礎、面向服務、保障業務系統高可用的工程師團隊；提供專業、體系化的SRE服務，幫助廣大客戶更好地使用雲、基于雲建構更加穩定可靠的業務系統，提升業務穩定性。我們期望能夠分享更多幫助企業客戶上雲、用好雲，讓客戶雲上業務運作更加穩定可靠的技術，您可用釘釘掃描下方二維碼，加入阿裡雲SRE技術學院釘釘圈子，和更多雲上人交流關于雲平台的那些事。