微服務改造中解決跨庫問題的思路

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