場景描述
在微服務架構中，每個微服務負責自己的數據庫，微服務A是不允許直接連接微服務B的數據庫進行操作的。
現在有2個微服務，一個是訂單服務，一個是用戶服務。
有一個數據報告的需求：生成一份包含用戶信息的訂單報告。
這就需要獲取2個服務中的數據，進行連接彙總。
如何構建這個數據報告的服務呢？
方案1 直接連接數據庫
直接連接訂單服務、用戶服務的數據庫，獲取所需的數據，拿到後進行加工處理即可。
非常簡單，但有明顯的問題。
首先是破壞了上面所說的微服務的那個原則，直接去連別人的數據庫，太粗暴了。
還有一個更嚴重的問題，如果訂單服務和用戶服務的數據庫表結構變化了咋辦？
報告服務必須跟着一起改變，敏感度太高。
方案2 數據匯聚
不直連數據了，調用這兩個服務的 REST API 接口獲取想要的數據。
解決了上個方案的問題，但此方法最大的問題是性能差。
報告服務需要最新的數據，就會經常訪問這2個服務，隨着數據規模的增加，3個服務的性能都會越來越低。
方案3 批量拉取數據
爲報告服務建立一個自己的數據庫，使用一個定時程序，批量從2個服務的數據庫中拉數據，存入自己的數據庫。
解決了上個方案的問題，性能明顯提升，但好像又回到了第一個方案的問題，破壞了微服務的原則，而且對數據表結構的變動極其敏感。
好處是因爲有了自己的數據庫，方便多了，性能更好了。
方案4 事件推送模型
訂單服務、用戶服務中，數據表更後，產生一個事件，發佈到消息系統中（例如 kafka），報告服務訂閱相關主題，把接收到的數據寫入自己的數據庫。
好處：
松耦合，業務服務和報告服務沒有調用關係，不管是業務接口層，還是數據庫層。
數據一致性好，準實時，業務服務數據表更後立即發送事件消息，報告服務可以快速消費。
性能好，數據吞吐量增加後，報告服務可以增加處理事件的 worker，提供處理能力。
擴展性好，方便以後添加更多的數據處理需求，例如實時分析，而且，以後可能不止是做訂單報告，可能會對更多的業務系統數據進行分析，到時，新服務只需把自己的數據變更事件發送到消息系統中即可。
寫在最後
歡迎大家關注我的公衆號【風平浪靜如碼】，海量Java相關文章，學習資料都會在裏面更新，整理的資料也會放在裏面。
覺得寫的還不錯的就點個贊，加個關注唄！點關注，不迷路，持續更新！！！