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