ShardingSphere 異構遷移最佳實踐：將3.5億量級的顧客系統 RTO 減少60倍
Apache ShardingSphere 助力噹噹 3.5 億用戶量級顧客系統重構，由 PHP+SQL Server 技術棧無縫轉型為 Java+ShardingSphere+MySQL，性能、可用性及維護性均得到顯著提升，是 ShardingSphere 異構遷移最佳實踐。
1 顧客系統背景
噹噹顧客系統主要負責賬戶的註冊、登錄、隱私數據維護等功能，歷史技術棧為 PHP+SQL Server，是標準的集中式架構，如下圖。
重構項目啟動前，顧客系統的數個業務模塊存在多個棘手的業務問題和技術挑戰，如邏輯分散、吞吐量低及運維成本高等問題。為改善顧客的購物體驗，噹噹技術團隊決定對業務邏輯和底層數據架構進行優化，實現顧客系統多場景下的可用性、擴展性及綜合提升等多個目標。在重構過程也實現了眾多技術創新，如跨數據源雙寫、讀寫分離、智能網關及灰度發佈等技術。
從需求設計、分庫分表規劃、邏輯優化、壓測再到完全上線等多個環節，噹噹技術團隊用半年的時間完成了基於 3.5 億+用戶的系統重構。
使用 Java 語言重構十餘個模塊，通過 ShardingSphere+ MySQL 構建分佈式數據庫解決方案，順利完成異構數據庫在線遷移，案例亮點如下。
-
使用 Java 語言重構 PHP 業務代碼；
-
使用 ShardingSphere+MySQL 替換 SQL Server；
-
在線完成 3.5 億用戶數據完整遷移；
-
通過數據雙寫方案完成無縫上線。
2 痛點&挑戰
業務痛點
在業務層面，顧客系統部分模塊的註冊和登錄邏輯分散在各端，維護成本較高，且當時的技術架構對於性能的提升和高可用性存在着很大的局限性。
-
不易維護：多平台註冊和登錄邏輯較為分散，業務維護複雜；
-
性能受限：PHP+SQL Server 集中式技術架構，吞吐量不足；
-
可用性&安全性差：
-
SQL Server 主備狀態變化後，訂閱庫會失效，重新配置需要窗口時間；
-
SQL Server 運行在 Windows Server 上，病毒影響導致安全性差，且打補丁後升級啟動時間長（>30min）。
挑戰
- 數據完整性
顧客系統擁有 3.5 億+ 用戶數據，在數據遷移過程中，需保證數據從 SQL Server 遷移到 MySQL 後的一致性及完整性；
- API 透明
API 對調用方保持透明，確保調用方無改動，最小化變更界面；
- 無縫切換
需要滿足業務系統無縫切換，切換過程對業務無影響；
- 時間緊迫
「618」和「11.11」促銷活動前後會封網，因此需在兩大促活動間、有限窗口的時間內完成切換，並緊接着面對「11.11」的驗證。
3 解決方案
整體規劃
為了改善顧客系統的可維護性、可用性及性能，研發團隊重新梳理顧客系統的架構。
在應用層，統一各端的功能邏輯，提升業務可維護性。在數據庫層，將集中式架構調整為分佈式數據庫架構，提升性能及可用性，即 ShardingSphere+MySQL 構建的開源分佈式解決方案。
-
應用層：隨噹噹整體技術棧的變遷，業務開發語言由 PHP 轉為 Java；
-
中間件：使用成熟的開源數據庫中間件 ShardingSphere 實現分庫分表；
-
數據庫：使用多套 MySQL 集群代替 SQL Server 數據庫。
在整體架構設計上，引入了分佈式主鍵生成策略、分片管理、數據遷移校驗以及灰度發佈等多個方案。
分佈式主鍵生成策略
數據庫架構由集中式轉型為基於中間件的分佈式架構，分佈式主鍵生成策略是首先需要考慮解決問題。在系統重構中，選擇建立兩台以上的數據庫 ID 生成服務器，每台服務器都有一張記錄各表當前 ID 的 Sequence 表，Sequence 中 ID 增長的步長是服務器的數量。起始值依次錯開，這樣相當於把 ID 的生成散列到了每台服務器節點上。
分片（ShardingSphere）
在顧客系統重構中，通過 Apache ShardingSphere 完成數據庫 Sharding，同時也啟用了讀寫分離功能。
由於顧客系統在高並發、低延時的要求，接入端選擇了 ShardingSphere-JDBC，它定位為輕量級 Java 框架，在 Java 的 JDBC 層提供的額外服務。它使用客戶端直連數據庫，以 jar 包形式提供服務，無需額外部署和依賴，可理解為增強版的 JDBC 驅動，完全兼容 JDBC 和各種 ORM 框架。
- Sharding
ShardingSphere 支持非常全面的分片算法，包括取模、哈希、範圍、時間及自定義等算法，顧客系採用取模分片算法對大表進行拆分。
- 讀寫分離
除了 Sharding，同時還啟用 ShardingSphere 讀寫分離功能，充分利用 MHA 集群資源，提升系統吞吐能力。
雙寫&數據同步
數據同步貫穿了整個重構項目，數據遷移的完整性及數據一致性是重構的關鍵。
該案例基於 Elastic-Job 同步歷史數據，以周期的方式將 SQL Server 的歷史數據同步到 MySQL 中。
關於數據庫切換方面，在切換過程中會採用備份方案，進行數據庫的雙寫，保證切換前後的數據一致性，過程如下。
第 1 步：實現雙寫機制
斷掉鏈路 1，打通鏈路 2、3、4，打通鏈路 9、10。
第 2 步：切換登錄服務
斷掉鏈路 9，10，打通鏈路 7，斷掉鏈路 5。
第 3 步：切換讀服務
打通鏈路 8，斷掉鏈路 6。
第 4 步：取消雙寫機制
斷掉鏈路 2，完成切換。
在數據校驗方面，通過業務側和數據庫側兩個方面進行驗證，均周期性進行檢查，在不同時間段採用不同的頻率，抽樣或全量檢查數據的完整性，在數據庫側也會進行 COUNT/SUM 的驗證。
顧客系統重構使用了基於 apollo 的灰度發佈方式，在新登錄方式的處理上，通過配置項逐步放開、小範圍陸續割接，確保上線成功率。重構後的系統架構如下圖。
4 用戶收益
經過重構，噹噹顧客系統響應速度明顯提升，同時也降低了日常運維成本，ShardingSphere 提供的分佈式解決方案功不可沒。該方案適用於各種高流量的互聯網平台服務，也適用於電商平台以及其他以數據處理為主的系統。
-
性能提升，響應速度提升 20% 以上；
-
可用性增強，ShardingSphere+MySQL 的方案實現 RTO<30s；
-
易於維護，業務邏輯以及數據庫的可維護性明顯提升；
-
無縫遷移，6 個月內在線完成各模塊割接，窗口時間為零。
5 總結
在「ShardingSphere 助力噹噹 WMS：訂單效率提升 30%、節約成本上千萬」案例之後，這是第二篇 ShardingSphere 在噹噹的實踐案例。
Apache ShardingSphere 為業務系統提供了強力的支撐。簡單與極致，是 ShardingSphere 突出的兩個特性，讓業務邏輯更簡單，讓性能更極致。
Apache ShardingSphere 社區已在開源領域耕耘了 7 年的時間。長久的堅持，使社區愈加成熟，已呈開放和多元化的勢態。我們誠心歡迎有開源情懷和編碼熱情的朋友一起參與社區共建，也歡迎您提供優質案例內容分享給社區的朋友們。
如果大家對 Apache ShardingSphere 有任何疑問或建議，歡迎在 GitHub Issue 列表提出，或可前往中文社區交流討論。
GitHub Issue：//github.com/apache/shardingsphere/issues
貢獻指南：//shardingsphere.apache.org/community/cn/contribute/
中文社區：//community.sphere-ex.com/
