接收程序員的技術早餐
作者｜張小虎
天翼電子商務有限公司（簡稱“甜橙金融”）是中國電信的全資子公司，2011 年 3 月成立於北京，現賬戶用戶已突破 1.5 億，成為國內最大的民生繳費平臺、移動支付領域 5 強、互聯網金融領域 16 強。甜橙金融技術團隊在經歷 2016 年成功“上雲”後，便開始著手建設新華南機房。新華南機房的設計目標是與當前的兩個華東機房一起，形成符合甜橙金融業務快速發展需要兼顧迎檢要求的“兩地三中心”異地雙活架構。
本文系統介紹了我們在業務需求驅動下的數據中心建設的演進過程，以及我們在此基礎上進行的 “ 異地雙活 ” 探索和驗證，其中“ 異地雙活 ”主要是基於數據訪問層（ Data Access Layer，DAL ）和數據層庫（ Database ）兩個方面展開介紹， 希望在雙活建設上能給大家帶來新的思路。
數據中心建設演進
圖 1. 甜橙金融 IDC 機房架構演進
1. 本地數據中心階段（2011 年 -2013 年）
最初的機房架構比較單一。華東、華南兩地各有一個本地機房，且各本地機房主要負責華東、華南兩個研發中心自身的發展需求。兩個本地機房之間通過 CN2 和 DCN 直連。
圖 2. 甜橙金融本地數據中心架構
在發展初期，這樣的 IDC 機房架構加上兩地研發中心，使得我們的業務在短時間內得以快速開發迭代、部署落地，一定程度上滿足了當時的業務需求。
架構痛點：2013 年後期，在經歷了幾次大型促銷活動引發的一系列故障後，本地機房架構的短板逐漸浮現，如業務沒有跨機房冗餘，在出現緊急事件時無法繼續提供必要服務等。因此，經過內部討論評估，我們初步制定了 IDC 機房架構的演進策略，開始著手建設同城機房。
2. 同城冷備階段（2014 年 -2015 年）
這一階段我們在華東地區規劃並建設了兩個同城機房，兩個華東數據中心均可以為華東研發中心提供業務相關服務。之所以依舊定義為同城冷備主要還是基於數據層面，因為從數據層面上說這種機房架構仍屬於冷備架構。雖然兩個數據中心的應用服務都可以接受並處理用戶請求，但用戶對數據的請求則同一時間只在固定的數據中心中讀寫。由於同城機房的網絡延時基本可以忽略，兩個數據中心則通過數據庫層面進行異步數據同步。
圖 3. 甜橙金融同城冷備數據中心架構
同城冷備架構讓我們的個人賬戶等核心業務有了必要的業務容災條件，同時由於兩個數據中心都可以處理正常業務請求，所以數據中心整體的資源處理能力也成倍擴充。
架構痛點：添加新的數據中心除了帶來 IDC、線路、維護成本上的增加外，並沒有解決我們華南數據中心業務無冗餘的困境，且由於其中一個數據中心的數據是冷備數據，當出現嚴重故障時，冷備數據是否可以直接拉起使用也因業務差異而定。
隨著甜橙金融業務的發展，我們認為華東數據中心同城冷備架構已無法滿足我們業務發展的需求，但是受限於當時的基礎技術儲備能力，因此我們計劃進行全業務改造，逐步滿足建立異地雙活機房條件。
3. 同地區冷備階段（2016 年 10 月 -2017 年 4 月）
為了逐步建立異地雙活機房架構，我們在 2015 年底便首先啟動全業務的上雲改造。到 2016 年 10 月底，在經過 1 年多的業務改造及數據中心基礎建設後，甜橙金融將原有的兩個華東同城百公里內數據中心改造為兩個同地區四百公里內數據中心。這樣做的目的是為了進一步驗證同城冷備架構在異地是否繼續可行，並且對遠距離數據同步中出現的問題進行調研。
兩個同地區數據中心的地位和之前也有區別：在保持原同城冷備方案的前提下，華東新數據中心定位為主數據中心，主要負責處理甜橙金融核心業務；華東容災數據中心則負責生產數據的異地容災備份。
在這一階段，我們的新華南數據中心也通過調研，加緊建設中。
圖 4. 甜橙金融同地區冷備數據中心架構
4. 異地冷備階段（2017 年 4 月至今）
新華南數據中心建成後，我們開始將同地區數據中心的冷備架構下線，並同期建設為數據容災中心。新的華南數據中心則規劃為可以承載部分公共業務的應用級異地雙活。
在這一階段建設初期，我們繼續沿用已經比較成熟的應用級雙活經驗，將華東、華南兩個數據中心的數據訪問全部集中在華東主數據中心。業務上則針對跨千公里的網絡環境進行相應改造。畢竟在原有的應用設計時，一些業務判斷會強依賴數據返回時延，跨千公里網絡時延一般在 20-50ms 內，這個對某些業務會產生較大影響。
圖 5. 甜橙金融異地冷備數據中心架構
架構痛點：在跨千公里數據中心數據同步方面，由於華南副中心的數據只是冷備數據，所以設計之初我們便定義其數據可用級別為 T+1 日。當然，這樣的設計在數據恢復上存在一定問題，比如華南的副中心由於網絡擁堵導致數據同步延遲較大，這時如果華東主數據中心出現災難性故障，則副中心只能有限接管業務——數據時延最大可能一天。
故障的恢復會採用以下兩種方案：
重新拉起華東主數據中心。
華東數據容災中心恢復增量備份到華南副數據中心。
不管採用哪種方案，這樣的數據恢復時長對於核心業務來說是無法忍受的，這也是我們當前只在公共業務裡採用異地應用級雙活架構的原因。
異地雙活架構面臨的問題
在數據中心建設告一段落後，我們將重點轉移到如何實現真正的異地雙活上來，在實現異地雙活架構時所面臨的問題主要包括以下幾個：
跨千公里網絡時延。
業務改造複雜。
各數據中心數據一致性問題，包括髒數據寫入、數據衝突、是否需要改造全局鍵等。
其中，跨千公里數據異地同步的難度在業內有著廣泛共識，受限於現在市面中的主流關係型數據庫都是基於 CAP 理論做底層設計（注：CAP 理論是指一款數據產品在數據一致性、可用性和分區耐受性三者中只能同時滿足其中任意兩者。），因此數據異地同步就需要對 CAP 理論進行規避。
針對上述的問題，我們制定了兩種類型方案並著手進行方案驗證：
消息分發 & DAL 層改造
數據層改造（MongoDB、TiDB）
異地雙活方案
消息分發 & DAL 層改造
採用消息進行異地數據同步在業內已有很多成功案例。在我們的技術方案裡，首先要做的是將被選定進行異地雙活改造的應用入口逐漸收攏，從多入口（域名）訪問改造為統一的入口路由。這樣，入口級應用 MAPI 應運而生，它上線後將之前相對零散的業務訪問統一起來，這也為後面我們針對 MAPI 做流量分發及控制提供了必要條件。
圖 6. 甜橙金融異地雙活方案之消息分發 & DAL 層改造
MAPI 通過 DNS 解析將入口流量進行多機房分發，業務請求生成的消息會寫入到兩地的機房中。接下來本地機房的消費者會通過 DAL 層將落盤數據分發到相應的數據分片裡，然後通過數據庫自身的複製機制，有延時的將本地數據中心的數據同步一份到異地數據中心。這樣既可保證每個數據中心都會保留一份全量數據，也可以保證以華東主數據中心為主，向華東容災數據中心。
Consumer 和 DAL 的改造是該方案的難點。在實施時，我們根據業務的性質進行了單元化劃分，這也是業內實現雙活架構的常用方案。將不能進行單元化的業務以全局區域存放，而可以單元化處理的業務模塊則放入本地區域。
圖 7. Global Zone 和 Local Zone
數據層改造
如前文所述，面對異地雙活最大的技術難點數據一致性問題，其實主要還是受限於關係型數據及 CAP 原理。因此，通過一些技術手段對 CAP 原理進行規避也能夠達到滿足業務的數據一致性要求。
這裡，我有兩個數據層改造的思路分享給大家：
1. 基於 MongoDB 副本集的異地雙活架構：
MongoDB 是天然提供分片的 NoSQL 數據庫，這樣的天然分片被稱為副本集。副本集的存在為每個 MongoDB 的分片節點提供了相應的高可用。
它在寫入持久性和讀取一致性上提供了更強的處理能力。比如，通過 write concern 來指定寫入副本的數量，無論採用應答式寫入還是非應答式寫入，均可保證跨數據中心的集群發生故障時，總會有相應的副本存在以保證寫安全。另外，MongoDB 是滿足 BASE 理論設計的，因此可以從一定程度上規避 CAP 理論帶來的問題。
圖 8. 基於 MongoDB 副本集的雙活架構
MongoDB 還有一個適合多數據中心部署的特徵是其故障自動 Failover。這一特性對於異地雙活有重要意義，數據庫運維人員可以不用太在意各數據中心的數據庫節點的狀態。我們在進行的方案驗證時，當集群中的節點發生故障或出現網絡中斷，MongoDB 基本可以在 5 秒內完成故障的 Failover 過程，這主要依賴集群對整個副本集的配置，發生故障後可以在剩餘的副本集中選擇一個新的主 shards。
2. 基於分佈式數據庫（NewSQL）的異地雙活架構：
從 Google 的 Spanner & F1 論文放出後，業內對於如何打造一套跨數據中心的強一致性分佈式數據庫的工程實踐方法有了深刻的認識和理解。
在開源數據庫領域，目前有兩個受 Google Spanner & F1 影響並建立發展的分佈式關係數據庫 (NewSQL) 尤其引人矚目。他們分別是來自國內的 PingCAP 團隊做的 TiDB 分佈式關係數據庫項目和美國團隊的 CockroachDB 分佈式關係數據庫項目。這兩個根據 Spanner & F1 體系打造的分佈式關係數據庫 (NewSQL) 目前在全球頂級開源分佈式數據庫領域展開了直接的競爭。
我們在探索多中心雙活數據中心架構演進的時候，考慮到開源社區的穩定及活躍程度，重點調研和關注 TiDB 在多中心架構多活模式中的技術價值和架構探討。TiDB 在數據庫領域屬於最新的第三代分佈式關係數據庫，其具備如下 NewSQL 核心特性：
SQL 支持 （尤其與 MySQL 兼容性，使得其面對業務完全透明）
水平在線彈性擴展
支持分佈式事務
跨數據中心數據強一致性保證
故障自恢復的高可用
應用解耦，沒有業務侵入性
TiDB 整個項目和產品的運作方式以標準的國際開源項目在運營和發展，這點也是我們重點圍繞 TiDB 做探索性研究論證的主要動因，一個健康發展的開源項目能夠使得我們在應用其到比如多中心多活這樣的業務場景中，更有信心和保障。
TiDB 數據庫的主要架構如下：
圖 9.TiDB 架構（圖出自 TiDB 官網）
TiDB Server (分佈式計算集群)：TiDB Server 負責接收 SQL 請求，處理 SQL 相關的邏輯，並通過 PD 找到存儲計算所需數據的 TiKV 地址，與 TiKV 交互獲取數據。
TiKV Server (數據分佈式存儲集群)：TiKV Server 負責存儲數據，從外部看 TiKV 是一個分佈式的提供事務的 Key-Value 存儲引擎。
PD Server (管理集群)：Placement Driver (簡稱 PD) 是整個集群的管理模塊，其主要工作有三個： 一是存儲集群的元信息（某個 Key 存儲在哪個 TiKV 節點）；二是對 TiKV 集群進行調度和負載均衡（如數據的遷移、Raft group leader 的遷移等）；三是分配全局唯一且遞增的事務 ID。
結合我們華東主數據中心、容災數據中心和華南數據的三中心佈局，在異地多活的場景中，我們設計的甜橙金融基於 TiDB 數據庫的雙活架構如下所示：
圖 10. 甜橙金融異地雙活架構
TiDB 分佈式數據庫在多中心多活的部署和運行模式下，依靠其核心調度 PD 對跨 1000 公里以上集群的調度管理。我們在實驗後，總結了以下重要特點：
標籤系統 (Label) : TiDB 內置有一套標籤系統，可以為一套集群的不同節點，按照 Site (數據中心），Rack (同中心內不同機架)，Host (不同物理機節點) 來對應設置標籤信息，從而實現將集群的跨數據中心物理拓撲和集群調度連接起來。
PD 集群調度器，根據對物理拓撲的映射，形成跨數據中心的實際數據和計算調度策略。
TiKV 存儲引擎中的數據管理最小單位是 Region，每一個 Region 都通過 Raft 產生多個強一致性副本，在整個數據存儲空間內，形成多個 Raft Group ( Region 和其副本所組成的同步組) 。同一個 Raft Group 中，會選舉出一個 Leader Region， 來自 TiDB SQL 引擎的物理數據讀寫，都會訪問所有 Raft Group 中的 Leader Region。
PD 集群調度器 根據調度策略，會動態調度 所有的 Leader Region 按照 業務要求在三個中心中分佈。
華東兩個數據中心 (主數據中心及華東容災中心）與華南數據中心的網絡通訊條件理想的情況下，PD 可以將數據分佈中的 Leader Region 動態分佈到三個中心的節點上。每個中心都可以以統一視角訪問和操作數據庫，TiDB 引擎上的 Multi-Raft 複製機制會在不同中心的數據區域進行強一致性複製 ( Raft Log based) 。
華東兩個數據中心 (主數據中心及華東容災中心）與華南數據中心的網絡通訊條件不夠理想的情況下，PD 可以將數據分佈中的 Leader Region 動態分佈到華東的兩個數據中心中，而在異地保留 Follower Region 作為高可用保護。
三個中心內的數據管理單位 Region 都是可以在線的做動態的分佈改變。
每個中心的節點擴容，通過 TiDB 自身的動態在線擴容機制，也可以實現動態水平擴展，擴展後的集群中的數據，會根據 PD 調度的管理，自動在後臺完成數據重平衡工作，對業務連續性不產生影響。
下面就 整個多中心多活的具體可用性實現做一個拆解分析，我們的雙活架構如下圖所示：
圖 11. 基於 TiDB 的異地雙活架構
業務應用接入層高可用設計
業務應用通過 F5 , HAProxy , LVS 之類常規提供 4-7 層的負載均衡設備接入，負載均衡器通過流量接入後，通過流量轉發，直接發往 TiDB 分佈式 SQL 引擎層進行業務計算。接入層的高可用，可以通過常規負載均衡的後向服務探測，完成檢測和流量切換。對業務應用透明。
TiDB 分佈式 SQL 引擎計算層高可用設計
TiDB 分佈式 SQL 引擎為無狀態服務，即任意一個集群節點不保留狀態數據。可以隨時增加節點和減少節點。節點發生故障後，通過前向服務探測和感知，可以自動隔離故障節點，剩餘的 SQL 引擎服務實例可以正常的工作不受影響。對業務透明。
TiKV 分佈式存儲引擎層高可用設計
圖 12.TiDB 底層 Region 設計原理
TiKV 分佈式存儲引擎層也是高可用集群架構，內置多種高可用底層保障機制，最核心的 Raft 機制確保位於每臺服務器上的每個 TiKV 服務實例中都有數據的副本存在，整個 TiKV 集群 如同 RAID 磁盤陣列，每個節點上都有業務數據，同時也有部分的校驗數據 （在 TiDB 中為數據副本）。
默認副本配置為 3 個，低於 50% 的節點故障都可以透明容忍，對業務應用的訪問沒有任何影響。
故障節點被新節點替換或修復後重新上線後，集群調度器會自動建立數據的重平衡分配任務。這個過程對業務完全透明。
PD 集群調度器高可用設計
圖 13.PD 設計原理
PD 集群調度器是整個集群的管理節點，自身也是一套高可用集群的設計。PD 集群保存有整個集群的管理元數據，PD 節點之間通過 Raft 建立強一致性數據複製，任意 PD 的損壞或故障均可通過內部的高可用機制重新選舉 Leader 對外繼續提供服務。Leader 選舉過程非常短暫，且選舉過程本身對業務應用無影響，PD 所在節點的存儲設備（如磁盤）物理損壞，既不會影響 PD 中集群元數據的安全（Raft 複製機制保證），也不會影響真實的業務數據的安全性。
寫在最後
在新技術的嘗試和引入時，甜橙金融內部採取更包容的心態，以期待新技術可以帶給業務更可靠、便捷的基礎服務，以應對更快速的業務增長和更嚴峻的技術挑戰。甜橙金融成立 7 年來，從數據中心演進建設到數據層雙活探索，過程中的探索和思考是我最想和大家分享的。希望我們正在做的一些嘗試，能給正在進行“兩地三中心”建設的同學在數據中心建設、應用級雙活和數據級雙活上帶來一些新的思路，歡迎業內有此方面研究的朋友一起交流。
張小虎，現任甜橙金融技術總監，運維技術中心負責人，在數據庫內核、雲高可用架構以及 Devops 上有深入研究。當前負責甜橙金融運維體系設計及前沿基礎技術研究。目前主要工作集中在異地多活架構實施及 AIOPS 上。
閱讀更多 InfoQ 的文章
