今年一直在和團隊做微服務的架構改造（相關的一些詳情，有興趣的朋友，可以參見之前的這篇分享）。但是做過改造的朋友都知道 從“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。里面會提到在微服務下，服務間事務回滾的幾個思路，希望對大家有用。

掃描二維碼或手動搜索微信公眾號【架構棧】： ForestNotes

歡迎轉載，帶上以下二維碼即可

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的微服务改造中解决跨库问题的思路的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。