ShardingSphere 異構遷移最佳實踐：將3.5億量級的顧客系統 RTO 減少60倍

Apache ShardingSphere 助力噹噹 3.5 億用戶量級顧客系統重構，由 PHP+SQL Server 技術棧無縫轉型為 Java+ShardingSphere+MySQL，性能、可用性及維護性均得到顯著提升，是 ShardingSphere 異構遷移最佳實踐。 ...

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 框架。