今年一直在和團隊做微服務的架構(gòu)改造（相關(guān)的一些詳情，有興趣的朋友，可以參見之前的這篇分享）。但是做過改造的朋友都知道 從“All-In-One” 到 “Micro-Service” 都需要邁過的一個坎，那就是垂直分庫, 根據(jù)不同的子服務，將數(shù)據(jù)庫拆分為不同的子服務庫。
那么問題就來了，在開始做微服務改造前，我發(fā)現(xiàn)在搖旺的老系統(tǒng)中，有很多后臺報表或者前端詳情頁所需的數(shù)據(jù)是通過SQL Join來完成的。但是，我們微服務改造后，每個服務背后的數(shù)據(jù)庫已經(jīng)在分布不同的實例中了，所以我們已經(jīng)不能繼續(xù)簡單在SQL中使用join了，那么解決“跨庫Join”就擺上了議事日程。
通過討論和調(diào)研，垂直分庫后，對于“跨庫查詢”的解決，可以采用以下幾個思路：
1. 依賴字段較少：字段冗余
A庫中的Tab1表需要關(guān)聯(lián)B庫中的Tab2表中的字段F, 我們就將字段F冗余到表Tab1中，那么查詢時候，Tab1和Tab2就不需要做Join，單獨查A庫中的Tab1表就可以解決問題。
這是一個野路子，因為這是違反正常的范式設計的，但在依賴字段較少的情況下還是可以解決問題的，達到空間來換取時間的目的。不過這個方法最大的短板在于2點： 1. 依賴字段不能太多，2. 數(shù)據(jù)一致性問題。Tab2中的F字段一但改變，必須要同步到Tab1中，否則就會引起臟數(shù)據(jù)的問題。所以，需要在業(yè)務代碼建立必要的同步機制，如果出錯，還需要考慮引入人工補償。
2. 依賴字段較多：表同步
在很多場景下，我們字段的依賴是很多的，乃至查詢的時候可能需要跨多張表，這個時候方法1就無法直接用了，我們就需要進行表級別的數(shù)據(jù)同步，可以采用ETL工具來做到跨庫的表同步。不過需要注意的是，數(shù)據(jù)同步不建議實時性過高，否則數(shù)據(jù)庫的性能會受到比較大的影響。所以對于實時性不高的查詢要求，表同步還是比較奏效的。
3. 靜態(tài)字段依賴：數(shù)據(jù)字典表
對于不同庫中的靜態(tài)字段，可以建立一張數(shù)據(jù)字典表，可以將這類表在其他每個數(shù)據(jù)庫中均保存一份，從而避免跨庫join查詢。如果靜態(tài)數(shù)據(jù)表中的某些字段數(shù)據(jù)需要修改，可以采用一套腳本統(tǒng)一更新。
4. 服務層代碼進行數(shù)據(jù)組裝
通過各種服務查詢到一個數(shù)據(jù)集，通過代碼進行二次組裝，然后生成我們需要返回給前端的對象。在實踐過程中，對于處理過的查詢集，我們可以將它們緩存在我們的分布式緩存中，減少服務間的RPC調(diào)用次數(shù)和數(shù)據(jù)庫的查詢壓力。同時，注意設置好過期時間，把控好數(shù)據(jù)一致性和有效性。
以上就是4種應對跨庫Join的思路，實戰(zhàn)中，一定是將這4類方案進行組合使用的，同時，需要注意的是，相比這些解決思路，更重要的是表結(jié)構(gòu)的合理設計。否則要徹底解決跨庫是很困難的。
分布式事務的處理方式
除此之外，分庫后，還有一個難題，就是分布式事務的處理。具體的事例，可以參見我之前的這兩篇文章1和 文章2。里面會提到在微服務下，服務間事務回滾的幾個思路，希望對大家有用。
