Microsoft AZ-204: Azure Functions 和無伺服器運算 — 學習指南

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

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

總覽

Azure Functions 是一種無伺服器運算服務，專為事件驅動和短時間執行的工作負載進行了最佳化。它將基礎架構抽象化，讓您能專注於撰寫程式碼來回應來自 HTTP 端點、佇列、blob、資料變更摘要和串流服務的事件。您可以選擇一個託管方案來管理擴展、定價和冷啟動行為；透過宣告式繫結將您的程式碼繫結到觸發程序和資料來源；並可選擇性地使用 Durable Functions 來組合長時間執行、可靠的工作流程。強大的組態設定、可重複的部署，以及透過 Application Insights 實現的深度可觀測性，共同完善了這個平台，使其適用於生產等級的系統。

託管方案、擴展與冷啟動

選擇託管方案會決定執行的特性和成本。

Consumption 方案：
- 擴展與定價： 按執行次數和資源消耗量付費。平台會根據事件自動向外擴展。閒置時，執行個體數量會縮減至零。
- 執行限制： 對於非 HTTP 的函式，函式逾時時間可設定長達 10 分鐘；由於客戶端連線的關係，HTTP 函式的實際逾時時間較短。
- 冷啟動： 在閒置一段時間後，或是在向外擴展、需要初始化新執行個體時，會發生冷啟動。啟動時間取決於語言、相依套件和應用程式的大小。
- 網路/功能： 預設支援公用網路。與 Premium 方案相比，功能集有限（例如，無 VNET 整合）。不提供部署位置 (Deployment slots)。
Premium 方案：
- 擴展與定價： 根據事件進行擴展，但會維持「預熱」的執行個體以消除冷啟動。根據作用中和預熱執行個體所分配的核心秒數和記憶體計費。
- 執行限制： 執行時間幾乎無限制（受 HTTP 客戶端限制）。建議用於對延遲敏感或較繁重的工作負載。
- 冷啟動緩解： 預熱的執行個體能讓執行環境保持在「熱」的狀態。您可以控制每個方案的預熱執行個體數量，從而在高載流量下提供可預測的延遲。
- 網路/功能： 支援 VNET 整合、私人端點、更大的執行個體大小和部署位置 (deployment slots)。
Dedicated (App Service) 方案：
- 擴展與定價： 在已佈建的 App Service 執行個體上執行，並採用手動或自動擴展規則。無論使用與否，您都需要為底層的 App Service 方案付費。
- 執行限制： 平台對背景執行沒有強加的逾時限制。當您已有閒置的 App Service 容量或需要一致的效能時，此方案是理想選擇。
- 冷啟動緩解： 啟用「Always On」功能以保持應用程式載入。不會縮減至零；執行個體會保持溫熱狀態。

對於成本最佳化的零星工作負載，請選擇 Consumption 方案；對於需要低延遲和 VNET 的場景，請選擇 Premium 方案；當需要與現有的 App Service 容量整合或需要完全控制時，請選擇 Dedicated 方案。若要實現超低延遲，可使用帶有預熱執行個體的 Premium 方案，或啟用 Always On 的 Dedicated 方案，以減少冷啟動。您可以透過精簡相依套件、使用 run-from-package 部署方式，以及延遲初始化客戶端，來進一步將冷啟動的影響降到最低。

觸發程序與繫結

函式由觸發程序啟動，並透過繫結與資料互動。觸發程序定義了函式如何以及何時執行。繫結以宣告方式連接到外部服務以進行輸入/輸出，無需使用命令式的 SDK 程式碼。

常見的觸發程序：

HTTP 觸發程序：為 REST 風格的 API 或 webhook 公開端點。授權層級包括 Anonymous、Function 和 Admin，透過金鑰或平台驗證強制執行。對於長時間執行的任務，需考慮冪等性與逾時；必要時可卸載到佇列或 Durable Functions。
計時器觸發程序：基於 CRON 的排程，每個應用程式（每個計時器）在單一執行個體上執行。使用具備時區設定的 NCRONTAB 運算式。非常適合維護、輪詢和清理工作。
Azure Storage Queue 觸發程序：回應佇列中的訊息。在達到清除佇列計數閾值後，支援使用 -poison 佇列進行有害訊息處理。可透過 host.json 設定批次大小、可見性逾時和並行性。
Azure Blob Storage 觸發程序：透過結合輪詢和 Event Grid 通知，對 blob 的建立/更新事件作出反應。使用路徑模式來界定容器和前置詞的範圍。需了解最終一致性以及大型 blob 上傳的重試行為。
Azure Event Hubs 觸發程序：消耗具備檢查點功能的高吞吐量事件串流。設定分割區並行性、批次大小和預先擷取以提升吞吐量。適用於遙測和串流處理，並在每個分割區內保持順序。
Azure Service Bus 觸發程序：支援佇列或主題訂閱。設定 maxConcurrentCalls、預先擷取和自動完成行為。無效信件佇列會擷取超過傳遞嘗試次數的訊息，以供後續檢查。
Azure Cosmos DB 觸發程序：監聽變更摘要中的插入和更新。其擴展性與實體分割區的數量相關；確保佈建足夠的 RU。使用租用集合來協調跨執行個體的擴展。

繫結：

輸入繫結：將資料提供給函式，例如 blob 內容、表格實體、Cosmos DB 文件或佇列訊息的中繼資料。在 .NET 中，由屬性（例如 [BlobInput]）或 function.json 定義繫結；在其他語言中，設定是宣告式的。
輸出繫結：無需 SDK 即可寫入資料，例如將訊息加入佇列、建立 blob、傳送到 Event Hub/Service Bus 或寫入 Cosmos DB。函式可以有多個輸出繫結，或從函式簽章中返回單一輸出。
繫結運算式：使用佔位符將連線詳細資料和路徑參數化，例如 {queueTrigger}、{rand-guid} 以及基於環境的應用程式設定。連線屬性參考應用程式設定名稱，從而實現輪換和密鑰管理。在支援的情況下，優先使用受控識別的基於身分識別的連線，以避免嵌入密鑰。
並行與批次：在 host.json 中，針對每個擴充功能（queues、serviceBus、eventHub）控制並行和批次大小，以調整吞吐量和記憶體使用。驗證有害/無效信件處理，以確保能呈現失敗。

設計觸發程序和繫結時，應考慮冪等性、背壓和故障隔離。對於至少一次傳遞的來源（佇列、Event Hubs、Service Bus），應將函式編寫為具備冪等性且能應對重試。

Durable Functions：可靠的協調流程模式

Durable Functions 透過持久性任務框架，為 Azure Functions 擴充了具狀態、可靠的協調流程，適用於長時間執行的工作流程。

函式類型：

協調器函式：在程式碼中使用確定性的結構來描述工作流程邏輯。協調器會根據事件重播狀態，並且必須避免使用非確定性的 API（例如 DateTime.Now、隨機、網路呼叫），除非有適當的輔助工具。使用 Durable orchestration client API 來啟動、查詢和管理執行個體。
活動函式：執行離散的工作單元，例如呼叫外部 API、執行 CPU 密集型操作或 IO 任務。活動是可重試且可獨立擴展的。
實體函式：提供具備小型、一致性狀態和操作的持久性、可定址實體（例如計數器、裝置狀態）。實體以單執行緒的一致性處理序列化的操作。

模式：

函式鏈結：按定義的順序（A → B → C）對活動進行排序，並將結果傳遞給下一個活動。適用於具備相依性的管線。
展開/匯集：平行啟動多個活動並彙總結果。協調器使用類似 Task.WhenAll 的語義進行協調。此模式可用於獨立任務的平行處理。
人為互動（外部事件）：使用 WaitForExternalEvent 等待外部輸入（例如，核准），並可設定逾時和升級機制。結合持久性計時器來實作 SLA 和補償邏輯。
非同步 HTTP API：啟動協調流程並返回 202 Accepted 以及狀態/查詢 URL。用戶端輪詢由 Durable client 繫結公開的狀態端點，以獲取最終結果或狀態。
監視器：按排程執行的週期性檢查點，例如輪詢一個端點直到滿足某個條件，使用持久性計時器以避免佔用計算資源。
彙總器/實體：使用實體函式將小型狀態與邏輯儲存在一起，用於細微的協調，而無需完整的工作流程。

Durable Functions 保證活動的至少一次執行，以及協調器狀態的僅有一次進程。它們將狀態持久化到儲存體中（預設為 Azure Storage）；請確保儲存體帳戶能滿足吞吐量和可靠性的需求。對暫時性故障使用自訂重試策略，並為外部互動引發事件。對於非常長的流程，持久性協調流程可以憑藉其內建的持久性執行數天到數月。

組態、部署與可觀測性

Function App 的組態是分層且具備環境感知能力的。

host.json: 控制執行階段與擴充功能的行為。可設定日誌記錄 (取樣、日誌層級)、functionTimeout、擴充功能設定 (批次大小、並行度、預先擷取) 以及 JSON schema 版本。請將 host.json 保留在原始碼控制中。
local.settings.json: 本機開發設定，包含連線字串與應用程式設定。此檔案不會部署到 Azure。請妥善處理密鑰；將其從公開的 repo 中排除，並在本機開發時使用 user-secrets 或環境注入。
應用程式設定: 儲存在 Function App (App Service) 的組態中。關鍵設定包含 AzureWebJobsStorage (供觸發程序、日誌與檢查點使用的儲存體帳戶)、擴充功能專用的連線字串，以及任何自訂組態。將密鑰標記為「位置設定 (slot settings)」以避免在交換時被覆蓋。使用 Key Vault 參考搭配受控識別 (managed identity)，以避免用純文字儲存密鑰。

部署選項：

Zip Deploy: 上傳您建置成品的 ZIP 檔至應用程式。對於 CI/CD 而言既快速又簡單。可使用 az functionapp deployment source config-zip 或 zipdeploy API。它會將檔案寫入內容目錄。
Run-From-Package: 將 WEBSITE_RUN_FROM_PACKAGE 設定為套件的 URL (或設為 1 代表最新版)。執行階段會以唯讀模式掛載該套件，改善冷啟動並消除部署期間的檔案鎖定問題。將套件儲存在 Blob Storage 中，並使用 SAS URL 以便進行可重現的回滾。
部署位置 (Deployment slots): 預備 (Stage) 與生產 (Production) 位置能透過暖機實現零停機交換。Premium 與 Dedicated 方案支援部署位置。為密鑰和端點設定特定於位置的設定 (slot setting 旗標)，以防止跨環境洩漏。在流量轉移前，使用 preSwap 暖機來驗證擴充功能與繫結。

使用 Application Insights 進行監控：

叫用記錄: 每次函式叫用都會發出結構化的遙測資料，包括 Requests、Traces、Exceptions 與 Dependencies。使用 ILogger (或等效工具) 來產生結構化日誌。Operation 與 correlation ID 會將跨服務的活動與相依性串連起來。
Live Metrics: 即時檢視輸送量、失敗次數與延遲，且無取樣。對於觀察部署、擴展與熱路徑 (hot paths) 非常有用。可依函式名稱篩選以隔離問題。
失敗與可靠性: 檢查 Exceptions、失敗的 Requests 與相依性失敗。可針對失敗率、FunctionExecutionCount 異常或 DLQ/poison queue 增長設定警示。對於 Storage Queue 觸發程序，監控 -poison 佇列；對於 Service Bus/Event Hubs，監控無效信件 (dead-letter) 與檢查點的健康狀況。調整 host.json 的重試策略與退避機制，以減少暫時性錯誤的影響。
分散式追蹤: 啟用 W3C 追蹤標頭以跨 HTTP 和訊息傳遞來傳播關聯性。對於 Durable Functions，該框架會連結協調 (orchestration) 與活動 (activity) 的遙測資料，有助於端到端的診斷。調整取樣以平衡成本與精確度。

透過部署自動化 (GitHub Actions/Azure Pipelines)、HTTP 端點的健康狀態探查 (health probes) 以及具備自動擴展意識的調校來操作函式。保持套件精簡，將客戶端 (例如 HttpClient、Service Bus client) 快取為靜態單例 (static singletons)，並在啟動時驗證繫結的連線設定是否能解析，以防止執行階段失敗。

實際問題情境

Contoso Retail 推出一個促銷服務，當顧客將商品加入購物車時，能即時套用折扣。後端必須以低延遲回應高變動的流量、呼叫第三方定價 API，並更新一個 Cosmos DB 購物車文件。維運團隊希望實現零停機部署，並對失敗有深入的可見度。

選擇託管方案並建構應用程式

使用 Azure Functions Premium 方案，搭配兩個預先暖機的執行個體與 VNET 整合。Premium 方案能為對延遲敏感的購物車互動消除冷啟動，並透過 VNET 中的 NAT 或防火牆來保護對第三方 API 的對外流量。
建立一個單一的 Function App，其中包含一個用於購物車端點的 HTTP 觸發函式，以及一個 Durable Functions 協調器 (orchestrator) 來協調折扣擷取與購物車更新。

實作 Durable orchestration 以確保可靠性與平行處理能力

協調器函式 (Orchestrator function): 串連多個步驟來驗證輸入，透過活動函式 (activity functions) 以 fan out 方式平行擷取每個購物車品項的折扣，然後以 fan in 方式聚合以取得最佳價格。Durable orchestration 確保了確定性的控制流程與對重啟的韌性。
活動函式 (Activity functions): 一個活動函式負責呼叫帶有重試策略的第三方 API；另一個則透過輸出繫結 (output binding) 更新 Cosmos DB 中的購物車。活動函式封裝了外部 IO，並且可以獨立重試，而無需重複協調器的邏輯。

設定觸發程序與繫結以簡化開發

使用帶有 Function 驗證的 HTTP 觸發程序，以接受來自 Web 前端的簽署請求。對於長時間執行的購物車，回傳 202 並附上狀態 URL；對於快速路徑，則回傳 200。
在活動函式上使用 Cosmos DB 輸出繫結，以 upsert 購物車文件。繫結表達式使用來自 HTTP payload 的 cartId 來鎖定正確的分割區索引鍵。
使用受控識別 (managed identity) 與基於識別的連線來存取 Cosmos DB 和 Key Vault 參考，從而將密鑰從應用程式設定中移除。

優化組態與部署

host.json 將 functionTimeout 設為無限制 (Premium 方案)，並設定適合服務網格 (service mesh) 的 HTTP 逾時。日誌層級在生產環境中調整為 Information，並將 Samples 設為 20% 以控制成本。
使用 run-from-package，並將套件儲存在有版本控制的 Blob 容器中。透過 CI 進行部署，使用 az functionapp deployment，並透過預備位置 (staging slot) 交換到生產環境，以實現零停機發布。將連線字串與 API 端點標記為位置設定 (slot settings)，以避免跨環境洩漏。

監控與維運

啟用 Application Insights 與 Live Metrics，以便在發布期間觀察輸送量與延遲。針對 HTTP 5xx、對定價 API 的相依性失敗率，以及 Durable function 失敗協調次數的增加設定警示。
使用分散式追蹤來關聯 HTTP 請求與 Durable orchestration 及活動相依性，以加速對間歇性第三方問題的根本原因分析。

為何選擇這些方案：