場景描述
在微服務架構中，每個微服務負責自己的數據庫，微服務A是不允許直接連接微服務B的數據庫進行操作的。
現在有2個微服務，一個是訂單服務，一個是用戶服務。
有一個數據報告的需求：生成一份包含用戶信息的訂單報告。
這就需要獲取2個服務中的數據，進行連接匯總。
如何構建這個數據報告的服務呢？
方案1 直接連接數據庫
直接連接訂單服務、用戶服務的數據庫，獲取所需的數據，拿到后進行加工處理即可。
非常簡單，但有明顯的問題。
首先是破壞了上面所說的微服務的那個原則，直接去連別人的數據庫，太粗暴了。
還有一個更嚴重的問題，如果訂單服務和用戶服務的數據庫表結構變化了咋辦？
報告服務必須跟着一起改變，敏感度太高。
方案2 數據匯聚
不直連數據了，調用這兩個服務的 REST API 接口獲取想要的數據。
解決了上個方案的問題，但此方法最大的問題是性能差。
報告服務需要最新的數據，就會經常訪問這2個服務，隨着數據規模的增加，3個服務的性能都會越來越低。
方案3 批量拉取數據
為報告服務建立一個自己的數據庫，使用一個定時程序，批量從2個服務的數據庫中拉數據，存入自己的數據庫。
解決了上個方案的問題，性能明顯提升，但好像又回到了第一個方案的問題，破壞了微服務的原則，而且對數據表結構的變動極其敏感。
好處是因為有了自己的數據庫，方便多了，性能更好了。
方案4 事件推送模型
訂單服務、用戶服務中，數據表更后，產生一個事件，發布到消息系統中（例如 kafka），報告服務訂閱相關主題，把接收到的數據寫入自己的數據庫。
好處：
-
松耦合，業務服務和報告服務沒有調用關系，不管是業務接口層，還是數據庫層。
-
數據一致性好，准實時，業務服務數據表更后立即發送事件消息，報告服務可以快速消費。
-
性能好，數據吞吐量增加后，報告服務可以增加處理事件的 worker，提供處理能力。
-
擴展性好，方便以后添加更多的數據處理需求，例如實時分析，而且，以后可能不止是做訂單報告，可能會對更多的業務系統數據進行分析，到時，新服務只需把自己的數據變更事件發送到消息系統中即可。
翻譯整理自：
推薦閱讀
- 圖解 Kubernetes
- ZooKeeper 並不適合做注冊中心
- kafka 中 zookeeper 具體是做什么的？
- Postman 的替代品來了
- Redis Cluster 會丟數據嗎？
- 阿里開源的分布式事務框架 Seata
