本文介紹Function Compute基於傳統常駐應用所拓展的運行時擴充功能，協助您消除閑置成本。
常駐應用與FaaS運行環境
傳統常駐的虛擬機器或者託管容器類服務通常從執行個體啟動到結束作為計費區間，即使該時間段沒有業務請求仍然需要付費。Function Compute提供1 ms計費粒度，且只在有實際請求的區間內計費，在請求以外的時間段內執行個體會被冷凍。這樣基本消除了完全事件驅動的計費模型的閑置成本，然而冷凍機制也會打破一些傳統架構下long-running進程的假設，加大應用遷移的難度。例如常用的開源分布式鏈路追蹤Tracing Analysis庫或者是第三方APM解決方案由於Function Compute特殊的運行環境無法正確上報資料。
下列痛點都阻礙傳統應用平滑遷移至Serverless架構：
非同步背景指標資料延遲或丟失：如果在請求期間沒有發送成功，則可能被延遲至下一次請求，或者資料點被丟棄。
同步發送指標增加延遲：如果在每個請求結束後都調用類似Flush介面，不僅增加了每個請求的延遲，對於後端服務也產生了不必要的壓力。
函數優雅下線：執行個體關閉時應用有清理串連，關閉進程，上報狀態等需求。在Function Compute中執行個體下線時機開發人員無法掌握，也缺少Webhook通知函數執行個體下線事件。
編程模型擴充
Function Compute針對上述痛點發布了運行時擴充（runtime extensions）功能。該功能在現有的HTTP服務編程模型上擴充，在已有的HTTP伺服器的模型中增加了PreFreeze和PreStop webhooks。擴充開發人員實現HTTP handler，監聽函數執行個體生命週期事件。
PreFreeze：在每次Function Compute服務決定冷凍當前函數執行個體前，Function Compute服務會調用HTTP GET /pre-freeze路徑，擴充開發人員負責實現相應邏輯以確保完成執行個體冷凍前的必要操作，例如等待指標發送成功等。函數調用InvokeFunction的時間不包PreFreeze hook的執行時間。
PreStop：在每次Function Compute決定停止當前函數執行個體前，Function Compute服務會調用HTTP GET /pre-stop路徑，擴充開發人員負責實現相應邏輯以確保完成執行個體釋放前的必要操作，如關閉資料庫連結，以及上報、更新狀態等。
計費說明
喚起PreFreeze或PreStop中產生的同InvokeFunction計費方式一致。擴充HTTP hooks請求數不做計費。擴充在單一實例多並發的情境下依然適用，假設同時有多個Invoke請求在相同執行個體執行，在所有請求都結束後即將冷凍執行個體之前會調用一次PreFreeze hook。以下圖為例，函數規格為1 GB，從t1 PreFreeze開始到t6請求2結束的時間段（假設為1秒），則執行個體執行時間為t6-t1，消耗1s * 1 GB=1 CU。