今年一直在和團隊做微服務的架構改造（相關的一些詳情，有興趣的朋友，可以參見之前的這篇分享）。但是做過改造的朋友都知道 從“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
歡迎轉載，帶上以下二維碼即可