【内含幹貨PPT下載下傳】DTCC 2020 | 阿裡雲張鑫：阿裡雲雲原生異地多活解決方案

摘要：異地多活，顧名思義就是分布在異地多個站點同時對外提供服務，與傳統災備最主要的差別是“多活”裡所有站點都是同時在對外提供服務的。在業務不斷複雜化和容災要求不斷嚴格化的今天，如何實作雲原生的異地多活解決方案，成為了中大型企業不得不面對的挑戰。在第十一屆中國資料庫技術大會（DTCC2020）上，阿裡雲進階資料庫專家張鑫就為大家分享了阿裡雲雲原生異地多活解決方案。

本文内容根據演講錄音及PPT整理而成。

嘉賓介紹：

張鑫（花名：六金），阿裡雲進階資料庫專家，之前主要作為DBA支援阿裡巴巴内部包括交易、廣告等在内的核心系統，近兩年轉戰專有雲市場，面向大型政企客戶提供資料庫解決方案。

本次分享将主要分為三個方面：

容災架構分析
阿裡雲異地多活解決方案
異地多活客戶案例

一、容災架構分析

容災必要性

異地多活本身是從容災出發的，是以首先介紹一下容災的必要性。生産系統可能會遇到三類故障，第一個是主機級故障，如單點負載過高、資料損壞等；第二類是機房級故障，如供電故障、機房網絡故障等；第三類是地域級故障，如自然災害等。對于上述三類故障而言，顯然是地域級故障影響面最大，但發生機率最低，但對于主機級故障而言，卻并不一定發生機率低且影響面小。阿裡巴巴對于自身多年來的故障類型做了梳理，發現随着現在業務系統複雜度的增加，單點故障也可能會造成全局影響，而且當複雜度達到一定程度時，如果發生這種單點故障，排查和恢複都會非常困難，是以容災能力成為了企業資訊化建設的必選項。

容災行業分析

從行業分析來看，容災的市場還是比較可觀的。根據權威報告預測：在2020年全球容災市場佔有率将達到115.9億美元，并且客戶群體非常廣泛，比如政府、金融、能源、網際網路、通信等，基本上隻要有資訊化系統就有容災需求。阿裡雲目前擁有十萬家企業使用者和四十萬個資料庫執行個體，這些都需要容災能力保障。而在國家層面，也具有嚴格的合規要求，尤其是現在大型的政企客戶都需參照《資訊系統容災恢複規範》GB/T 20988進行容災建設。

容災架構演進

容災架構的演進主要分成幾個階段。同城容災最為簡單，即在同一個地域内有一個IDC并部署了業務，容災時再部署一個機房備份系統和資料庫，在中間實作異步或者同步的資料同步，業務流量集中在一邊，另外一邊隻做災備。後來逐漸演進出了同城雙活，其借用了同城内兩個資料中心地理距離比較近，網絡延遲較短的優勢，可以将業務部署到兩端，因為實體距離較短，延遲等問題都可以接受。再往後就是異地雙活，即兩點三中心以及其衍生出的兩地四中心等，主要就是在同城雙活的基礎之上再增加一個災備中心，這個災備中心常态下是不接收流量的，隻有發生地域級故障時才會切換。

傳統的容災方案

重新梳理一下傳統的容災方案，對于同城容災或者同城雙活而言，優勢在于部署簡單，并且接入成本非常低；缺點在于僅提供同城保護，在GB/T 20988中隻能達到1級能力，是以對于大型客戶而言，無法選擇該方案。對于異地冷備而言，優勢同樣在于部署簡單，對業務侵入比較少，并且異地部署的災備能力相對而言會高一些，能夠達到2到5級；缺點在于冷備單元備援成本較高，造成一定的資源浪費，此外因為災備單元常年不接流量，是以真正發生故障的時候切換是否可用是一個未知數。對于兩地三中心而言，其實就是同城雙活和異地冷備兩種方案的結合，其優勢就是上述兩個方案的優勢，缺點則是冷備中心成本浪費和地域級故障發生時不敢進行切換。

二、阿裡雲異地多活解決方案

阿裡雲異地多活架構

如上圖所示的是阿裡雲異地多活整體架構。實際上，異地多活的本質是通過對業務做自頂向下的流量隔離來實作的。阿裡雲将整個異地多活架構分為三層，第一層是接入層，實作異地雙活首先需要為業務制定一個分流政策，如按照地域或使用者次元配置設定流量，一旦定義好分流政策，即可在接入層實作流量拆分，屬于本單元的流量可以繼續向下透傳執行，如果不屬于則會将其轉入正确的單元。第二層是服務層，就是對外提供服務的業務系統，針對于提供能力的不同劃分為了單元化服務、中心化服務和普通服務三種類型。第三層是資料層，這一層所需要解決的是資料庫所需要具備的雙向跨域同步能力、防循環能力，并且需要保障切流時的資料品質。

阿裡雲針對OLTP和OLAP兩種業務場景對于多活架構方案進行了細化，接下來逐個介紹。

OLTP業務多活架構

針對于OLTP業務，阿裡雲提供了一套相應的多活架構，其中包含了幾個關鍵要素。第一，多活配置，主要通過MSHA進行一站式多活配置，其負責制定流量劃分政策、決定哪些資料庫需要進行多活。第二，多活流量控制，主要根據既定規則通過MSFE進行分流，其負責流量識别、流量分發以及流量校正。第三，多活資料同步，主要是通過DTS實作，DTS本身是資料同步工具，其針對多活場景增加了很多新功能，如防循環、網絡優化和切流關聯等。第四，多活容災切換，也是通過MSHA實作，主要負責将規格下推到各層，并對多活切換之前的狀态進行全局檢查。第五，多活場景運維，通過DMS實作，多活場景下實作DDL變更和資料運維存在雙寫問題，并存在同步延遲的可能，是以執行DDL和DML變更的政策是不同的，DMS針對于多活場景進行了能力适配。

OLAP業務多活架構

OLAP業務多活架構與OLTP差別不大，要素也基本一樣，唯一不同在于在OLTP業務多活架構中在底層實作了雙向的資料同步，在OLAP業務多活架構中，則不建議做這樣的工作。主要有兩個原因，其一，跨地域資料同步的帶寬成本非常高，如果OLTP已經将資料同步了一份，那麼盡量選擇在雲内同步，而不是OLAP同步；其次，還需要保證資料一緻性，在OLTP上同步了一次，如果在OLAP上還需要同步一次，那麼保證資料一緻性就會比較困難。是以，阿裡雲建議不在OLAP上做資料同步，而應該全部在OLTP上做，并且在雲内可以實作資料同步能力的補齊。

雙活典型架構：雙Region四AZ

上圖所示的是雙活典型架構，分為兩個Region，每個Region裡面各有兩個AZ，首先具備AZ級别的容災能力，如果真的發生了地域級故障，再将Region級别的容災能力用起來。在這個架構下，MSFE以及具體業務系統等是跨AZ部署的，在雲内具備AZ級高可用。資料庫在AZ1和AZ2、AZ3和AZ4可以進行主備部署，底層通過DTS實作雙向同步。資料是四份副本備援，業務備援達到200%，每個AZ備援到達50%，但真正承接流量時可實作每個AZ隻有25%，業務可以自行調配。對于計劃外的切換而言，可以達到分鐘級RTO。

多活中不同的服務類型

前面提到服務層分為三種服務類型，第一種是單元化服務，這是在多活架構下主要面向的服務類型，比如淘寶買家的資訊修改就是典型的單元化服務，其根據買家的使用者ID進行流量分流，在這個次元下，可以實作單元内封閉調用，不依賴于對端資料，而底層的資料同步隻是在資料切換時確定對端資料是完整的，能夠将資料補齊的，這樣切換之後能夠讓業務直接運作。第二種是中心化服務，主要面向全局配置或者業務具有強中心讀寫要求的場景，如庫存扣減，不允許在多個地方同時扣減同個庫存，這種場景一定會通路中心資料庫，底層通過單向同步來同步資料，這樣的服務提供的并不是多活能力，而是容災能力。第三種是普通服務，所針對的是如果業務按照某一個次元進行了流量劃分，那麼一些耦合的邊緣服務可能無法按照相同次元進行劃分，這類業務可能會選擇普通服務，比如淘寶交易按照買家ID進行劃分，那麼賣家就無法按照這一次元進行劃分。普通服務能夠容忍同步延遲，也就是最終一緻，但是無法接受通路延遲，是以主要面向讀服務，不建議寫場景使用。

跨雲資料同步

上述三種服務類型在底層的資料同步方式不同，是以給出了兩種跨雲資料同步方式。第一種是COPY類型的資料同步方式，主要面向中心化服務和普通服務，資料是單向同步的，單元隻可讀不可寫，同步任務配置通過白名單+DDL放行方式實作。第二種是UNIT類型的資料同步方式，主要面向單元化服務和普通服務，資料是雙向同步的，各單元均可讀寫，此時就需要通過事務表等解決防循環問題，并且通過全局Sequence避免沖突。

防循環&Sequence

阿裡雲POLARDB和RDS資料庫等針對于防循環和Sequence兩個能力進行了實作。在防循環部分，主要提供了兩種方式，第一種是事務表方式，也就是業務在寫入資料庫的時候，即事務送出完成，生成Binlog，Binlog被DTS拿走并解析完成後會發現向目标單元DB寫入的時候會在事務表裡面産生一個自定義記錄，這樣一來在單元裡面落地的事務實際上除了原始業務邏輯之外還會多一個小Event。通過目标端的DTS解析之後就會發現Binlog裡面還多了一個事務操作，就會知道這個操作是來自于DTS的，而不是來自于業務系統的，是以可以将該操作過濾掉，進而放置資料循環。第二種是通過THREAD_ID的方式，這是AliSQL核心定制的優化功能，将原生MySQL核心的THREAD_ID從8位元組改到了5位元組，是以業務生成連接配接隻能是0x00000到0xFFFFF之間，而高位則留給DTS連接配接使用，這樣中心DB就能夠差別兩類連接配接，Binlog會記錄所有的THREAD_ID，是以DTS也能夠很清晰地解析出來操作來自于業務還是DTS，如果來自業務就同步過去，如果來自DTS就中斷掉，進而達到防循環的功能。第一種方式對業務具有一定的侵入性，第二種則是完全原生的能力，對使用者或者核心沒有太大影響。

對于Sequence功能而言，其實就是在兩邊同時寫入資料，需要保證資料不能沖突。是以，阿裡雲針對于POLARDB-X做了全局唯一Sequence的能力，在原生的DDL上面增加了辨別去控制目前單元個數以及每個單元的Index。基于這種方式建立出來的表，以内步長為10萬，單元數為2舉例，産生結果如上圖所示，進而達到全局Sequence的能力。

多活場景資料保護

在多活場景下，和原生最大的差別就是不需要關注可用性，但是卻多了資料品質的問題，該問題在單資料中心場景下可能不容易發生，但是在多活場景下因為業務需要雙寫，是以容易出現資料品質的沖突問題。歸根結底，所有的資料品質問題都是由于資料雙寫導緻的，是以需要針對于這種場景制定一定的保護措施。阿裡雲制定了三個次元的單元保護措施，第一個是日常态，針對接入層、應用層和資料層提供相應的方法多寫操作的多活分流規則進行路由邏輯校驗，如果非本單元流量，則在接入層和應用層将流量轉走，但如果在資料層，則直接阻塞掉。第二個是變更态，主要針對資料運維變更，比如批量資料訂正，阿裡雲提供了事前檢查和事後補充的能力，在DMS上面針對于多活場景下的資料變更任務提前檢查變更情況，如果同步延遲很大則會被阻塞掉，降低了資料雙寫的機率，同時在變更前和變更後通過檢查保持資料的一緻。第三個是切流态，是在資料多活切流過程中做的保護政策，包括了絕對禁寫、延遲禁寫、前鏡像比對同步以及延遲檢查等功能。

多活切流流程

在多活切流時，首先會打開前鏡像比對功能。一般認為，在多活場景下業務寫入的資料比同步過來的資料更重要，是以需要保證業務寫入的資料不被同步的資料覆寫掉，是以如果切流過程中，資料同步有延遲，為了不覆寫掉業務資料，則需要将Binlog裡面前鏡像拿出來拼到SQL裡面去執行。前鏡像比對功能開啟之後會将新的流量分發規則在各層進行下發，在規則下發完成之後會開啟絕對禁寫的動作，在此過程中，所有參與切流的使用者流量是無法執行的。在禁寫過程中首先需要判斷三層規則是否全部收斂成功，其次還需要判斷每層内各個節點的規則是否收斂成功，最終目标是讓所有伺服器上的規則保持一緻，這樣才能保證不出現雙寫。上述條件滿足之後，解除絕對禁寫，開啟延遲禁寫，這一點可由使用者配置。當資料同步完成之後，解除禁寫和前鏡像比對，切流過程至此完成。

異地多活價值總結

簡單總結下異地多活的價值。首先，多活本身是做容災的，但是現在來看異地多活已經不像是傳統容災那樣放置一個災備單元了。現在業務即容災，業務系統和容災系統緊密地連接配接到了一起。其次，業務連續性有了保障，為業務提供了高可用能力。第三，為業務的高速發展提供了支撐，在多活場景下劃分了很多原子單元，可以根據原子單元合理配比相關資源，達到最優效果，最終具有跨地域的水準擴充能力。第四，流量有效隔離，基于阿裡雲的異地多活解決方案可以非常靈活地調配流量，可以按照不同次元設定規格，也可以按照不同的權重配比設定，實作流量大小的靈活調配，并可實作在最小單元内進行風險可控的技術試驗。第五，降本增效，傳統容災方案無法突破200%的備援成本問題，而通過三活、四活的方案可以實作備援成本小于200%。

使用者自行實施異地多活的難點

使用者自行實施異地多活所需面對很多難點，如流量管理難度高、資料同步政策複雜、容災切換資料品質保障難，以及多資料中心統一管控難度大等，這也是阿裡巴巴将異地多活能力沉澱為産品級解決方案的推動力。基于阿裡雲的異地多活方案，使用者隻需要關系如何對流量進行分割即可。

阿裡雲雲原生方案優勢

目前能夠實作産品級異地多活能力的廠商極少，阿裡雲經過8年的積累和沉澱，在異地多活的雲原生方案上具有諸多優勢。

三、異地多活客戶案例

客戶案例-某稅務核心系統

某稅務核心系統的異地多活方案也是按照三層架構實作的，在接入層，支援按照兩個次元流量拆分，即省份和自然人檔案号。在服務層利用CSB産品實作普通服務的跨雲調用。在資料層，針對不同服務類型實施不同容災級别的資料同步。最終實作了兩個次元的多活，秒級切換能力，達到了國标6級效果，因為基于兩單元接流，是以在成本上具有優勢，并且具有灰階放量能力。

客戶案例-某營運商客服系統

某營運商客服系統實作了按省份分流能力，即按照DNS的地域分流接入南北兩個中心，接入層按照路由規則進行判斷和糾錯，在業務層對于客戶原有系統進行了适配改造，實作了雙中心的服務同步。在資料層，則通過POLARDB-X和DTS實作雙向資料同步。最終使得該營運商客服系統的多個業務按地域多活分流，在多次容災演練中，可以完成秒級切換，并保障了資料0丢失。此外，由于常态由兩個單元承載業務流量，是以成本也有所降低。

點選這裡下載下傳本場演講PPT