Microsoft AZ-305: 整合與訊息傳遞架構 — 學習指南

By Laurynas Brazys · 11 August 2026 · #microsoft #az-305 #certification #exam-prep #study-guide

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

總覽

Azure 上的整合與訊息傳遞架構，其關鍵在於為指令、事件和資料移動語意選擇正確的服務；針對可靠性、順序性和規模進行設計；以及安全地整合混合式系統。核心建構模組包括：用於提供豐富代理器功能的企業級訊息傳遞服務 Azure Service Bus、用於反應式事件路由的 Azure Event Grid、用於高吞吐量串流擷取的 Azure Event Hubs，以及用於簡單佇列的 Storage Queues。圍繞這些核心服務的還有：用於流程自動化的 Azure Logic Apps、用於治理和開發者體驗的 API Management、用於 ETL/ELT 的 Azure Data Factory、用於防火牆友善的本地連線的 Azure Relay，以及用於行動推播的 Azure Notification Hubs。一個健全的設計會為工作選擇合適的服務，明確地建立合約與失敗模式的模型，並在適當之處應用編排 (orchestration) 或協同 (choreography) 模式。

Azure 上的訊息傳遞與事件處理

Azure Service Bus 是企業級的代理器，適用於需要有序傳遞、交易、群組內 FIFO 以及無法投遞信件處理的指令與工作流程。佇列 (Queues) 在一個生產者和一個競爭的消費者群組之間提供點對點的訊息傳遞。主題 (Topics) 則啟用 pub/sub 模式，允許多個獨立的訂閱，這些訂閱可以使用類 SQL 的篩選器和動作來篩選與路由訊息。訊息工作階段 (Message sessions) 將相關訊息歸類在一個 sessionId 之下，從而實現每個群組的 FIFO 和具狀態的處理；工作階段鎖定 (session lock) 確保一次只有一個消費者處理一個工作階段。當超過最大傳遞次數、TTL 到期或被明確標示為無法投遞時，無法投遞信件佇列 (Dead-letter queues) 會擷取這些有害訊息 (poison messages)，以便進行隔離和後續檢查；每個佇列或訂閱都有一個 $DeadLetterQueue 子佇列。交易 (Transactions) 允許在同一個命名空間內跨實體執行不可部分完成的傳送/接收/完成操作，例如，確保只有在後續訊息成功傳送後，原始訊息才會被完成 (send-via 支援跨實體的工作流程)。

Azure Event Grid 是一個全託管的事件路由器，專為反應式、推送式模式而設計。它使用原生的 Event Grid 結構描述或 CloudEvents 1.0。事件訂閱 (Event subscriptions) 的目標端點可以是 Functions、Logic Apps、Service Bus、Event Hubs、WebHooks 和 Storage Queues 等，並可透過主旨和進階篩選器來減少雜訊。傳遞會以指數退避方式重試；訂閱支援可設定的重試原則 (最大傳遞嘗試次數和事件存留時間)，並可將無法傳遞的事件存入儲存體帳戶作為無法投遞的信件。交握驗證 (Handshake validation) 可保護 WebHook 端點的安全，而受控識別 (managed identities) 則簡化了對 Azure 端點的發布和傳遞過程。

Azure Event Hubs 透過分割區記錄 (partitioned logs) 來大規模擷取遙測和串流資料。分割區 (Partitions) 提供平行處理能力，並確保分割區內的順序性；選擇一個分割區索引鍵 (partition key) 來保持相關事件的順序。分割區的數量決定了規模，且建立後無法減少，因此應為未來的吞吐量規劃大小。消費者群組 (Consumer groups) 為不同的應用程式提供事件串流的獨立視圖，而不會互相干擾彼此的位移 (offsets)。擷取 (Capture) 功能會根據時間/大小視窗，以近乎即時的方式將資料持續卸載到 Azure Blob Storage 或 Data Lake Storage，通常使用 Avro 格式，這使得批次分析得以進行而不會影響擷取過程。內建的結構描述登錄 (Schema Registry) 儲存 Avro/JSON 結構描述，並提供版本控制和相容性原則，讓生產者和消費者能夠安全地驗證和演進合約。

Storage Queues 提供簡單、具成本效益的至少一次傳遞 (at-least-once delivery)，具備不可見逾時 (invisibility timeouts) 以及透過訊息 TTL 和由應用程式管理的有害訊息處理所實現的基本無法投遞信件功能。它們缺乏交易、工作階段和進階路由功能，但非常適合用於基本的解耦和低成本的大規模扇出 (fan-out)。

如何選擇：

• 當指令、工作流程和整合情境需要 FIFO (透過工作階段)、交易、延遲、重複偵測和無法投遞信件稽核時，請使用 Service Bus。
• 當需要來自 Azure 服務或自訂應用程式的輕量級、推送式、扇出通知，並具備細緻的篩選和近乎即時的反應能力時，請使用 Event Grid。
• 當需要高吞吐量的串流遙測和日誌擷取，並有多個獨立的消費者和下游分析需求時，請使用 Event Hubs。
• 當只需要簡單的生產者/消費者解耦，不需要進階代理器功能，且成本單純性是首要考量時，請使用 Storage Queues。

整合、API 與混合式連線

Azure Logic Apps 提供受控的工作流程自動化，並具備數百個連接器。在「取用」(Consumption，多租戶) 模式中，您依動作付費，具備自動擴展與多租戶連接器；適合突發性使用。在「標準」(Standard，單一租戶) 模式中，它在 Functions 執行階段上運行，支援具狀態/無狀態工作流程、更高的輸送量、自訂連接器與在程序內執行的內建連接器、容器化、本機開發，以及 VNET/私用端點整合；適合需要企業級隔離與可預測容量的場景。整合服務環境 (Integration Service Environment, ISE) 是一個舊版的專用環境，用於私有網路與資料落地；新的設計通常偏好使用具備 VNET 整合的 Logic Apps Standard，或部署到 App Service Environment v3。

Azure API Management (APIM) 為 API 提供一個抽象化與治理層。原則 (Policies) 可應用於傳入 (inbound)、後端 (backend) 和傳出 (outbound) 階段，以強制執行跨領域考量，例如 validate-jwt、rate-limit-by-key、quota、set-header、retry、cache-lookup/store，以及用於動態路由的 set-backend-service。產品 (Products) 將一個或多個 API 分組、綑綁原則行為，並可發佈給特定群組。訂用帳戶 (Subscriptions) 為每個取用者或每個產品核發金鑰，以計量與控制存取；金鑰可以輪替並與配額綁定。開發人員入口網站 (developer portal) 實現了自助式探索、文件、試用與上線工作流程，而自我裝載閘道 (self-hosted gateway) 則允許混合式控制平面/邊緣部署，適用於地端或其他雲端環境。

Azure Relay 能夠實現對地端服務的傳入連線，而無需開啟傳入的防火牆連接埠。混合式連線 (Hybrid Connections) 使用透過 TLS 443 的 WebSockets 進行通用的雙向通訊端通訊，此通訊由地端向外發起，並由用戶端連向 Relay，適用於 HTTP 及封裝在 WebSockets 上的任意協定。WCF Relay 透過 Relay 公開地端的 WCF 端點 (NetTcp/HTTP)，具備傳輸層級或訊息層級的安全性與宣告式存取；它非常適合需要以安全、防火牆友善的方式公開現有 WCF 服務的場景。

Azure Notification Hubs 是一個跨平台的推播代理，它抽象化了平台通知系統 (PNS)，如適用於 iOS 的 APNs、Android 的 FCM、Windows 的 WNS、Amazon 的 ADM。後端註冊裝置或安裝時，可使用標籤 (tags) 與範本 (templates) 來大規模地鎖定目標並個人化通知。每個 PNS 都需要平台認證：APNs 的 p8 金鑰或憑證、FCM 的伺服器金鑰/認證、WNS 的套件 SID/密碼。Notification Hubs 處理廣播 (fan-out)、節流 (throttling) 與權杖管理，使應用程式程式碼保持與 PNS 無關。

資料移動與串流分析

Azure Data Factory (ADF) 跨混合式資產協調資料整合。整合執行階段 (Integration runtimes, IRs) 為活動託管運算資源：Azure IR 用於 Azure 內的無伺服器複製與資料流；自我裝載 IR (Self-hosted IR) 用於私有網路內的資料移動/運算，無需開啟傳入連接埠；Azure-SSIS IR 則用於將 SSIS 套件直接遷移 (lift-and-shift) 至受控叢集。管線 (Pipelines) 透過控制流程 (相依性、迴圈、分支、觸發程序) 與參數化來協調活動，以供重複使用。對應資料流 (Mapping Data Flows) 提供大規模、無程式碼、以 Spark 為基礎的轉換，並具備結構描述漂移處理與分割區控制；當轉換複雜但您希望使用受控運算時，可使用此功能。連結服務 (Linked services) 定義來源、接收器與運算的連線中繼資料與認證；資料集與資料流的來源/接收器會參考這些服務，從而實現安全的重複使用與 RBAC。

Event Hubs 透過 Capture 功能將資料寫入永續性儲存體來與分析服務整合，接著 Azure Synapse 或 Databricks 就可以用微批次 (micro-batches) 的方式處理 Avro 檔案。結構描述登錄 (Schema Registry) 透過集中化合約，簡化了串流作業中的反序列化與演進，避免了生產者與取用者之間脆弱、隱含的型別。

可靠性與事件驅動模式

設計可靠性始於明確的故障處理。Service Bus 為每個實體提供無效信件佇列 (dead-letter queue)；取用者應監控並分類處理 DLQ，並可選擇性地自動轉寄到分析佇列。使用重複偵測和冪等 (idempotent) 處理常式來避免重複處理。利用交易來以不可部分完成 (atomically) 的方式結算接收的訊息並送出 outbox 訊息，並使用會話 (session) 來針對每個業務實體進行循序處理，同時能跨會話進行擴展。Event Grid 的重試原則使用指數退避 (exponential backoff) 搭配可設定的限制；設定將無效信件存入 Storage 以提供可稽核性，並建立重播工具。Event Hubs 保證至少一次 (at-least-once) 傳遞；透過 SDK（或 Azure Functions 觸發程序）進行檢查點 (checkpointing) 設定，可確保追蹤每個分割區/取用者群組的進度。Storage Queues 則依賴您明確實作的可見度逾時 (visibility timeout) 和毒藥訊息 (poison message) 模式。

事件驅動架構通常使用編舞 (choreography) 或協調流程 (orchestration)。編舞模式將協調工作分散到各個服務，由服務對等節點的事件做出反應。它鬆散耦合、可擴展，且對部分故障具有彈性，但可能變得難以視覺化和治理，且補償措施會分散各處。協調流程模式將流程控制集中在一個協調器中，例如 Azure Durable Functions、Logic Apps 或工作流程引擎，這改善了可觀測性、逾時/補償邏輯，以及需要人為介入的步驟，但代價是與協調器之間更緊密的耦合。Saga 模式用來實作長時間執行的多步驟交易，它使用補償動作而非兩階段提交。在編舞模式中，每個服務監聽領域事件並視需要發出補償；在協調流程模式中，協調器會叫用活動，並在發生故障或逾時時觸發補償。在 Azure 上，可使用 Durable Functions（具狀態的協調流程、重試、逾時、補償模式）搭配 Service Bus 來實作 Sagas，以達成可靠的命令傳遞；或使用 Logic Apps Standard 來處理穩健的企業工作流程並利用其內建的連接器。

實務問題情境

Contoso 零售業正在現代化其訂單處理流程，該流程橫跨地端 ERP、電子商務網站、行動應用程式及下游分析系統。此解決方案必須支援合作夥伴通知、即時遙測分析、安全的地端存取和行動推播，並對付款和庫存作業有嚴格的排序與補償要求。

1. 擷取與命令工作流程

• 使用 Azure Service Bus 主題來處理訂單命令。透過訂閱來區隔處理流程（付款、庫存、運送）。啟用以 OrderId 為鍵的訊息會話，以保證每個訂單的先進先出 (FIFO) 與單一並行性。理由：Service Bus 提供了循序、可靠的業務工作流程所需的會話、交易和無效信件處理功能。

2. 協調流程與補償

• 使用 Azure Durable Functions 實作 Saga 模式。活動會呼叫支付閘道、預留庫存並建立出貨；若失敗，補償動作則會退款或補回庫存。在交易範圍內使用 Service Bus 觸發程序和輸出，以不可部分完成的方式處理傳入的訊息並發布後續訊息。理由：集中式協調流程簡化了逾時、重試和補償的處理，同時保有訊息代理的可靠性。

3. 事件驅動的通知

• 將領域事件（OrderPlaced、OrderShipped）發布到 Azure Event Grid 自訂主題。合作夥伴和內部應用程式可使用主旨前綴的篩選器進行訂閱。設定將無效信件存入 Storage 帳戶，並設定有次數上限的重試原則。理由：Event Grid 提供低延遲的推送、細緻的篩選以及無效信件稽核功能，適用於廣泛的扇出 (fan-out) 情境。

4. 遙測串流與分析

• 將點擊流和應用程式遙測資料傳送到 Azure Event Hubs，使用 8 個以使用者會話為鍵的分割區。啟用 Capture 功能，每 5 分鐘或 100 MB 將資料擷取到 Data Lake Storage。在 Schema Registry 中註冊 Avro 結構描述，並強制執行結構描述相容性。理由：Event Hubs 的擷取規模可獨立於取用者擴展；Capture 功能將分析作業解耦；Schema Registry 維護了合約的紀律。

5. 資料整合

• 使用 Azure Data Factory 搭配地端的 Self-hosted Integration Runtime 來安全地擷取 ERP 資料，並使用 Azure IR 將整理好的資料放入 Synapse。建立管線和對應資料流，以處理 SCD（緩慢變動維度）並使用 Event Hubs Capture 檔案進行資料擴充。理由：ADF 透過受控的運算資源和經由連結服務治理的連線，來協調混合式資料的移動與轉換。

6. API 與合作夥伴治理

• 使用 Azure API Management 作為所有面向合作夥伴的端點的前端。公開訂單狀態和 webhook 註冊的 API。套用原則：使用

undefined

驗證合作夥伴發行的權杖，使用

undefined

對合作夥伴進行更嚴格的節流，使用

undefined

將流量路由到現有的 Logic Apps 而不需修改程式碼。為需要訂閱和金鑰的合作夥伴發布產品；透過開發人員入口網站讓他們上線。理由：APIM 強制執行安全性、節流，並提供自助式上線流程，無需動到後端邏輯。

7. 工作流程自動化與連接器

• 使用 Azure Logic Apps Standard 進行後勤辦公室的自動化（例如，寄送電子郵件、更新 Dynamics），利用其內建的連接器和 VNET 整合功能。理由：單一租用戶的效能、私有連線能力以及企業級的連接器，簡化了與 SaaS 和企業營運 (line-of-business) 應用程式的整合。

8. 混合式連線

• 透過 Azure Relay WCF Relay 公開選擇性的地端 ERP 服務（適用於現有的 WCF 端點），並透過 Hybrid Connections 公開輕量級的 HTTP/WebSocket 應用程式，以避免變更傳入的防火牆規則。理由：Relay 提供由外連線啟動的安全連線，無需處理 VPN 的複雜性。

9. 行動推播

• 透過 Azure Notification Hubs 傳送出貨更新，使用標籤進行裝置/使用者區隔，並使用範本進行本地化。設定 APNs 權杖憑證和 FCM 金鑰。理由：Notification Hubs 抽象化了不同 PNS（推播通知服務）之間的差異，並能擴展推播的傳遞規模。

此設計將每個需求對應到專門建構的服務：Service Bus 用於可靠的命令，Durable Functions 用於協調的 Sagas，Event Grid 用於推播通知，Event Hubs + Capture + Schema Registry 用於串流分析，ADF 用於混合式 ETL/ELT，APIM 用於治理，Logic Apps 用於企業自動化，Relay 用於地端存取，以及 Notification Hubs 用於行動互動。

← 安全架構與零信任 · 所有領域 · 監控、成本最佳化與維運 →

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

瀏覽 Microsoft →