本文介绍函数计算基于传统常驻应用所拓展的运行时扩展功能，帮助您消除闲置成本。
常驻应用与FaaS运行环境
传统常驻的虚拟机或者托管容器类服务通常从实例启动到结束作为计费区间，即使该时间段没有业务请求仍然需要付费。函数计算提供1 ms计费粒度，且只在有实际请求的区间内计费，在请求以外的时间段内实例会被冷冻。这样基本消除了完全事件驱动的计费模型的闲置成本，然而冷冻机制也会打破一些传统架构下long-running进程的假设，加大应用迁移的难度。例如常用的开源分布式链路追踪Tracing Analysis库或者是第三方APM解决方案由于函数计算特殊的运行环境无法正确上报数据。
下列痛点都阻碍传统应用平滑迁移至Serverless架构：
异步背景指标数据延迟或丢失：如果在请求期间没有发送成功，则可能被延迟至下一次请求，或者数据点被丢弃。
同步发送指标增加延迟：如果在每个请求结束后都调用类似Flush接口，不仅增加了每个请求的延迟，对于后端服务也产生了不必要的压力。
函数优雅下线：实例关闭时应用有清理连接，关闭进程，上报状态等需求。在函数计算中实例下线时机开发者无法掌握，也缺少Webhook通知函数实例下线事件。
编程模型扩展
函数计算针对上述痛点发布了运行时扩展（runtime extensions）功能。该功能在现有的HTTP服务编程模型上扩展，在已有的HTTP服务器的模型中增加了PreFreeze和PreStop webhooks。扩展开发者实现HTTP handler，监听函数实例生命周期事件。
PreFreeze：在每次函数计算服务决定冷冻当前函数实例前，函数计算服务会调用HTTP GET /pre-freeze路径，扩展开发者负责实现相应逻辑以确保完成实例冷冻前的必要操作，例如等待指标发送成功等。函数调用InvokeFunction的时间不包PreFreeze hook的执行时间。
PreStop：在每次函数计算决定停止当前函数实例前，函数计算服务会调用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。
