六種經常使用的微服務架構設計模式 第四種模式

第四種模式：分層API架構上事件驅動的狀態管理

事件驅動並非一個新的設計模式。許多ESB最初的設計模式就是一個事件驅動系統。當在微服務體系上實施事件驅動架構時，它可以提供一些強大的抽象。事件驅動系統一般使用某種類型的隊列（相似於面向消息的系統），可是圍繞隊列所傳遞內容的設計和行爲，強制執行一個標準；具體來講，就是事件。

人們常常將事件驅動模式與其餘模式相混淆，所以在事件驅動模式中涵蓋了大量的設計。嚴格地說，事件是關於過去發生的，具備相關表明性狀態和時間戳的東西。事件容許接收它的服務經過按順序重放事件來重建狀態的物化視圖。然而，在許多實現中，每每將事件（已經發生了的事情）與命令（讓某件事情發生）混淆在一塊兒。若是事件和命令不進行區分的話，架構設計的可預測性是有缺陷的。也就是說，不能否認，事件驅動的設計模式優於面向消息的方法（由於事件驅動的設計更爲具體）；可是因爲事件驅動的設計模式缺少一致性，在實現中每每會出現問題。可是，鼓勵並執行一致標準的團隊會發現，事件驅動的設計模式可以在微服務體系結構中工做得很好。

問題：

爲了確保系統內數據的完整性，須要複製關鍵業務事件，以便在微服務或數據存儲之間進行同步。

解決方案：

使用常見的事件抽象來表示系統中的發生變化的組件。

應用：

當業務發生改變時，將其封裝成過去時的事件，併發送給相關方。業務中的更改就是發送和處理這些事件的產物。

影響：

一、增長複雜性，由於這種模式讓狀態以一種新的方式更改和移動。

二、不提供任何標準模式，實現多是不一致的，除非創建並實踐統一的標準。

三、對於在發生故障時如何處理數據衝突或重建狀態，不提供任何具體的解決方案。

目標：

一、內聚性：因爲其標準化的特性，事件驅動架構很是容易使用和理解。

二、可伸縮性：事件驅動的設計模式須要更深層次的技術決策（如何發送/處理/存儲事件？以及重傳？），可是在這種模式下可伸縮性是可實現的。

三、更改的速度：會受到更具內聚性的架構影響，若是沒有依賴性分析，管理手段有點過於依賴團隊的知識和運氣。

主要特色：

一、異步通訊機制將帶來高效的IPC（Inter-Process Communication，進程間通訊）。

二、喪失了設計的靈活性，取而代之的是可預測的行爲。

三、經過特定的一致性模型，提升了數據一致性和狀態管理能力；任何給定的狀態都是事件的重構四、因爲與面向消息設計模式的類似性，在事件與命令混合的地方可能會出現混淆。

五、該模式具有合理的可操做性以及有效的可擴展性。

六、該模式在具有一致性能力時有很強的內聚力，但內聚力每每隨時間推移而變弱。

分層API架構上事件驅動的狀態管理模式如何與現有系統、SOA或API共存？

事件驅動系統能夠與現有系統共存，但這兩個系統之間每每須要一個「轉換層」，這個「轉換層」跨越體系結構中事件驅動部分與非事件驅動部分的邊界。本質上，事件驅動系統在其架構內部使用一致的語言，其架構外部的任何內容都須要轉換（輸入或輸出）才能參與進來。分層API架構上事件驅動的狀態管理模式提供了一種清晰的方法，將體系結構中的事件驅動部分與傳統集成和企業系統分離開來，但這確實意味着，您傾向於使用事件驅動的微服務建立「新」功能，這些微服務能夠在其餘地方更新，或與邊界外的系統和API同步。