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

SphereEx發表於2022-06-13

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