事件驅動的架構模式-雲原生架構設計快速入門

事件驅動的架構由生成事件流的事件生成者和偵聽事件的事件使用者組成 。

事件可幾乎實時發送，是以使用者可在事件發生時立即做出響應。 生成者脫離使用者 — 生成者不知道哪個使用者正在偵聽。 使用者之間也能彼此脫離，且每個使用者都能看到所有事件。 這與使用者競争模式不同，在此模式中，使用者從隊列中拉取消息，且消息可以一次或多次消費。 在某些系統中（例如 IoT），必須大量引入事件。

事件驅動的架構可以使用釋出/訂閱模式或事件流模式。

• 釋出/訂閱：消息傳遞基礎結構會跟蹤訂閱。 事件釋出後，它會将事件發送給每位訂閱者。 事件在接收後，便無法重播，新訂閱者也看不見此事件。
• 事件流式處理：事件會寫入日志。 事件是（在分區中）經過嚴格排序的，而且具有持久性。 用戶端不會訂閱流，但是用戶端可以讀取該流的任何部分。 用戶端負責提升它在流中的位置。 這意味着用戶端可以随時加入，并可以重播事件。

在使用者端，有一些常見的變化：

• 簡單事件處理。 事件會立即觸發使用者中的某項操作。
• 複雜事件處理。 使用者使用各公有雲雲端工具或開源Spark、Storm 、Flink之類的技術處理一系列事件，尋找事件資料中的模式。 例如，如果移動平均超過特定門檻值，便可聚合在某個時間範圍内從嵌入式裝置讀取的資訊，并生成通知。
• 事件流處理。 使用者使用各公有雲雲端工具或 Kafka、RocketMQ、RabbitMQ 等資料流平台作為管道引入事件并将其饋送到流處理器。 此流處理器可處理或轉換流。 不同應用程式子系統可能有多種流處理器。 此方法非常适合 IoT 工作負荷。

事件可能來源于系統之外，例如 IoT 解決方案中的實體裝置。 在這種情況下，系統必須能夠以資料源需要的容量和吞吐量來引入資料。

在上面的邏輯圖中，每種類型的使用者都顯示為單個框。 實際情況中通常有多個使用者執行個體，可避免使用者成為系統中的單點故障。 處理事件的容量和頻率可能還需要多個執行個體。 此外，單個使用者可以處理多個線程上的事件。 如果事件必須有序處理或需要恰好一次語義，這可能會帶來挑戰。 請參閱本部落格關于”減少協調架構設計原則“相關文章。

何時使用此架構

• 多個子系統必須處理相同的事件。
• 延遲時間最短的實時處理。
• 複雜事件處理，如模式比對或時間範圍内的聚合。
• 大量且快速的資料，如 IoT。

優點

• 生成者和使用者相脫離。
• 無點到點內建。 容易向系統添加新使用者。
• 使用者在事件發生時便可立即響應。
• 具有高縮放性，分布廣泛。
• 子系統具有獨立的事件流視圖。

挑戰

• 有保證的傳遞。 在某些系統中，尤其是在 IoT 方案中，保證資料傳遞至關重要。
• 按順序或者“恰一次”處理事件。 每種使用者類型通常都在多個執行個體中運作，以提供複原能力和可伸縮性。 如果必須按順序（在使用者類型中）處理事件，或處理邏輯不是幂等的，就會帶來挑戰。

其他注意事項

• 要包括在事件内的資料量可能是影響性能和成本的重要考慮因素。 将處理所需的全部相關資訊放入事件本身可以簡化處理代碼并儲存其他查找。 将最少的資訊放入事件（例如幾個辨別符）可減少傳輸時間和成本，但需要處理代碼來查找它所需的任何其他資訊。