作者：阿里雲高級技術專家改天
2020年天貓雙十一成交額突破4982億，在雙十一走過12個年頭之際，我們的訂單創建峯值達到58.3萬筆/秒，再次刷新全球在線交易系統的記錄。歷年雙十一都是對技術人的一次大考，峯值的絲般潤滑體驗是大家一致的追求，而數據庫可謂關鍵。多年雙十一大促“磨練”出阿里巴巴DBA一整套技能來應對大考，比方說全鏈路壓測、容災預案、實時限流等，同時阿里的數據庫產品能力也大幅提升，如智能化的企業級MySQL內核AliSQL，自研PolarDB引擎等，這些硬核能力是阿里巴巴集團數據庫團隊應對大考的底氣。
在數據庫引擎技術能力不斷攀登高峯的同時，長期以來我們“似乎忽略”一個非常重要的因素，而該因素卻是中大型企業上雲的必須考量點。如果將時鐘指針撥回到半年前，這個重要因素就擺在眼前，是阿里巴巴集團所有的數據庫系統全面上雲及雲原生化過不去的“坎”，它是什麼呢？
一、阿里集團數據庫全面上雲的挑戰
當DBA維護的系統上百套甚至上萬套以後，系統管理的複雜度就會急劇上升，加上資源利用效率、業務高峯支持（如大促活動評估）、流量管理等上級或業務方“強加給”DBA的工作後，整個系統複雜度就會居高不下，這種複雜度“熵”就會指數級增長，並且無法通過擴充DBA人數來有效解決問題，DBA自身也會陷入到繁雜的日常支持和“滅火”中，自身價值難以體現，這就是深坎。
阿里巴巴集團就是這樣一個巨型的、系統複雜度“熵”奇高的大型企業。今年阿里雙十一要求所有系統全面上雲，相比單純提升系統吞吐擴展能力的技術要求，這個任務更加難完成。簡述下當初面臨的嚴峻挑戰：
1. 如何保證大量數據庫短時間內快速上雲？
這不僅僅是數據的搬遷過程，還要在此期間支持業務需求，比方說如何做到對業務“無感知”的遷移數據上雲。如何在阿里的巨型體量下，保障所有系統全面上雲的絲般順滑度？
2. 如何高效支持DBA滿足雙十一期間的數據庫業務需求？
DBA對業務系統是熟悉，多系統之間有的相互依賴有的相互排斥，如何有效的將它們編排好，從而整體利用好數據庫資源，這是非常大的挑戰。
3. 全面上雲以後，要支持DBA依舊對數據庫的強管理能力，比方說能夠及時登錄操作系統排查數據庫問題等。
二、全面上雲的新打法，以專屬集羣RDS構建超高效數據庫管理體系
在全面上雲這個殘酷指標下，必須找到全新的方法來解決上述三個重點問題，構建一個高複雜度的但“混亂熵值”很低的超高效的數據庫管理體系。這就是全面採用專屬集羣RDS的根本前提。
那麼我們是如何極短時間內全面上雲並且能夠絲般順滑，如何充分發揮DBA的業務把控能力從而實現對RDS標準化服務的超高效能的管理，以及如何利用專屬集羣的源生內核能力構建全球最大的異地多活電商系統呢？
2.1 絲般順滑上雲
要實現絲般順滑上雲，需要充分規劃和精細的執行。由於阿里集團是隔離於公有云的網絡環境，底層對數據庫資源的網絡配置上雲後都會涉及變化，數據庫還要特別注意避免雙寫，要和業務做聯動的流量管理。
上圖是我們實現絲般順滑上雲的基礎框架圖：
1. 將數據傳輸路徑儘量縮短，節省大量時間：由於阿里集團超高業務量，幾乎每個數據庫系統的數據量都是巨大的，少則TB多則PB爲單位，我們採用最原始有效的方法，將備份文件拷貝到雲上環境，然後執行快速恢復。
2. 有效快速恢復是另一省時環節。阿里集團數據庫普遍有兩種存儲類型，分別是本地SSD盤和ESSD雲盤，兩者的備份方案是不同的，本地SSD盤類似於Xtrabackup執行物理的備份，ESSD雲盤採用存儲級快照備份。對應的兩者快速恢復的方法也不同，本地SSD盤在備份時採用庫表級備份，而恢復的則採用並行表級恢復，大幅度的提升恢復速度，ESSD雲盤則通過秒級快照恢復實現。也就是說從阿里集團網的全量備份、到數據兩套環境的傳輸、到雲上環境的快速恢復是一個聯動的連續過程，從而大大節省恢復時間。
3. 利用MySQL源生複製實時追加增量數據，確保業務對數據的搬遷無感知。在複製技術方面，AliSQL 針對高延遲網絡做了大量的協議優化嘗試和測試，通過合理的Batching和Pipelining，設計並實現了一整套自適應的針對高延遲高吞吐和低延遲高吞吐網絡的通信模式，極大的提升了日誌傳輸的性能。另外爲了節省帶寬，對binlog全面壓縮，同時在壓縮率和解壓速率上採個較好的平衡值。
4. 統一的混合網絡環境代理實現流量的按需切換，確保業務感覺遷移的過程是順滑的。聯動於業務部署，先切換讀流量到雲上環境，後切換寫流量。由於代理層實現透明切換能力，在分鐘級級內會保持原有的數據庫連接，保障切寫過程中業務是無感知的，在絕大數情況下效果很好。
2.2 靈活可控的標準化服務管理
雙十一涉及數據庫系統數萬套，除交易、商品、用戶、評價、優惠、店鋪、積分等核心系統外，還有各種“中小型”業務系統，機會每個業務都有一套或多套數據庫，每個業務之間有親和性或排斥性需求，即必須要在專屬集羣中滿足多樣性的業務部署要求。
舉例而言，我們將購物車數據庫和購物車應用自身部署在一起，確保購物車不受別的業務影響，同時購物車內部實現交叉部署，大致部署圖如下所示，通過靈活的部署策略，業務方DBA可以制定一套複雜部署策略滿足業務需要。
如上所述參與雙十一的業務方特別多，而DBA人數有限，DBA對業務的掌控程度也是高低不一的。一般而言，上述的核心業務基本上比較清晰，這主要得益於雙十一前的一次次全鏈路壓測，交易核心鏈路業務模型比較清晰，對數據庫容量的預估會很準確。但是這並不是所有情況，比方說創新型業務，對業務流量評估會非常的不準確，可能百倍增長也有可能是百分比增長，此情況下DBA預留數據庫資源沒有參考依據，如何在有限的資源中支持足夠多的創新型業務絕對是一大挑戰。再比方說原邊緣型業務，會由於其他系統的新依賴、或者業務流量徒增導致流量預期不準，更常見的是被其他系統新依賴，還容易導致故障。
爲了解決該不確定性問題，我們在專屬集羣上特別開發智能化DAS資源調度系統，DBA可以通過簡單的設置實例的彈性策略，DAS會根據過去系統的表現情況以及突發狀態，基本上以準實時的方式實現秒級資源彈性，分鐘級資源調度。秒級資源彈性能力，是在整臺主機範圍內靈活的對實例資源進行調整，也可以人工干預保護一些實例資源不被爭搶。分鐘級的資源調度能力，這得益於存儲計算分離架構，通過分佈式存儲的秒級快照能力，以分鐘級在不同主機之間重新平衡資源利用調度實例，由於高可用保障系統和代理透明切換能力，這個過程幾乎是平滑的。通過專屬集羣，DBA只需要投入一定量的服務器資源，然後專注監控整體集羣的資源水位，就可以保障大量的創新和小型業務的大促性能需要，可謂一夫當關萬夫莫開。
2.3 構建源生異地多活
雙十一零點高峯流量是巨大的，今年交易筆數達到58.3 萬筆/秒，數據庫集羣的TPS超過千萬級每秒，巨大的洪峯流量通過阿里的單元化數據庫部署來分流，從而規避單個實例單個機房的流量風險。與往年相比，今年單元化數據庫全部採用全球數據庫模式支持多地域的讀流量，另外在內核中實現源生多寫能力，支持實例集羣級別的異地多寫多活，從而可以在不同地域分擔寫流量。
如上圖所示本次雙十一阿里巴巴啓用張北、深圳、南通3個地域，針對每個Region是獨立開服的，地域之間是低耦合的，通過一個橋樑把他們連接起來，它就是全球數據庫網絡，（GDN，Global database network）。部署於不同地域的數據庫，採用MySQL的源生複製技術，保證數據的一致性和實時性。
關於異地多活，第一次實現了在內核層的雙向同步，在多個地域中都有各自主節點和備節點，在內核中實現雙向複製，保障兩個地域在數據總量上是一致的，同時寫實現分地域分流。這裏需要強調的一點，異地多活需要業務的改造，比如這個UID的數據只會在某一個地域寫入避免行衝突，此外ID（PK鍵）也需要使用獨立的Sequence，從而實現全局的一致性。業務和數據庫在本套架構中實現完美結合，業務只需要關注邏輯的拆分，而數據庫自身實現數據的同步組合，底層數據同步複雜性完全由數據庫自身實現。
三、展望
總結而言，本次雙十一爲了保障集團數萬數據庫的全面上雲及雲原生化，我們基於專屬集羣做了很多定向改造和匹配，取得了非常好的效果。核心交易鏈路總共構建數千臺機器集羣，總共超過數萬的數據庫節點，並且所有數據庫系統RPO等於0，主備延遲做到毫秒級，並保證整體人力效能數量級提升。靈活調度、源生複製等定製化能力，在專屬集羣內部實現產品化，經過雙十一驗證後，逐步開放，將會大幅度提升企業數據庫管理生產力，敬請期待。