事件驅動架構是由 產生事件資料流程的事件產生者 ，以及 接聽事件的事件取用者 所組成。
事件會近乎即時地傳遞，因此取用者可以在事件發生時立即回應事件。 生產者與取用者分離，生產者不知道哪些消費者正在傾聽。 取用者也會彼此分離，每個取用者都會看到所有事件。 這與 競爭取用者 模式不同，其中取用者會從佇列提取訊息，而訊息只會處理一次（假設沒有錯誤）。 在某些系統中，例如 IoT，事件必須擷取到非常高的磁片區。
事件驅動架構可以使用 發佈/訂閱 （也稱為 pub/sub ）模型或事件資料流程模型。
發行/訂閱：傳訊基礎結構會追蹤訂閱。 發行事件時，它會將事件傳送給每個訂閱者。 收到事件之後，就無法重新執行事件，而且新的訂閱者看不到事件。
事件串流：事件會寫入至記錄。 事件會嚴格排序 (在分割區內) 並具有持久性。 用戶端不會訂閱資料流程，而是用戶端可以從資料流程的任何部分讀取。 用戶端會負責其在資料流中的位置移動。 這表示用戶端可以隨時加入，而且可以重新執行事件。
在取用者端，有一些常見的變化：
簡單事件處理。 事件會立即觸發取用者的動作。 例如，您可以使用 Azure Functions 搭配服務匯流排觸發程式，讓函式在訊息發佈至服務匯流排主題時執行。
基本事件相互關聯 。 取用者需要處理少量的離散商務事件，通常由某些識別碼相互關聯，並保存先前事件的某些資訊，以在處理稍後的事件時使用。 NServiceBus 和 MassTransit 等 程式庫支援此模式。
複雜事件處理。 取用者會使用 Azure 串流分析等技術來處理一系列事件，尋找事件資料中的模式。 例如，您可以彙總一段時間的內嵌裝置讀數，並在移動平均超過特定閾值時產生通知。
事件串流處理。 使用資料流程平臺，例如 Azure IoT 中樞 或 Apache Kafka，作為內嵌事件的管線，並將其饋送至串流處理器。 資料流處理器會採取行動來處理或轉換資料流。 應用程式的不同子系統可能會有多個資料流處理器。 這種方法非常適合 IoT 工作負載。
事件的來源可能位於系統外部，例如 IoT 解決方案中的實體裝置。 在此情況下，系統必須能夠擷取資料來源所需數量和輸送量的資料。
在上述邏輯圖表中，每種類型的取用者都會顯示為單一方塊。 在實務上，通常有多個取用者的實例，以避免取用者成為系統中的單一失敗點。 可能需要多個實例來處理事件的磁片區和頻率。 此外，單一取用者可能會處理多個執行緒上的事件。 如果事件必須依序處理，或只需要一次語意，這可能會造成挑戰。 請參閱 最小化協調 。
使用此架構的時機
- 多個子系統必須處理相同的事件。
- 具有最短時間延遲的即時處理。
- 複雜的事件處理，例如一段時間的模式比對或匯總。
- 大量資料和高速度，例如 IoT。
福利
- 生產者和消費者被分離。
- 沒有點對點整合。 將新的取用者新增至系統很容易。
- 取用者可以在到達時立即回應事件。
- 高度可調整且分散式。
- 子系統具有事件資料流程的獨立檢視。
挑戰
- 保證傳遞。 在某些系統中，特別是在 IoT 案例中，保證事件傳遞非常重要。
- 依序處理事件，或只處理一次。 每個取用者類型通常會在多個實例中執行，以進行復原和延展性。 如果事件必須依序處理（在取用者類型內），或 未實作等冪訊息處理 邏輯，這可能會造成挑戰。
- 跨服務協調訊息。 商務程式通常牽涉到多個服務發佈和訂閱訊息，以在整個工作負載中達成一致的結果。 工作流程模式，例如 編舞模式 和 Saga Orchestration ，可用來可靠地管理各種服務之間的訊息流程。
其他考量
- 要包含在事件中的資料量可能是影響效能和成本的重要考慮。 將處理所需的所有相關資訊放在事件本身可以簡化處理常式代碼，並儲存其他查閱。 將最少的資訊量放在事件中，就像幾個識別碼一樣，可減少傳輸時間和成本，但需要處理常式代碼來查閱它所需的任何其他資訊。 如需詳細資訊，請參閱 此部落格文章 。
- 雖然要求只對要求處理元件可見，但工作負載中的多個元件通常會看到事件，即使這些元件不是或不是用來取用這些元件也一樣。 以「假設缺口」思維操作，請留意您在事件中包含的資訊，以防止非預期的資訊暴露。
相關資源
- 社群討論影片 ，說明在編舞與協調流程之間選擇的考慮。