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

## 1  顧客系統背景

噹噹顧客系統主要負責賬戶的註冊、登入、隱私資料維護等功能，歷史技術棧為 PHP+SQL Server，是標準的集中式架構，如下圖。
![](http://img.blog.itpub.net/blog/2022/06/13/accb9d3e49fe3bfb.png?x-oss-process=style/bb)
重構專案啟動前，顧客系統的數個業務模組存在多個棘手的業務問題和技術挑戰，如邏輯分散、吞吐量低及運維成本高等問題。為改善顧客的購物體驗，噹噹技術團隊決定對業務邏輯和底層資料架構進行最佳化，實現顧客系統多場景下的可用性、擴充套件性及綜合提升等多個目標。在重構過程也實現了眾多技術創新，如跨資料來源雙寫、讀寫分離、智慧閘道器及灰度釋出等技術。

從需求設計、分庫分表規劃、邏輯最佳化、壓測再到完全上線等多個環節，噹噹技術團隊用半年的時間完成了基於 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 資料庫。
![](http://img.blog.itpub.net/blog/2022/06/13/c4dc910f2815cc54.png?x-oss-process=style/bb)
在整體架構設計上，引入了分散式主鍵生成策略、分片管理、資料遷移校驗以及灰度釋出等多個方案。

#### 分散式主鍵生成策略

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

#### 分片（ShardingSphere）

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

由於顧客系統在高併發、低延時的要求，接入端選擇了 ShardingSphere-JDBC，它定位為輕量級 Java 框架，在 Java 的 JDBC 層提供的額外服務。它使用客戶端直連資料庫，以 jar 包形式提供服務，無需額外部署和依賴，可理解為增強版的 JDBC 驅動，完全相容 JDBC 和各種 ORM 框架。
![](http://img.blog.itpub.net/blog/2022/06/13/ef863948f0903dc1.png?x-oss-process=style/bb)

* **Sharding**

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

* **讀寫分離**

除了 Sharding，同時還啟用 ShardingSphere 讀寫分離功能，充分利用 MHA 叢集資源，提升系統吞吐能力。
![](http://img.blog.itpub.net/blog/2022/06/13/6c90089937afa775.png?x-oss-process=style/bb)
#### 雙寫&資料同步

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

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

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

**第 1 步：實現雙寫機制**

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

**第 2 步：切換登入服務**

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

**第 3 步：切換讀服務**

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

**第 4 步：取消雙寫機制**

斷掉鏈路 2，完成切換。
![](http://img.blog.itpub.net/blog/2022/06/13/da5a36d8c15e2a40.png?x-oss-process=style/bb)
在資料校驗方面，透過業務側和資料庫側兩個方面進行驗證，均週期性進行檢查，在不同時間段採用不同的頻率，抽樣或全量檢查資料的完整性，在資料庫側也會進行 COUNT/SUM 的驗證。

顧客系統重構使用了基於 apollo 的灰度釋出方式，在新登入方式的處理上，透過配置項逐步放開、小範圍陸續割接，確保上線成功率。重構後的系統架構如下圖。
![](http://img.blog.itpub.net/blog/2022/06/13/080047948d602f23.png?x-oss-process=style/bb)
## 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/

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

相關文章