【轉】 微服務架構之事件驅動架構

原文：https://blog.csdn.net/jacks_sure/article/details/52537886

 

 

事件源方法有以下的優勢： 
- 事件即狀態，發佈事件就是在更新狀態，所以自然具備原子性，而且不會出錯 
- 因爲存儲的是事件，而不是域對象，所以避免了對象關係抗阻不匹配的問題（object‑relational impedance mismatch problem） 
- 因爲存儲了全部的業務狀態更新事件，所以能夠經過事件回放推斷出任一時間點的業務實體狀態

事件源方法也有如下這些缺點： 
- 要實現一個可靠和高性能的事件倉庫並非一件容易的事情 
- 應用代碼須要根據事件倉庫的 API 進行重寫 
- 事件倉庫只直接支持經過主鍵查詢業務實體，所以對於複雜視圖的查詢比較困難（能夠經過CQRS方法解決，具體參見下文）

 

命令操做仍然經過各服務的 API 以更新事件列表的方式進行，而查詢操做則經過一個統一的視圖查詢服務（View Query Service）完成。

根據存儲在事件倉庫中的事件集合，能夠計算獲得每一個業務實體的狀態，這些狀態以物化視圖（Materialized View）的方式存儲在一個數據庫中。當有新的事件產生時，也一樣會自動更新視圖。這樣，視圖查詢服務就能夠像查詢普通的數據庫數據同樣實現各類查詢場景。具體的設計可參考下圖所示：

結論

在微服務架構中，每一個微服務都有其私有數據存儲，不一樣的微服務可能使用不一樣的數據庫。這種架構帶來便利的同時，也給分佈式數據管理帶來挑戰，其中最大的挑戰就是在實現跨服務的業務邏輯時，如何保持服務之間的數據一致性。