選擇 Azure Event Grid

  • 10 分鐘

許多應用程式都會使用公開訂閱模型通知分散式元件有問題發生或有物件變更。 假設您有一個音樂分享應用程式，其 Web API 在 Azure 中執行。 當使用者上傳新歌曲時，您需要通知全球在使用者裝置上安裝所有行動應用程式，且對該內容類型有興趣的使用者。

在此結構中，聲音檔發行者不需了解對所分享音樂有興趣的任何訂閱者。 此外，我們想要有可擁有多名訂閱者的一對多關聯性，讓訂閱者選擇是否對這首新歌曲感興趣。 Azure Event Grid 是此種架構的完美解決方案。

什麼是 Azure 事件方格？

Azure 事件方格是在 Azure Service Fabric 上執行的完全受控事件路由服務。 事件方格會從不同來源 (例如 Azure Blob 儲存個體帳戶或 Azure 媒體服務) 將事件分散給不同的處理常式 (例如 Azure Functions 或 Webhook)。 事件方格的建立是為了讓您更輕鬆地在 Azure 上建置事件架構和無伺服器應用程式。

事件方格支援大部分的 Azure 服務做為發行者或訂閱者，並可搭配協力廠商服務使用。 它提供可動態調整的低成本傳訊系統，讓發行者通知訂閱者相關的狀態變更。 下圖顯示的 Azure 事件方格會接收多個來源的訊息，並根據訂用帳戶將其散發給事件處理常式。

Azure 事件方格中有數個概念可將來源連接到訂閱者：

  • 事件：發生了什麼事。
  • 事件來源：事件發生位置。
  • 主題：發行者傳送事件的端點。
  • 事件訂閱：用來路由事件的端點或內建機制，有時會路由到多個處理常式。 處理常式也會使用訂用帳戶，以智慧方式篩選內送事件。
  • 事件處理常式：對事件做出回應的應用程式或服務。

下圖顯示位於多個事件來源與多個事件處理常式之間的 Azure 事件方格。 事件來源會將事件傳送至事件方格，而事件方格會將相關的事件轉寄給訂閱者。 事件方格會使用主題來決定要將哪些事件傳送至哪些處理常式。 事件來源會標記每個具有一或多個主題的事件，而事件處理常式會訂閱其感興趣的主題。

Diagram of various event sources sending messages as topics to the Event Grid which in turn sends messages to subscribing event handlers.

什麼是事件？

事件是透過事件方格傳遞的資料訊息，描述發生的情況。 每個事件都是獨立的、最大可達 64 KB，並包含以事件方格所定義之結構描述為基礎的數個資訊片段：

[
  {
    "topic": string,
    "subject": string,
    "id": string,
    "eventType": string,
    "eventTime": string,
    "data":{
      object-unique-to-each-publisher
    },
    "dataVersion": string,
    "metadataVersion": string
  }
]
欄位 描述
topic 事件來源的完整資源路徑。 事件方格提供此值。
subject 發行者定義事件主旨的路徑。
id 事件的唯一識別碼。
eventType 此事件來源已註冊的事件類型之一。 您可以針對此值建立篩選條件，例如 CustomerCreated、BlobDeleted、HttpRequestReceived 等。
eventTime 事件產生的時間，以提供者的 UTC 時間為準。
data 與事件類型相關的特定資訊。 例如，在 Azure 儲存體中建立新檔案的相關事件含有該檔案相關詳細資料，例如 lastTimeModified 值。 或者，事件中樞事件含有「擷取」檔案的 URL。 這是選用欄位。
dataVersion 資料物件的結構描述版本。 發行者會定義結構描述版本。
metadataVersion 事件中繼資料的結構描述版本。 「事件方格」會定義最上層屬性的結構描述。 事件方格提供此值。

提示

事件方格會傳送事件，指出有狀況發生或有項目變更。 不過，已變更的「實際物件」不屬於事件資料的一部分。 相反地，通常會傳遞 URL 或識別碼來參考已變更的物件。

什麼是事件來源？

事件來源負責將事件傳送至事件方格。 每個事件來源都與一或多個事件類型相關。 例如，Azure 儲存體是 Blob 建立事件的事件來源。 IoT 中樞是裝置建立事件的事件來源。 您的應用程式是您定義之自訂事件本身的事件來源。 稍後將詳細探討事件中樞。

Azure 事件方格具有事件發行者的概念，這通常會和事件來源搞混。 事件發行者是決定將事件傳送至事件方格的使用者或組織。 例如，Microsoft 會發行數個 Azure 服務的事件。 您可以從您自己的應用程式發行事件。 裝載 Azure 外部服務的組織可以透過事件方格發行事件。 事件來源是針對該發行者產生事件的特定服務。 雖然這兩個字詞稍有不同，但基於本單元的目的，我們將交互使用「發行者」和「事件來源」，來代表將訊息傳送給事件方格的實體。

什麼是事件主題？

事件主題將事件分類成群組。 主題是以公用端點表示，而且是事件來源傳送事件的「目的地」。 在設計應用程式時，您可以決定要建立多少個主題。 較大型解決方案會為每個類別的相關事件建立一個自訂主題，而較小型解決方案可能會將所有事件傳送至單一主題。 例如，請考慮使用應用程式來傳送與修改使用者帳戶和處理訂單有關的事件。 任何事件處理常式不太需要兩種類別的事件。 建立兩個自訂主題，並讓事件處理常式訂閱其感興趣的自訂主題。 事件訂閱者可以從特定主題篩選出他們想要的事件類型。

主題可分為系統主題和自訂主題。

系統主題

系統主題是由 Azure 服務提供的內建主題。 您不會在您的 Azure 訂用帳戶中看見系統主題，因為發行者擁有主題，但是您可以訂閱這些主題。 若要訂閱，可以提供與您想要接收事件之資源有關的資訊。 只要您可存取資源，就可以訂閱其事件。

自訂主題

自訂主題是應用程式和協力廠商的主題。 當您建立或獲指派可存取自訂主題時，您會在訂用帳戶中看見該自訂主題。

什麼是事件訂閱？

事件訂閱定義事件處理常式想要接收的主題事件。 訂用帳戶也可依其類型或主旨篩選事件，讓您可以確保事件處理常式只接收相關事件。

什麼是事件處理常式？

事件處理常式 (有時稱為事件「訂閱者」) 是可從事件方格接收事件的任何元件 (應用程式或資源)。 例如，Azure Functions 可以執行程式碼以回應新增至 Blob 儲存體帳戶的新歌曲。 訂閱者可以決定要處理哪些事件，而事件方格會在發生新事件時有效率地通知每個感興趣的訂閱者；不需要任何輪詢。

事件來源類型

下列 Azure 資源類型可以產生事件：

支援系統主題的 Azure 服務

以下是一些支援系統主題的 Azure 服務。 如需支援系統主題的 Azure 服務完整清單，請參閱 Azure 事件方格中的系統主題。

  • Azure 訂用帳戶和資源群組：訂用帳戶和資源群組會產生與 Azure 中管理作業相關的事件。 例如，當使用者建立虛擬機器時，此來源會產生事件。
  • 容器登錄：Azure Container Registry 服務可在登錄中新增、移除或變更映像時產生事件。
  • 事件中樞：事件中樞可用來處理及儲存來自各種資料來源的事件，通常是相關記錄或遙測。 事件中樞可在擷取檔案時產生事件，並傳送至事件方格。
  • 服務匯流排：服務匯流排可在有作用中訊息但沒有作用中接聽程式時產生事件。
  • 儲存體帳戶：儲存體帳戶可在使用者新增 Blob、檔案、資料表項目或佇列訊息時產生事件。 您可以使用 Blob 帳戶和一般用途 V2 帳戶作為事件來源。
  • 媒體服務：媒體服務會裝載視訊和音訊媒體，並提供媒體檔案的進階管理功能。 媒體服務可在啟動或完成視訊檔案的編碼工作時產生事件。
  • Azure IoT 中樞：IoT 中樞會與 IoT 裝置通訊並從中收集遙測資料。 它可在每次這類通訊抵達時產生事件。

如需詳細資訊，請參閱 Azure 事件方格中的系統主題。

自訂主題

您可以使用 REST API 或透過 Java、GO、.NET、Node、Python 和 Ruby 的相關 Azure SDK，來產生自訂事件。 例如，您可以使用 Azure App Service 的 Web Apps 功能建立自訂事件。 當背景工作角色從儲存體佇列選取訊息時，就會發生此種情況。

這個與 Azure 內不同事件來源的深度整合會確保事件方格可散發與幾乎任何 Azure 資源相關的事件。

事件處理常式

Azure 中的下列物件類型可以接收及處理 Event Grid 中的事件：

  • Azure Functions：在 Azure 中執行的自訂程式碼，不需要明確設定主機虛擬伺服器或容器。 當您想要撰寫事件的自訂回應程式碼時，您可以使用 Azure 函數作為事件處理常式。
  • Azure Logic Apps：使用 Logic Apps 來實作商務程序，以處理事件方格事件。 在此情節中，您不會明確建立 Webhook。 當您設定邏輯應用程式來處理事件方格中的事件時，會自動為您建立 Webhook。
  • Webhook：Webhook 是實作推送結構的 Web API。 您也可以使用 Azure 自動化 Runbook 來處理事件。 Webhook 透過使用自動化 Runbook，支援事件的處理。 您會為 Runbook 建立 Webhook，然後使用 Webhook 處理常式。
  • 事件中樞：從事件方格解決方案收到事件的速度比處理事件的速度更快時，請使用事件中樞。 事件位於事件中樞內之後，應用程式就可以依自己的排程處理事件中樞的事件。
  • 服務匯流排：您可以使用服務佇列或主題，作為事件方格的事件處理常式。
  • 儲存體佇列：使用佇列儲存體來接收需要提取的事件。 若執行中的流程太過冗長導致回應時間過久，您可以使用佇列儲存體。 藉由將事件傳送至佇列儲存體，應用程式即可按照自己的排程提取並處理事件。
  • Microsoft Power Automate：Power Automate 也會裝載工作流程，但對於非技術人員來說佇列儲存體使用起來更方便。

如需詳細資訊，請參閱事件處理常式。

您是否應該使用「事件方格」？

當您需要下列功能時，請使用「事件方格」：

  • 簡易性：在事件方格中將來源連接到訂閱者相當簡單。
  • 進階篩選：訂閱者可以密切控制他們從某個主題所接收的事件。
  • 展開傳送：您可以針對相同的事件和主題訂閱不限數目的端點。
  • 可靠性：「事件方格」針對每個訂用帳戶最多會嘗試傳遞事件 24 小時。
  • 依事件支付：只需就您傳輸的事件數目來付費。

「事件方格」是一個簡單但多用途的事件散發系統。 您可以使用其向訂閱者傳遞離散事件，讓訂閱者迅速可靠地接收這些事件。 我們還有一個傳訊模型要檢查；如果想要傳遞大型的事件資料流該如何？ 在此案例中，事件方格不是很好的解決方案，因為它的設計是一次傳遞一個事件。 於是，我們需要考慮另一個 Azure 服務：事件中樞。