Microsoft AZ-204: Azure 事件驅動和訊息解決方案 — 學習指南

By Laurynas Brazys · 6 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

屬於 Microsoft Azure Developer Associate AZ-204 — 學習指南. 使用經過驗證的解答練習： Microsoft 考試中心, 或參加限時模擬考試： ExamRoll.io.

概觀

Azure 的事件與訊息傳遞產品組合橫跨四種互補的服務：用於反應式事件處理的 Event Grid、用於高吞吐量串流擷取的 Event Hubs、用於企業級訊息傳遞與工作流程協調的 Service Bus，以及用於行動推播的 Notification Hubs。要精通這些服務，您必須了解每項服務的核心抽象概念、傳遞與重試語意、擴展模型，以及在典型的應用程式模式中（如發布/訂閱 (pub/sub)、命令處理、遙測資料擷取、裝置或使用者通知）何時該選擇哪一種服務。

Event Grid：主題、訂閱、結構描述、篩選與無效信件處理

Event Grid 是一個全託管、基於推送 (push-based) 的發布/訂閱 (pub/sub) 結構，用於處理離散事件。發布者將事件傳送到一個主題 (topic)；訂閱者在主題上註冊事件訂閱，並在支援的處理常式（如 HTTPS webhook、Azure Functions、Logic Apps、Service Bus、Storage Queues 和 Event Hubs）接收相符的事件。Event Grid 定義了兩種發布者模型。系統主題 (System topics) 是由 Azure 管理的主題資源，代表在您的訂閱或資源群組中發布事件的第一方 Azure 服務（例如，儲存體 blob 已建立、Key Vault 密鑰已輪替或 Resource Manager 事件）。自訂主題 (Custom topics) 是由使用者建立、讓您的應用程式發布事件所用的主題端點，讓您能在自己的服務與領域之間實現事件驅動模式。系統主題不需要任何發布者端的程式碼，並簡化了將 Azure 資源連接到反應式處理常式的過程；自訂主題則讓您能完全控制事件的合約與生命週期。

Event Grid 事件可以使用原生的 Event Grid 結構描述或 CloudEvents v1.0 規格。使用 Event Grid 結構描述時，每個事件都包含 id（唯一識別碼）、eventType（所執行的動作）、subject（支援篩選的階層式路徑）、eventTime (UTC)、data（承載資料）、dataVersion、metadataVersion 和 topic。CloudEvents 提供了一組標準化的屬性，如 id、source、type、time、subject 和 data。選擇 CloudEvents 有助於跨平台的互通性；Event Grid 結構描述則與源自 Azure 的事件保持一致，並提供對 subject 的豐富篩選功能。

事件訂閱定義了路由、傳遞選項與篩選器。基本篩選器包含事件類型納入，以及主旨的前綴/後綴 (subjectBeginsWith, subjectEndsWith)，這對於階層式資源命名非常有效率。進階篩選器可比對頂層事件或 data 內的欄位（例如，數值範圍比較、不區分大小寫的字串包含、布林值等於，以及陣列包含）。您可以組合使用篩選器，以進行精確的扇出 (fan-out) 控制，從而將下游工作與出口流量降到最低。

傳遞方式為推送，並具有至少一次 (at-least-once) 的語意。Event Grid 會以指數退避 (exponential back-off) 方式重試。您可以設定最大重試次數與事件的存留時間 (time-to-live)；當傳遞最終失敗或事件過期時，Event Grid 可以將事件寄送至無效信件 (dead-letter) 佇列，也就是您在訂閱上指定的 Blob Storage 容器。無效信件處理會保留承載資料與中繼資料，以供稽核或重新處理之用；如有需要，可使用獨立的程序來重新還原並重播事件。Webhook 端點會參與驗證交握 (validation handshake) 以證明所有權，而對於受限的網路環境，您可以優先選擇受控的 Azure 端點（Functions、Service Bus、Storage Queue），這些端點不需要對外公開，並且可以使用由 Azure AD 支援的授權機制。

Event Hubs：分割區、消費者群組、輸送量、擷取與可靠的取用

Event Hubs 以低延遲的方式擷取大量的遙測與日誌串流。資料會附加到分割區中，而分割區是獨立且有序的認可日誌。分割區在建立時就已選定，以平行化輸送量；生產者會指派一個分割區索引鍵來維持每個索引鍵的順序，而服務會將這些索引鍵雜湊到不同的分割區。多個讀取者可以平行處理分割區；在單一分割區內，順序性是有保證的。

消費者群組提供串流的獨立檢視，讓不同的處理應用程式可以各自維護其位置而互不干擾 (例如，一個即時異常偵測器和一個封存管線)。水平擴展讀取者需要進行分割區擁有權的平衡；SDK 的 EventProcessorClient 會協調跨執行個體的分割區指派與重新平衡。

標準層 (Standard tier) 中的輸送量單位 (TUs) 定義了容量：每個 TU 都享有傳入與傳出頻寬的配額。自動擴充 (Auto-inflate) 功能可以自動向上擴展 TU 以應對尖峰流量。進階版 (Premium) 使用具備專用運算資源和可預測延遲的處理單位 (Processing Units)。監控節流計量以驗證佈建是否充足。Event Hubs 在同一個端點上支援 Kafka 通訊協定，簡化了從 Kafka 用戶端進行的直接遷移 (lift-and-shift)，無需執行 brokers。

生產者可以使用 AMQP 或 HTTPS。AMQP (包含在 443 埠上的 AMQP-over-WebSockets) 提供多工、持續性的連線和高效率的批次處理，建議用於傳送和接收。HTTPS 適用於簡單或零星的傳送，但不支援接收；它不提供長輪詢 (long-polling)，而且會犧牲效率和流量控制。在受限制的企業網路中，AMQP-over-WebSockets 在通過典型的輸出代理伺服器時，仍能維持效能。

檢查點 (Checkpointing) 與位移管理對於確保正確性至關重要。每個事件在每個分割區中都有一個序號和一個位移。接收者會沿著串流前進，並在成功處理一批次資料後，將其位置設定檢查點到持久性儲存體中——通常是透過 EventProcessorClient 存到一個 Azure Blob Storage 容器。在重新啟動或容錯移轉時，處理器會從最後一個檢查點恢復，透過等冪處理常式 (idempotent handlers) 實現至少一次 (at-least-once) 的處理。如果沒有檢查點，消費者會從預設位置 (最新或最早) 開始，並冒著重複處理或略過事件的風險。

擷取 (Capture) 功能提供伺服器端封存，它會根據可設定的時間或大小視窗，自動將批次處理過的、僅附加的 Avro 檔案寫入 Azure Blob Storage 或 Azure Data Lake Storage Gen2。這免去了為冷路徑分析建立自訂批次處理器的需要，讓下游工具 (如 Spark、Synapse) 能夠取用相對於擷取管線具備精確一次 (exactly-once) 語意的不可變串流區段。

Service Bus 與 Queue Storage：命令、工作流程、工作階段與毒性訊息處理

Service Bus 是一個企業級的訊息代理人，適用於需要豐富傳遞保證的命令、工作流程和整合情境。佇列實作點對點傳訊；每個訊息由一個競爭消費者接收。帶有訂閱的主題可啟用發佈/訂閱模式：發佈者傳送到主題，而獨立的訂閱會根據規則接收副本。訂閱規則可以是 SQL 篩選器、相互關聯篩選器或布林值 true 篩選器，這些規則會計算每個訊息是否應被包含，並可透過動作新增或修改訊息屬性。

工作階段為相關訊息提供有序且獨佔的處理。對於屬於同一組的訊息（例如，訂單 123 中的所有步驟），請指派一個 SessionId。接收者接受工作階段鎖定，並為該工作階段按到達順序處理訊息，同時可選擇性地維護工作階段狀態，然後釋放工作階段以允許下一個消費者取得擁有權。這是在大規模環境下實現先進先出（FIFO）的首選模式。若沒有工作階段，則無法保證跨競爭消費者的訊息順序。

Service Bus 支援 PeekLock 和 ReceiveAndDelete 模式。PeekLock 是確保可靠性的預設模式：消費者在鎖定持續時間內鎖定一則訊息，處理它，然後透過 Complete 來結算它。如果處理失敗，消費者可以 Abandon（使其再次可用）、Defer（根據序號推遲到稍後再擷取），或 Dead-letter（將其移動到該實體獨立的無法投遞信件子佇列，並附上原因和錯誤描述）。ReceiveAndDelete 則是以可靠性換取輸送量，它在收到訊息後立即將其移除。

關鍵屬性控制著生命週期。存留時間（Time to Live, TTL）可以在實體層級設定預設值，並可由個別訊息覆寫；過期的訊息會根據設定被移至無法投遞信件佇列或被丟棄。鎖定持續時間控制訊息為處理而被鎖定的時間長度；SDK 可以在最大限制內為長時間的工作自動續訂鎖定。最大傳遞計數是針對每個佇列或訂閱設定的；在達到該傳遞嘗試次數（因 Abandon 或鎖定遺失）後，訊息會被自動移至無法投遞信件的佇列（DLQ）。操作人員會清空 DLQ 以進行診斷或使用修正邏輯進行重新處理。

Azure Queue Storage 是一個更簡單、大規模可擴展的佇列服務，具有 REST 介面，最適合用於基本解耦、高扇出和成本敏感的工作負載。它提供至少一次傳遞、一個在處理期間隱藏訊息的可見度逾時，以及每個訊息的 TTL（預設為 7 天，可設定，包括永不過期）。個別訊息的大小有限，且不提供如工作階段、交易、順序保證、重複偵測、無法投遞信件子佇列和進階篩選器等功能。當需要處理簡單的背景工作且要求以低成本實現非常高的輸送量時，請選擇 Queue Storage。當您需要複雜的路由（主題/訂閱）、透過工作階段實現的 FIFO、排程傳遞、延遲處理、跨實體的交易、重複偵測視窗、AMQP 支援，或者當整合可靠性和治理至關重要時，請選擇 Service Bus。一個常見的模式是透過 Event Grid 或 Queue Storage 扇入輕量級事件，並在 Service Bus 上協調業務關鍵的命令和狀態轉換。

Notification Hubs：推播路由與平台憑證管理

Notification Hubs 是一個跨平台的推播引擎，能大規模管理裝置註冊，並將目標式通知路由到 Apple (APNs)、Android (FCM)、Windows (WNS) 及其他平台。應用程式使用標籤 (tag) 和標籤運算式 (tag expression) 來註冊裝置，從而實現精準的受眾選擇（例如：user:42 AND region:emea OR topic:promotions）。範本 (template) 讓您能傳送單一、本地化的承載 (payload)，再由特定平台的轉譯器擴展，這能減少伺服器邏輯，並以最少的後端分支實現每個裝置的個人化。安裝 (Installation) 模型透過將平台控制代碼 (platform handle)、標籤和範本封裝在每個裝置的單一資源中，簡化了裝置的生命週期管理。

平台憑證管理是可靠交付的核心。對於 APNs，您可以上傳憑證式或權杖式憑證（包含 Key ID、Team ID 和 .p8 權杖），並為每個中樞或命名空間選擇沙箱或生產環境端點，以隔離不同環境。對於 FCM，請設定合適的伺服器憑證（對於 HTTP v1，請使用具備 OAuth2 範圍的 Google 服務帳戶）。對於 WNS，請註冊應用程式以取得 Package SID 和用戶端密鑰。憑證會定期輪換；請安排輪換時程並監控回饋通道，以找出無效的裝置控制代碼。Notification Hubs 使用 SAS 進行從您的應用程式伺服器到中樞層級的驗證，而 Azure AD 角色則保護管理操作。請使用標籤慣例來分割多租戶應用程式，並透過排程或批次推播來調節傳送量，以符合平台配額。

實際問題情境

星巴克正在推出全球行動點餐體驗，該體驗必須在訂單準備好時通知顧客、可靠地處理咖啡師的工作流程步驟，並分析設備遙測資料以進行主動維護。

使用 Event Grid 連接事件驅動的訂單生命週期

建立一個自訂的 Event Grid 主題 OrderEvents，並發布如 OrderPlaced、PaymentAuthorized 和 OrderReady 等離散的領域事件。使用像 /stores/{storeId}/orders/{orderId} 這樣的主體路徑，以實現按店家進行的前綴篩選。設定訂閱：一個訂閱到 Service Bus 主題以進行工作流程處理，另一個訂閱到 Azure Function 以進行輕量級的資料擴充。選擇 Event Grid 是因為其低延遲的扇出 (fan-out)、結構正規化 (CloudEvents) 以及能避免不必要下游叫用的高效篩選能力。

使用 Service Bus 主題和會話協調咖啡師的工作流程

定義一個 Service Bus 主題 Orders，並為每個處理階段（準備、交貨）設定訂閱，每個訂閱都對 eventType 使用關聯或 SQL 篩選器。將命令作為訊息發布，並設定 SessionId = {orderId}，以保證每個訂單的先進先出 (FIFO)。消費者使用 PeekLock 並搭配自動鎖定續約，成功時執行 Complete；發生暫時性故障時，Abandon 會觸發重試；發生持續性故障或遇到毒訊息時，Max delivery count 會將它們移至無效信件佇列 (DLQ) 以供後續檢查。針對特定階段訊息設定的 TTL 可防止店家關門後處理過時的工作。選擇 Service Bus 是因為其有序、可靠的命令處理、豐富的結算選項以及基於規則的發布/訂閱模型。

使用 Event Hubs 擷取和封存設備遙測資料

佈建一個 Event Hub Telemetry，提供足夠的分區以按 deviceId 進行平行處理，並啟用自動擴展 TU (auto-inflate TUs) 以吸收尖峰流量。裝置閘道器透過 AMQP-over-WebSockets 傳送資料，以高效地穿透公司代理伺服器。使用 EventProcessorClient 搭配 Blob Storage 檢查點，近即時地運行異常偵測和警報。啟用擷取至 ADLS Gen2 的功能，以建立不可變的 Avro 封存檔，支援在 Synapse 中進行離線分析。選擇 Event Hubs 是因為其持續的高吞吐量擷取能力、持久的位移 (offset) 以及簡易的冷路徑匯出。

使用 Notification Hubs 進行目標式推播通知

使用安裝 (Installation) 模型註冊行動裝置，為每個裝置加上 user:{userId}、store:{storeId} 和平台標籤。為 iOS 上傳 APNs 權杖憑證，為 Android 上傳 FCM 服務帳戶；分開開發和生產中樞以隔離憑證和回饋。當 OrderReady 事件到達時，Azure Function 會向 Notification Hubs 傳送單一範本通知，指定給標籤 user:{userId} AND store:{storeId}。選擇 Notification Hubs 是因為其平台無關的路由、標籤運算式以及全球規模的集中式憑證管理。

確保可觀測性和彈性

設定 Event Grid 的無效信件功能，將信件導向 Blob 容器，以保留無法投遞的事件以供稽核和重播。監控 Service Bus 的 DLQ，並提供一個操作員工作流程來分類和重新排入已修正的訊息。透過指標追蹤 Event Hubs 的消費者延遲，以驗證檢查點設定，並在待辦項目增加時擴展處理器。這種組合提供了端到端的持久性：至少一次的交付，並為異常情況提供重播路徑，同時保持正常路徑的快速和成本效益。

這個架構清晰地分離了各個關注點：Event Grid 驅動反應式協調，Service Bus 保證工作流程的正確性和順序性，Event Hubs 處理大規模的持續遙測，而 Notification Hubs 則以最低的後端複雜度，傳遞精準、特定平台的客戶通知。

← Azure API Management · 所有領域 · Azure 快取、CDN 和效能 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →