微服務架構中如何快速構建一個數據報告服務？

場景描述

在微服務架構中，每一個微服務負責本身的數據庫，微服務A是不容許直接鏈接微服務B的數據庫進行操做的。

如今有2個微服務，一個是訂單服務，一個是用戶服務。

有一個數據報告的需求：生成一份包含用戶信息的訂單報告。

這就須要獲取2個服務中的數據，進行鏈接彙總。

如何構建這個數據報告的服務呢？

方案1 直接鏈接數據庫

直接鏈接訂單服務、用戶服務的數據庫，獲取所需的數據，拿到後進行加工處理便可。

很是簡單，但有明顯的問題。

首先是破壞了上面所說的微服務的那個原則，直接去連別人的數據庫，太粗暴了。

還有一個更嚴重的問題，若是訂單服務和用戶服務的數據庫表結構變化了咋辦？

報告服務必須跟着一塊兒改變，敏感度過高。

方案2 數據匯聚

不直連數據了，調用這兩個服務的 REST API 接口獲取想要的數據。

解決了上個方案的問題，但此方法最大的問題是性能差。

報告服務須要最新的數據，就會常常訪問這2個服務，隨着數據規模的增長，3個服務的性能都會愈來愈低。

方案3 批量拉取數據

爲報告服務創建一個本身的數據庫，使用一個定時程序，批量從2個服務的數據庫中拉數據，存入本身的數據庫。

解決了上個方案的問題，性能明顯提高，但好像又回到了第一個方案的問題，破壞了微服務的原則，並且對數據表結構的變更極其敏感。

好處是由於有了本身的數據庫，方便多了，性能更好了。

方案4 事件推送模型

訂單服務、用戶服務中，數據表更後，產生一個事件，發佈到消息系統中（例如 kafka），報告服務訂閱相關主題，把接收到的數據寫入本身的數據庫。

好處：

• 鬆耦合，業務服務和報告服務沒有調用關係，無論是業務接口層，仍是數據庫層。

• 數據一致性好，準實時，業務服務數據表更後當即發送事件消息，報告服務能夠快速消費。

• 性能好，數據吞吐量增長後，報告服務能夠增長處理事件的 worker，提供處理能力。

• 擴展性好，方便之後添加更多的數據處理需求，例如實時分析，並且，之後可能不止是作訂單報告，可能會對更多的業務系統數據進行分析，到時，新服務只需把本身的數據變動事件發送到消息系統中便可。

寫在最後

歡迎你們關注個人公衆號【風平浪靜如碼】，海量Java相關文章，學習資料都會在裏面更新，整理的資料也會放在裏面。

以爲寫的還不錯的就點個贊，加個關注唄！點關注，不迷路，持續更新！！！