1樓：太上玄元道君
得看你們的場景，如果是OLTP業務，那就去呼叫其他服務的介面，通過分布式事務去做最終一致性。
如果是OLAP就簡單了，把你所有分庫的資料同步到乙個從庫中，在從庫中進行分析
2樓：小憤青
把資料以
customer]
}類似這樣的方式,儲存在ES上, 資料庫盡量就不做特別多的多表關聯查詢了.至於後續取資料, 基本就是根據主鍵外來鍵取了.速度基本上也不會有很大的波動.也算是比較通用的方案了.
3樓：Arkadimon
我說個思路吧
首先，分庫不要簡單的按表分，改為按水平分庫，使用一些分布式資料庫軟體管理起來，這種情況下，大部分需要進行關聯的查詢，如果分片規則設計得當，都可以直接使用資料庫的能力直接進行處理
然後，就是剩下那一部分不在同乙個分片上的資料怎麼關聯，大部分情況下在上乙個策略的基礎上，進行軟體層面上的關聯，也都能解決了
最後，才是OLAP部分，一般實時性要求不會太高，隨便處理了
4樓：權哥SH
簡單回答主題，有乙個簡單可行的方案：用etl把各業務系統資料同步到資料倉儲然後做分析查詢，提供API為前台服務反哺業務系統——也就是現在流行的資料中臺。
什麼時候做微服務做到多微其實不重要也沒有標準答案，關鍵是你要在單體系統的時候就做好架構治理（模組化分層開發規範）、 做好物件導向設計（高內聚低耦合）、編織好單元測試安全網、做好devops流水線，然後當你們的業務發展起來了組織結構變複雜需要重組拆分了開發團隊超過100人難以在乙個單體工程上施展了，這時按照康威定律自然就浮現出了拆分微服務的輪廓，那會是乙個很自然不糾結的過程，因為彼時拆分的好處顯而易見（減少業務耦合降低溝通成本減少團隊發布節奏衝突和版本控制系統衝突），而成本和代價又可以承受（業務發展起來了有現金流有融資了可以投入專門資源做微服務基礎設施）。
所以微服務是個良藥也可以是毒藥，是殺手鐗也可以是屠龍之技，取決於是否在適合的時間和場景。
時機未到，就老老實實把單體系統做好， 不斷重構優化清理技術債，為微服務化做好準備打好基礎，就算最後沒做微服務也至少提高了現有系統的交付質量and效率。
說句不好聽的，如果連單體系統都駕馭不了越做越臃腫技術債高企，那你更駕馭不了微服務，妄想通過微服務化來改善架構治理無異於水中撈月（微服務的分布式架構會讓你的技術債爆發式增長加速專案崩潰），同時微服務可以讓原本質量很好的單體系統變得更好，殘酷的馬太效應在這裡也適用——強者更強弱者更弱。
5樓：文刀流
明明樓主問的是微服務架構如何解決連表查詢的問題, 為何最高票的答案讓問題變成了我司有必要上微服務嗎. 神煩這種答非所問的答案.
既然你們已經有關聯跨庫的需求了.可以這樣.
如果只是OLTP
查,分多個 api . 手動合. 如果有實時需求, 多買記憶體, 將資料整合扔 es 查.
增刪改事務, 上最終一致性事務解決方案. 比如通過訊息. 如果要求強一致性, 上 TCC. 如果你領域模型拆的合理，最終一致性是首選
如果是 OLAP, 也就是還需要大量計算才得到的結果的情況.
要求實時, 多買記憶體, 扔資料倉儲 , 跑 spark-stream
不要求實時, 跑 Hive 即可.
6樓：
解決方法：
不上微服務
2. 不拆分db，只拆分服務
3. 非要拆分db，可以曾加冗餘字段
4. 查詢的資料少，直接呼叫服務查詢，內網的速度可以接受5. CQRS，對查詢另外建檢視表，監聽相關表的增刪改事件，非同步更新，最終一致性
6. 實時性要求高的服務，實行同步更新
7樓：yaoyao
資料庫按領域拆分，適當冗餘一些業務邏輯無關字段，例如建立人姓名、客戶名稱之類，就可以消除很多聯表的問題。
服務的拆分不僅要按功能拆分，還需要考慮運維架構，例如需要穩定和需求變更多的，可以拆分為兩個服務。負載不同的，也可以拆分服務。
8樓：火皇煌
拆不拆看你們公司的體量和資料量，中小公司能簡單來就簡單來，拆成微服務並不是必須的，不要把大廠那一套照搬過來，架構越簡單也就意味著越穩定，出錯機率低，排查問題容易，拆成微服務後呼叫鏈增長，出錯的概率會增大。各有利弊，根據你們公司實際情況看怎麼權衡。
9樓：kimmking
首先，把業務服務分成兩部分，分別對待。
A類：一部分是實時的、針對客戶請求處理的部分。比如客戶下了乙個單，我們就需要把客戶資訊和訂單資訊，兩個庫關聯起來處理。
客戶不會很有耐心，所以需要我們的系統在秒級別做出處理結果的回應。好在客戶本身就是乙個特別簡單的資料劃分維度，或者說是客戶資訊、訂單資訊的關聯處理維度。
我們可以使用服務化的方式，把客戶資訊服務和訂單資訊服務，變成單獨部署的客戶中心UC和訂單中心OC，然後在需要呼叫他們的業務系統裡，直接使用UC和OC提供的API，通過userid或者orderid來或者資料，一般來說部署在內網的多個機器之間的呼叫在幾毫秒級別，完全可以不影響現有的使用者體驗，同時帶來微服務的其他諸般好處。
kimmking：00.什麼是微服務架構
微服務架構深度解析與最佳實踐
kimmking：梁桂釗《顛覆微服務認知：深入思考微服務的七個主流觀點》
kimmking：微服務架構設計中如何把握「微」度，需要考慮哪幾方面因素？
kimmking：有沒有講微服務架構比較不錯的書？
微服務架構下使用者服務被單獨抽離出來如何實踐？
10樓：有銘
明確的告訴你，沒有，我曾經非常困惑這類問題，直到某次有幸去大廠交流了一下，才發現他們拿微服務基本都做的是OLTP（聯機事務處理）類業務——最多涉及多個庫的表事務性寫入，通過最終一致性解決。而你說的這種聯表查詢，屬於OLAP（聯機分析處理）類業務，這型別業務，大廠的採取了兩個辦法解決：
1.專門有乙個微服務，背後有乙個專門的資料庫，通過某種同步機制。把客戶資訊和訂單表的資訊同步到這個庫，然後這個微服務就專門提供這類聯表查詢，適合實時性要求不高的分析場合。
2.實時要求高的場合，上大資料，流處理，同樣也是把客戶和訂單表的資料以流的方式進行計算得到你用關聯式資料庫必須聯表才能得到的資料。這種現在應用開始變多了。
從這點可以看出，微服務不是銀彈，資料庫拆分不是萬能的，有不適應的場合，而解決這個問題的方式無非是「空間換時間」。所以我是真的認為微服務不適合一些並不複雜的小型場景，這類一開始就能預估出規模的場景，一開始就上微服務，那就看你舍不捨得投資上基礎設施，來解決這種常見的OLAP需求了
11樓：Thomas Deng
因為微服務架構基本都是把各自服務對應資料庫分開，可以專門再做乙個服務用於將涉及連表操作的資料表存入其中，一旦需要連表檢索，就向那個服務發請求，該服務會將連表查詢得到的資料返回給呼叫方。
12樓：bluetrees
級聯查詢還比較簡單的，可以都弄到乙個庫裡面，專門做報表。
麻煩的是事務補償和資料鎖定，都木有通用的辦法，要按照業務內容見招拆招。
你這個例子裡面，客戶是緩變資料的概率很大，這個好辦了，就是把客戶資料到訂單系統再存乙份就好了。同步的辦法多的是，自己寫同步服務、資料庫事務日誌傳送、唯讀映象等等，多如牛毛。
但是訂單往往不是緩變資料，如果不是資料操作很密集的話，訂單也可以這樣處理，如果訂單處理很密集，又要聯合查詢，還是這招，但是資料庫之間的通道要專門設計，這個請諮詢你們的資料庫廠商，要麼就忍耐資料傳送比較慢。
我們的基礎資料往阿里雲的客戶推送都能忍受呢。每晚一次從客戶那裡蒐集資料形成報表也可以接受。
13樓：find goo
最麻煩的是查詢。
如果系統的表很多，相互關係，你可以使用動態構造json輸出的方式。
類似下面的資料庫查詢輸出html,只是格式改為json的。
這樣你不管用什麼sql都可以輸出json，不需要頻煩修改json輸出的model。
使用動態構建json，把下面類似的動態html輸出改成json格式，這樣可以方便發布介面了，也不用害怕join了。
14樓：
聽起來是你資料模型過於耦合，那麼其實不建議優先拆分DB。我覺得你在轉microservice的道路上可以一點一點來，先拆服務。
如果一定要拆db的話：
分享幾個我能想到的辦法：
稍微不那麼hackish，建乙個新的DB，做logical replication，把你這倆db都複製進去，然後根據你多閒從已拆分服務中讀，或者建新服務讀 （很多錢很多時間很想玩的話）
如果沒有時效性要求，建議複製到資料倉儲，整合之後分別在部署回源資料庫，這裡如果你在原來的連表查詢做很多分析類的資料就很有用了，可以在資料倉儲裡做一些processing
實在不行看看能不能重新做資料模型解耦
15樓：JimmyGao
為什麼要拆？核心收益
如何拆？領域如何劃分
拆完如何跨庫查詢？一般要非同步同步做冗餘方案，視場景分隔開準實時查詢和離線統計。99%以上的需求都能解決。
微服務不一定是好架構，能不拆就別拆了
16樓：Bird Frank
這個題目太大了，要好幾本書才能講清楚的那種大。
基本上這是乙個複雜業務系統的分析設計和微服務架構設計的問題。所以建議先看下相關的書，比如關於DDD的、關於企業系統架構的（Martin Fowler的那本）、以及微服務架構設計的（比如Micorservice Patterns，不是XX微服務實戰之類的）。學習的同時先思考乙個問題：
你們真的需要微服務嗎？
解決的多表連線查詢拆分微服務問題的大思路肯定是需要引入一定的資料冗餘。可能是在訂單和客戶表中冗餘一部分關聯表的資料、或者使用CQRS模式。
如何通俗的解釋一下微服務架構？
Eleven 我來試試這樣解釋夠不夠通俗。1 傳統架構又被稱之為單體架構，簡單三層理解的話就是UI層 業務邏輯 資料庫，啥事兒都在乙個程序裡面完成，省心省力但是擴充套件困難。2 然後隨著業務量增加，資料量累計，單體應用扛不住了，就會誕生如下的垂直拆分，每個系統還是單體架構 3 然後突然發現，這幾個子...
如何解決養殖中的臭氣汙染？
存在即合理 養豬場可以使用植物除臭劑除臭，前提是環境衛生管理的好，要不然使用除臭劑成本就比較大了。如果在衛生及時清理後再使用山美環境植物液除臭劑那效果是顯而易見的，可以間歇式噴灑，植物濃縮液，稀釋倍數大 森納斯環保 養殖中的臭氣可以用除臭劑來處理，當然很多除臭劑是不能用在養殖場上的，因為會傷害動物和...
如何解決贍養義務中的詐騙問題？？？
肥魚 親情和詐騙都已經掛在一起了，證明你們之間的關係的確是有很多問題。不妨先檢討一下到底你們之間能否有一次直接的溝通，把你的疑惑攤開來跟他說。當然如果你覺得再也無法信任他的話，不妨直接把錢給到你父親或者通過其他可信任的關係轉交給父親。但是我有點不明白的就是，你明知道他很有可能是騙錢，但是為什麼還多次...