今年一直在和團(tuán)隊做微服務(wù)的架構(gòu)改造（相關(guān)的一些詳情，有興趣的朋友，可以參見之前的這篇分享）。但是做過改造的朋友都知道 從“All-In-One” 到 “Micro-Service” 都需要邁過的一個坎，那就是垂直分庫, 根據(jù)不同的子服務(wù)，將數(shù)據(jù)庫拆分為不同的子服務(wù)庫。

那么問題就來了，在開始做微服務(wù)改造前，我發(fā)現(xiàn)在搖旺的老系統(tǒng)中，有很多后臺報表或者前端詳情頁所需的數(shù)據(jù)是通過SQL Join來完成的。但是，我們微服務(wù)改造后，每個服務(wù)背后的數(shù)據(jù)庫已經(jīng)在分布不同的實(shí)例中了，所以我們已經(jīng)不能繼續(xù)簡單在SQL中使用join了，那么解決“跨庫Join”就擺上了議事日程。

通過討論和調(diào)研，垂直分庫后，對于“跨庫查詢”的解決，可以采用以下幾個思路：

1. 依賴字段較少：字段冗余

A庫中的Tab1表需要關(guān)聯(lián)B庫中的Tab2表中的字段F, 我們就將字段F冗余到表Tab1中，那么查詢時候，Tab1和Tab2就不需要做Join，單獨(dú)查A庫中的Tab1表就可以解決問題。

這是一個野路子，因為這是違反正常的范式設(shè)計的，但在依賴字段較少的情況下還是可以解決問題的，達(dá)到空間來換取時間的目的。不過這個方法最大的短板在于2點(diǎn)： 1. 依賴字段不能太多，2. 數(shù)據(jù)一致性問題。Tab2中的F字段一但改變，必須要同步到Tab1中，否則就會引起臟數(shù)據(jù)的問題。所以，需要在業(yè)務(wù)代碼建立必要的同步機(jī)制，如果出錯，還需要考慮引入人工補(bǔ)償。

2. 依賴字段較多：表同步

在很多場景下，我們字段的依賴是很多的，乃至查詢的時候可能需要跨多張表，這個時候方法1就無法直接用了，我們就需要進(jìn)行表級別的數(shù)據(jù)同步，可以采用ETL工具來做到跨庫的表同步。不過需要注意的是，數(shù)據(jù)同步不建議實(shí)時性過高，否則數(shù)據(jù)庫的性能會受到比較大的影響。所以對于實(shí)時性不高的查詢要求，表同步還是比較奏效的。

3. 靜態(tài)字段依賴：數(shù)據(jù)字典表

對于不同庫中的靜態(tài)字段，可以建立一張數(shù)據(jù)字典表，可以將這類表在其他每個數(shù)據(jù)庫中均保存一份，從而避免跨庫join查詢。如果靜態(tài)數(shù)據(jù)表中的某些字段數(shù)據(jù)需要修改，可以采用一套腳本統(tǒng)一更新。

4. 服務(wù)層代碼進(jìn)行數(shù)據(jù)組裝

通過各種服務(wù)查詢到一個數(shù)據(jù)集，通過代碼進(jìn)行二次組裝，然后生成我們需要返回給前端的對象。在實(shí)踐過程中，對于處理過的查詢集，我們可以將它們緩存在我們的分布式緩存中，減少服務(wù)間的RPC調(diào)用次數(shù)和數(shù)據(jù)庫的查詢壓力。同時，注意設(shè)置好過期時間，把控好數(shù)據(jù)一致性和有效性。

以上就是4種應(yīng)對跨庫Join的思路，實(shí)戰(zhàn)中，一定是將這4類方案進(jìn)行組合使用的，同時，需要注意的是，相比這些解決思路，更重要的是表結(jié)構(gòu)的合理設(shè)計。否則要徹底解決跨庫是很困難的。

分布式事務(wù)的處理方式

除此之外，分庫后，還有一個難題，就是分布式事務(wù)的處理。具體的事例，可以參見我之前的這兩篇文章1和 文章2。里面會提到在微服務(wù)下，服務(wù)間事務(wù)回滾的幾個思路，希望對大家有用。

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

歡迎轉(zhuǎn)載，帶上以下二維碼即可

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。