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

SphereEx 發表於 2022-06-13

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

1  顧客系統背景

噹噹顧客系統主要負責賬戶的註冊、登入、隱私資料維護等功能,歷史技術棧為 PHP+SQL Server,是標準的集中式架構,如下圖。
ShardingSphere 異構遷移最佳實踐:將3.5億量級的顧客系統 RTO 減少60倍

重構專案啟動前,顧客系統的數個業務模組存在多個棘手的業務問題和技術挑戰,如邏輯分散、吞吐量低及運維成本高等問題。為改善顧客的購物體驗,噹噹技術團隊決定對業務邏輯和底層資料架構進行優化,實現顧客系統多場景下的可用性、擴充套件性及綜合提升等多個目標。在重構過程也實現了眾多技術創新,如跨資料來源雙寫、讀寫分離、智慧閘道器及灰度釋出等技術。

從需求設計、分庫分表規劃、邏輯優化、壓測再到完全上線等多個環節,噹噹技術團隊用半年的時間完成了基於 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 資料庫。
    ShardingSphere 異構遷移最佳實踐:將3.5億量級的顧客系統 RTO 減少60倍

在整體架構設計上,引入了分散式主鍵生成策略、分片管理、資料遷移校驗以及灰度釋出等多個方案。

分散式主鍵生成策略

資料庫架構由集中式轉型為基於中介軟體的分散式架構,分散式主鍵生成策略是首先需要考慮解決問題。在系統重構中,選擇建立兩臺以上的資料庫 ID 生成伺服器,每臺伺服器都有一張記錄各表當前 ID 的 Sequence 表,Sequence 中 ID 增長的步長是伺服器的數量。起始值依次錯開,這樣相當於把 ID 的生成雜湊到了每臺伺服器節點上。

分片(ShardingSphere)

在顧客系統重構中,通過 Apache ShardingSphere 完成資料庫 Sharding,同時也啟用了讀寫分離功能。

由於顧客系統在高併發、低延時的要求,接入端選擇了 ShardingSphere-JDBC,它定位為輕量級 Java 框架,在 Java 的 JDBC 層提供的額外服務。它使用客戶端直連資料庫,以 jar 包形式提供服務,無需額外部署和依賴,可理解為增強版的 JDBC 驅動,完全相容 JDBC 和各種 ORM 框架。
ShardingSphere 異構遷移最佳實踐:將3.5億量級的顧客系統 RTO 減少60倍

  • Sharding

ShardingSphere 支援非常全面的分片演算法,包括取模、雜湊、範圍、時間及自定義等演算法,顧客系採用取模分片演算法對大表進行拆分。

  • 讀寫分離

除了 Sharding,同時還啟用 ShardingSphere 讀寫分離功能,充分利用 MHA 叢集資源,提升系統吞吐能力。
ShardingSphere 異構遷移最佳實踐:將3.5億量級的顧客系統 RTO 減少60倍

雙寫&資料同步

資料同步貫穿了整個重構專案,資料遷移的完整性及資料一致性是重構的關鍵。

該案例基於 Elastic-Job 同步歷史資料,以週期的方式將 SQL Server 的歷史資料同步到 MySQL 中。

關於資料庫切換方面,在切換過程中會採用備份方案,進行資料庫的雙寫,保證切換前後的資料一致性,過程如下。

第 1 步:實現雙寫機制

斷掉鏈路 1,打通鏈路 2、3、4,打通鏈路 9、10。

第 2 步:切換登入服務

斷掉鏈路 9,10,打通鏈路 7,斷掉鏈路 5。

第 3 步:切換讀服務

打通鏈路 8,斷掉鏈路 6。

第 4 步:取消雙寫機制

斷掉鏈路 2,完成切換。
ShardingSphere 異構遷移最佳實踐:將3.5億量級的顧客系統 RTO 減少60倍

在資料校驗方面,通過業務側和資料庫側兩個方面進行驗證,均週期性進行檢查,在不同時間段採用不同的頻率,抽樣或全量檢查資料的完整性,在資料庫側也會進行 COUNT/SUM 的驗證。

顧客系統重構使用了基於 apollo 的灰度釋出方式,在新登入方式的處理上,通過配置項逐步放開、小範圍陸續割接,確保上線成功率。重構後的系統架構如下圖。
ShardingSphere 異構遷移最佳實踐:將3.5億量級的顧客系統 RTO 減少60倍

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:https://github.com/apache/shardingsphere/issues

貢獻指南:https://shardingsphere.apache.org/community/cn/contribute/

中文社群:https://community.sphere-ex.com/