北京
凌晨三點，你的函數實例數歸零。早高峰流量涌入，第一個用戶盯著加載圈等了6.8秒——這筆錢省得值嗎？
Azure Functions現在有五種托管方案，但核心矛盾沒變：免費配冷啟動，恒溫要月付146美元。微軟把按量計費（Consumption）標為"遺留"，卻擋不住它仍是大多數應用的起點。本文拆解四種App Service方案，看各自的賬單邏輯和擴容邊界。
擴容公式：一個除法決定你的實例數
從運行時v4.19.0起，平臺用目標驅動擴容。公式極簡：
目標實例數 = 事件源長度 / 單實例目標執行數
"事件源長度"因觸發器而異：存儲隊列看隊列長度，服務總線看活躍消息數，事件中心看分區未處理事件，Cosmos DB看變更流積壓。系統讀取這些信號，動態調整實例。
但擴容有硬約束：每次最多加4個實例；HTTP觸發器每秒最多擴一次，非HTTP每30秒一次。漸進流量沒問題，從零突增必卡頓。
單實例配置：1.5GB內存，1核CPU。Windows上限200實例，Linux上限100實例（且每小時每訂閱限500實例）。
賬單的兩把尺子：內存桶和時間片
內存按128MB向上取整，執行時間按毫秒計，最小計費單位128MB×100ms。日跑數千次、單次秒內的函數，通常吃不滿免費額度。
真正的賬單陷阱是冷啟動。約20分鐘無活動后，實例歸零。下次請求需重新拉啟——.NET隔離工作模式下，冷啟動2到7秒是常態，依賴注入重的能破10秒。微軟2026年11月將停用進程內模式，那曾是更快的選項。
定時觸發器的特殊困境
（原文此處截斷，后續內容缺失）
五種方案里，按量計費（Consumption）和彈性按量（Flex Consumption）主打"無服務器"，高級版（Premium）買預溫實例，專用版（Dedicated）和容器應用（Container Apps）走傳統托管路線。選擇本質是回答：你的流量模式，值得為"隨時可用"預付多少成本？
微軟力推新方案，但遺留標簽不意味著立即淘汰。關鍵判斷標準是：冷啟動損失的用戶價值，是否超過恒溫托管的固定月費？對低頻后臺任務，6.8秒的延遲或許無人感知；對面向用戶的同步API，這可能是轉化率的直接殺手。
你的函數最近一次冷啟動是多少秒？這筆賬，你算過嗎？
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
