一、舊系統(tǒng)的現(xiàn)狀分析：
1）服務調(diào)用關系
2）接口梳理
訂單相關舊系統(tǒng)接口整理：
a、gamecatsdk服務
b、wechat服務
c、paysdk服務
d、paycenter服務
主要梳理的格式包括：
接口名稱；接口uri；接口被調(diào)用服務；接口網(wǎng)絡訪問（內(nèi)網(wǎng)還是外網(wǎng)）；遷移后的服務；重構后新接口URI。
（具體的梳理省略，每個公司每個系統(tǒng)的情況各不一樣。）
3）ER關系圖
二、新系統(tǒng)的設計
1）ER圖：
2）域名依賴關系：
paycenter的域名是：paycenter.xxx.com
trade的域名是：trade.xxx.com
a、支付回調(diào)。為了支持舊系統(tǒng)已發(fā)起的支付(支付寶和微信)，在trade-nginx配置舊域名paycenter.xxx.com的調(diào)用。也就是說，無論是paycenter.xxx.com還是trade.xxx.com都指向trade-nginx服務器。
注意：在開發(fā)測試環(huán)境里，trade服務需要開通對外端口映射，讓支付機構能夠回調(diào)到trade-nginx。
b、IOS內(nèi)支付回調(diào)，為了兼容舊版本的客戶端回調(diào)服務后端，之前是訪問paycenter.xxx.com /notify/iosInnerPay，所以trade-nginx需要支持paycenter.xxx.com/notify/iosInnerPay。
3）數(shù)據(jù)遷移：
由于舊系統(tǒng)的訂單和代金券也是分庫分表，需要先使用臨時表，把之前的分庫聚合到一張臨時表。再根據(jù)主鍵ID%n的方式分到新的庫里。
在預防環(huán)境下執(zhí)行, 數(shù)據(jù)遷移分為三類數(shù)據(jù)，包括基礎類，訂單類和支付類。
等新服務上線驗證無誤后，執(zhí)行補償任務，把落在舊庫的訂單和支付等數(shù)據(jù)再次補償?shù)叫聨臁?/p>
I、基礎數(shù)據(jù)
支付接口實現(xiàn) pay_api :
支付接口映射：pay_api_mapping
ios sdk商品：sdk_ios_goods
II、支付數(shù)據(jù)
支付流水：pay_flow
支付通知：pay_notify
ios支付校驗 pay_ios_voucher_check
III、訂單數(shù)據(jù)
訂單：order_base
喵點訂單：catpt_order_detail
sdk訂單：sdk_order_detail
訂單索引表：order_es_index
訂單代金券使用表：order_use_coupon
4）因為訂單分庫分表了，之前為了解決跨庫聚合問題，引入的是訂單索引表。
后期引入分布式搜索引擎ElasticSearch。
mysql數(shù)據(jù)庫負責的是操作類，ES負責訂單查詢，分頁查詢等。
做過分庫分表的重構同學，都得面臨解決舊庫與新庫的一致性問題。常見的解決方案有：
I、停機部署
掛出停機公告，屆時進行數(shù)據(jù)遷移，待驗證通過后，切流到新庫。
II、雙寫到db和mq
歷史數(shù)據(jù)
增量數(shù)據(jù)：保存在mq里，通過訂閱程序把增量數(shù)據(jù)補到新庫。
III、雙寫到db和ES
采用cqrs思想，把操作類和查詢類分離開來，新庫和舊庫都會寫入ES, 避免查詢數(shù)據(jù)的同步延遲等問題，保證用戶看到的訂單數(shù)據(jù)是實時的，也不影響運營后臺的訂單管理。
mysql里的數(shù)據(jù)采用補償機制，把舊庫的增量數(shù)據(jù)同步到新庫。
建議方案三，可以不用停機部署，至于灰度策略問題，等后續(xù)專門文章來討論。
在遷移期間，舊程序和舊庫表務必保留，不能刪除，否則會出現(xiàn)訂單或支付流水號找不到的錯誤等等。新系統(tǒng)必須是對新舊的一個同時兼容，只有待程序運行確保無誤后，再刪程序刪庫表。
