本文源碼： GitHub·點這裡 || GitEE·點這裡
一、資料庫擴容
1、業務場景
網際網路項目中有很多“資料量大，業務複雜度高，需要分庫分表”的業務場景。
這樣分層的架構
（1）上層是業務層biz，實作業務邏輯封裝；
（2）中間是服務層service，封裝資料通路；
（3）下層是資料層db，存儲業務資料； 2、擴容場景和問題
當資料量持續新增，面臨着這樣一些需求，兩台資料庫無法容納，需要資料庫擴容，這裡選擇2台—擴容到3台的模式，如下圖：
這樣擴容的問題
（1）分庫分表的政策導緻資料遷移量大；
（2）影響資料的持續服務性；
（3）指定時間完成，技術壓力大，容易導緻預想不到的錯誤； 如何平穩不停機遷移資料，保證系統持續服務，是本文将要讨論的問題。
二、擴容解決方案
1、擴容方案圖解
（1）分庫分表基于MySQL資料庫，使用shard-jdbc中間件
（2）該方案的思路整體基于SpringCloud微服務架構 2、解決擴容問題
（1）擴容情況下不需要暫停服務；
（2）資料遷移的壓力小，不需要指定時間； 3、資料通路層邏輯
方案描述
基于兩台資料庫分庫分表，簡稱：服務二
基于三台資料庫分庫分表，簡稱：服務三
（1）提供兩套服務，服務二和服務三
（2）資料庫擴容後，如果通路服務三直接擷取到資料，流程結束。
（3）如果通路服務三擷取不到資料，則通路服務二擷取資料。
（4）在遷移開始的一段時間内，通路壓力還會在服務二上面。
（5）這樣就做到資料通路服務不會停機。
（6）這種通路模式基于SpringCloud很容易做到。 4、資料遷移層邏輯
（1）關閉基于兩台庫的資料入庫流程
（2）開啟基于三台庫的資料入庫流程，這樣新入庫資料就可以被服務三直接通路到。
（3）開發資料遷移中間件，掃描原先兩台庫的資料。
（4）掃描的資料根據分三台庫政策判斷是否需要遷移。
（5）如果資料需要遷移，則調用服務三的資料入庫接口。
（6）資料遷移完成後，删除原來的位置的資料。
（7）這種遷移模式基于SpringCloud很容易做到。 5、該方案遷移的優點
（1）整個過程是持續對線上提供服務；
（2）資料遷移中間件的開發複雜度較低；
（3）可以限速慢慢遷移，沒有時間壓力； 三、源代碼管理
GitHub·位址
https://github.com/cicadasmile/cloud-shard-jdbc
GitEE·位址
https://gitee.com/cicadasmile/cloud-shard-jdbc