概述
多年來，我們一直在技術的浪潮中乘風破浪，揚帆奮進，尋找更優秀的方法來構建IT系統，也一直在積極的學習並觀察先進的公司如何以不同的架構方式構建或者優化其IT系統，來積極應對市場的變化，迅速做出響應，從而為客戶提供更多的價值。
微服務架構模式（Microservice Architect Pattern）是近兩年在軟件架構模式領域裡出現的一個新名詞。雖然其誕生的時間不長，但其在各種演講、文章、書籍上所出現的頻率已經讓很多人意識到它對軟件領域所帶來的影響。那到底什麼是微服務，當我們談論微服務時，它代表著一種什麼樣的含義？微服務適合應用在什麼場景下，以及它有什麼樣的優缺點？微服務和SOA到底有沒有區別？在接下來的幾部分裡，我將為大家揭開微服務的神祕面紗。
通過討論和調研，垂直分庫後，對於“跨庫查詢”的解決，可以採用以下幾個思路：
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類方案進行組合使用的，同時，需要注意的是，相比這些解決思路，更重要的是表結構的合理設計。否則要徹底解決跨庫是很困難的。
5.考慮使用JTA等支持分佈式事務的事務管理器
這種方案的優勢就是直接有現成的解決方案，一般的j2ee服務器都提供了JTA的相關的實現。比較明顯的問題就是解決方案太重量級。一般JTA除了服務器要支持，對應的數據庫服務廠商一般也要提供相應的商業支持，主要是提供基於 XAResource JDBC驅動，這一些商業上的支持，部分是需要付費的。而且使用XA 數據庫驅動，本身可能導致一些潛在的問題，尤其是基於不同的數據庫廠商的時候。而XA是基於兩階段提交協議，事務管理器為了完成一個事務，需要多次和數據庫通信，效率上比較低。
6.考慮使用數據庫自身的數據同步機制
如果新老庫的結構基本一樣，這種方案還是比較靠譜的。也是比較簡單的方案。這種方案的侷限性也再次。在本項目中，新庫不是一個物理庫，而是多個物理庫，而老庫是一個物理庫。如果要用數據庫自身的同步機制，涉及到多個庫和一個庫之間的數據複製。同時由於分表的方案也不一樣，導致兩邊做一個映射的配置，而這個需要在數據庫層面進行，邏輯相當的複雜，解決方案成本也比較高。相當於把重要的分庫分表的邏輯在數據庫這一層重新實現了一份。
其實這個也帶來一個維護問題，一旦我們覺得新系統已經足夠穩定。應用程序可以之間在寫入庫進行切換，把老庫的邏輯切掉，從而實現了只寫新庫的需求。整個過程也不需要進行再次發佈。而數據庫的方案則需要停掉腳本，在多個地方進行配置。
7. 在old庫存放相同的兩張模型表，一張表用於old庫的持久化表，另外一張作為臨時表，主要是作為需要同步到到新庫的數據。如果已經同步到新庫，就刪除。如果沒有同步到新庫就同步到新庫。這個過程採用定時機制，每分鐘定時提取臨時表一定數據量的數據，批量導入到新庫。通過努力重試，來保證一致性。而新庫則需要保證冪等性，保證數據只會同步過一次。一般情況下，則是通過數據特徵標識符來識別，這個一般都是數據的唯一性主鍵。
總結
到這裡，微服務架構如何解決跨庫問題的思路與方案就結束了，，不足之處還望大家多多包涵！！覺得收穫的話可以點個關注收藏轉發一波喔，謝謝大佬們支持。（吹一波，233~~）
下面和大家交流幾點編程的經驗：
1、多寫多敲代碼，好的代碼與紮實的基礎知識一定是實踐出來的
2丶 測試、測試再測試，如果你不徹底測試自己的代碼，那恐怕你開發的就不只是代碼，可能還會聲名狼藉。
3丶 簡化編程，加快速度，代碼風騷，在你完成編碼後，應回頭並且優化它。從長遠來看，這裡或那裡一些的改進，會讓後來的支持人員更加輕鬆。
最後，每一位讀到這裡的網友，感謝你們能耐心地看完。希望在成為一名更優秀的Java程序員的道路上，我們可以一起學習、一起進步。
內部交流群469717771 歡迎各位前來交流和分享， 驗證：（007）
