最近在工作上使用到一些採用事件驅動架構（Event-driven architecture）概念的 Azure 服務，稍微整理了三種服務的簡單比較，並在這邊分享其中一個服務「Azure Event Grid」給大家。 

Azure Event Grid

匯流事件的中樞。開發者可以很簡易的建立一個事件驅動的系統。Azure 提供的多種服務當中也採用了 Event Grid 作為事件觸發的處理架構。

 採用發布與訂閱模式（publish-subscribe model）來處理事件，處理流程可以簡單歸納為：

1. 觸發事件
2. 來源（Source）發布（Publish）事件至主題（Topic）
3. 主題依據篩選條件，將事件傳遞至訂閱（Subscription）
4. 訂閱將事件傳遞給處理者（Handler），處理者接收並處理事件；若有需要，訂閱會進行重試機制

 核心概念

  1. 事件（Event）

足以描述「發生了什麼」的輕量資料，一般包含：來源、類型、發生時間、ID 等等。

依據不同事件類型，也會包含特定的資訊，例如：Azure Blob Storage 發生新增檔案的事件時，會附加檔案最後異動時間的資料。

Event Grid 支援了數種事件模型，下述為 Event Grid 標準的事件模型。

// Azure Event Grid event schema:

{
    "topic": "string",
    "subject": "string",
    "id": "string",
    "eventType": "string",
    "eventTime": "string",
    "data": {
        // object-unique-to-each-publisher
    },
    "dataVersion": "string",
    "metadataVersion": "string"
} 

  2. 事件來源（Event source）與發布者（Publisher）

事件來源指事件發生的地方。

發布者指發布事件的人或組織。例如：微軟等等。

一般而言，一個事件來源會發生一至多種不同事件類型的事件。例如：Azure Blob Storage 會觸發新增、刪除 Blob 等事件。

  3. 主題（Topic）

接收發布者發布事件的地方。

分為系統主題（System topic）與自訂主題（Custom topic）兩種。

一般而言，在小型系統與架構中，一個主題會接收所有類型的事件，依據篩選將事件傳遞至不同事件訂閱；在大型系統與架構中，一個主題會對應一種類型的事件。

發布者會從事件來源傳遞事件至一至多個主題。

  4. 事件訂閱（Event subscription）

事件會藉由篩選（Filter）傳遞至各訂閱。常見的篩選條件：事件類型（Event type）、主旨（Subject）等等。

由 Azure 多種服務 Events 頁籤所建立的事件訂閱中，訂閱的事件類型由 Azure 提供。

  5. 事件處理者（Event handler）

事件送達的地方，事件處理者會對事件進行更多的處理動作。

Event Grid 會保證事件正確地送達至事件處理者。

支援設定事件的生存時間（Event Time to Live），Azure 並不希望事件停留在事件訂閱中太久，最大停留時間為 24 小時。

支援設定最大嘗試傳遞次數（Max Event Delivery Attempts），若事件已經傳遞超過最大嘗試傳遞次數，Event Grid 會將事件儲存至 Azure Blob Storage。

例如：事件處理者是 Webhook，事件會嘗試重新傳遞，直到 Webhook 成功回傳 200 狀態碼。

常見的事件處理者：

• Webhook
  
• Azure Function
  
• Event Hubs
  
• Relay Hybrid Connection
  
• Service Bus: Queue/Topic
  
• Storage Account: Queue Storage
  
• Logic App
  

 Azure 上的事件與訊息服務

在 Azure 上提供了三種事件與訊息相關的服務：

1. Azure Event Grid
2. Azure Event Hubs
3. Azure Service Bus

 事件與訊息的差異

在 Azure 中，Azure 將事件與訊息區分為兩種不同的概念。

Event Grid 與 Event Hubs 處理的是事件，Service Bus 處理的是訊息。

  1. 事件（Event）

事件是某種條件或是狀態改變（發生了什麼）的輕量通知，僅包含足以描述此改變的資料，不包含觸發事件的實際資料。例如：檔案新增時觸發事件，事件內容不包含檔案本身，僅描述什麼檔案觸發了這個事件。

事件通常是彼此相關且有順序性的，處理者在處理事件時，須要考量多個事件之間的相關性。

一般發布者送出事件後，並不會知道事件是如何被處理、以及期望事件的處理結果。

  2. 訊息（Message）

訊息是完整的原始資料，包含觸發時的原始實際資料。例如：檔案新增時觸發訊息，訊息內容會包含檔案本身。

一般發送者送出訊息後，會希望知道訊息是如何被處理、以及期望訊息的處理結果。

 小結

以上是簡單的整理與分享，希望對有需要的人有所幫助，若有發現錯誤煩請指教，非常感謝。