問(wèn)題描述

微服務(wù)架構(gòu)中，每個(gè)服務(wù)都有自己的獨(dú)立數(shù)據(jù)庫(kù)。然而現(xiàn)在有個(gè)需求，需要生成一張實(shí)時(shí)的報(bào)表，該報(bào)表包含兩個(gè)服務(wù)的數(shù)據(jù)。如服務(wù)A，服務(wù)B。B中僅包含A的主鍵id作為關(guān)聯(lián)。而此報(bào)表的搜索條件包含A服務(wù)實(shí)體中的字段也包含B服務(wù)實(shí)體中的字段。

現(xiàn)有方案1、如果搜索條件中包含A的條件，則先去服務(wù)A中搜索，得到所有結(jié)果的主鍵，在服務(wù)B中使用where A.id IN （ids） 再次查詢想法：當(dāng)A.id數(shù)量龐大時(shí)，這個(gè)查詢極其緩慢！ 而A.id數(shù)量龐大的情況很多

2、使用搜索引擎

想法：感覺(jué)殺雞用牛刀

請(qǐng)教各位大牛有更好的方案嗎

問(wèn)題解答

瀉藥

如果是線上業(yè)務(wù)數(shù)據(jù)(OLTP)，那么方案一是微服務(wù)的標(biāo)準(zhǔn)做法。如果線上要頻繁做這種關(guān)聯(lián)的查詢，就說(shuō)明兩個(gè)服務(wù)(及其兩個(gè)庫(kù))的耦合非常嚴(yán)重，那當(dāng)初何必要把它們拆開(kāi)來(lái)呢？

如果是分析報(bào)表，那就屬于OLAP范疇了，方案二確實(shí)是一種可取的方案。如果使用搜索引擎覺(jué)得殺雞用牛刀的話，不妨試試在從庫(kù)上做各種報(bào)表分析操作，比如線上的A庫(kù)和B庫(kù)都實(shí)時(shí)同步到一個(gè)只讀庫(kù)中，然后在只讀庫(kù)里JOIN一下就搞定了。

微服務(wù)的一個(gè)設(shè)計(jì)原則是業(yè)務(wù)沒(méi)有關(guān)聯(lián)的服務(wù)拆開(kāi)成單獨(dú)的服務(wù)，你這個(gè)業(yè)務(wù)之間有交叉了。

其實(shí)這種問(wèn)題在微服務(wù)中很常見(jiàn),比如說(shuō)需要通過(guò)商品上的一些信息查詢訂單,訂單和商品分別屬于兩個(gè)微服務(wù),該類問(wèn)題的解決方案除了你自己兩種方案,還有

將數(shù)據(jù)聚合放入數(shù)據(jù)倉(cāng)庫(kù),實(shí)時(shí)聚合A和B中的數(shù)據(jù)放入另外一個(gè)庫(kù)中(不一定是mysql,也可以是Hbase),報(bào)表拉的數(shù)據(jù)都從數(shù)據(jù)倉(cāng)庫(kù)中拉去

表設(shè)計(jì)的時(shí)候適當(dāng)冗余一些字段,就如你說(shuō)的在B上可預(yù)見(jiàn)性的冗余一些A的字段

方法1有一個(gè)很致命的缺點(diǎn),一旦涉及到分頁(yè),這種方式必定不可行.具體采用哪種方案,還是需要根據(jù)你的數(shù)據(jù)對(duì)應(yīng)的數(shù)量級(jí)來(lái)決定,如果對(duì)應(yīng)的數(shù)據(jù)量不是很大,可以采用方法1,如果速度比較慢,可以多開(kāi)幾個(gè)線程分批撈相應(yīng)的數(shù)據(jù)(id數(shù)量太多分批拉,批量查詢都是可以減少超時(shí)情況和時(shí)間的有效解決方案);如果數(shù)據(jù)量很大,建議采用數(shù)據(jù)倉(cāng)庫(kù)的方式,采用數(shù)據(jù)倉(cāng)庫(kù)的主要好處是,對(duì)主庫(kù)不會(huì)產(chǎn)生壓力,因?yàn)榫酆媳淼漠a(chǎn)生可以通過(guò)Binlog來(lái)獲取;因?yàn)閳?bào)表還是屬于離線數(shù)據(jù)的范疇,如果真的需要像訂單查詢那樣實(shí)時(shí),效率很高期間還伴隨著狀態(tài)的該表,并且搜索條件巨多無(wú)比,那么搜索引擎是一個(gè)很好的選擇所以,可以根據(jù)實(shí)際情況采用方法1和方法3

生成報(bào)表這樣的需求就不應(yīng)該放在業(yè)務(wù)數(shù)據(jù)庫(kù)系統(tǒng)中，你可以在后端做一套o(hù)tter匯聚庫(kù)，實(shí)時(shí)同步多個(gè)服務(wù)的數(shù)據(jù)進(jìn)來(lái)，然后在這個(gè)匯聚庫(kù)中你想怎么玩就怎么玩