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
相關閱讀
【內含干貨PPT下載】DTCC 2020 | 阿里云葉正盛：數據庫2025
https://developer.aliyun.com/article/780725
【內含干貨PPT下載】DTCC 2020 | 阿里云趙殿奎：PolarDB的Oracle平滑遷移之路
https://developer.aliyun.com/article/780749
【內含干貨PPT下載】DTCC 2020 | 阿里云朱潔：NoSQL最新技術發展趨勢
https://developer.aliyun.com/article/780746
【內含干貨PPT下載】DTCC 2020 | 阿里云王濤：阿里巴巴電商數據庫上云實踐
https://developer.aliyun.com/article/781001
DTCC 2020 | 阿里云梁高中：DAS之基于Workload的全局自動優化實踐
https://developer.aliyun.com/article/781036
【內含干貨PPT下載】DTCC 2020 | 阿里云程實：云原生時代的數據庫管理
https://developer.aliyun.com/article/780992
【內含干貨PPT下載】DTCC 2020 | 阿里云吉劍南：在線分析進入Fast Data時代的關鍵技術解讀
https://developer.aliyun.com/article/780747
原文鏈接：https://developer.aliyun.com/article/781031?
版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。總結
以上是生活随笔為你收集整理的DTCC 2020 | 阿里云张鑫：阿里云云原生异地多活解决方案的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： DTCC 2020 | 阿里云程实：云原
- 下一篇： 【最全干货下载】| DTCC 2020：