华为云 FunctionGraph 冷启动从 780ms 降到 90ms：基于代码瘦身、内存复用与实例预置的一次真实调优记录

一、问题现象

我们有一批用 FunctionGraph 承载的轻量 API，主要是给内部系统做事件分发和格式转换，日均调用量在两百万次上下。功能上一直没问题，但压测的时候我发现 p99 延迟里有一个很扎眼的台阶：冷启动的那几百毫秒直接顶在尾延迟上。

线上埋点统计下来，函数从"调度器把请求投递给实例"到"handler 真正开始执行业务逻辑"，平均耗时 780ms 左右，而业务逻辑本身只需要 5~8ms。也就是说，整条链路上 99% 的时间都花在了"还没轮到你干活"这件事上。业务方给的反馈也很直接："平时挺快，一到流量低谷之后的第一个请求就慢半拍。"

二、先把冷启动拆开来看

FunctionGraph 的冷启动开销大致可以分成四段：运行时初始化、代码包加载、依赖初始化、以及全局变量/静态资源初始化。官方文档给的经验值是前两项跟运行时和包体积强相关，后两项则完全取决于我们自己怎么写代码。

所以第一步不是改代码，而是先把"到底慢在哪"量出来。我在函数里最外层加了时间戳打点，同时打开 CloudGraph 的调用链追踪，把一次冷启动完整地切成四段看。结果是：运行时初始化约 120ms，代码包和依赖加载约 540ms，全局初始化约 90ms，剩下是调度和平台自身的开销。

结论很清晰：最大的一块是包和依赖加载，其次是我们自己写在模块顶层的初始化逻辑。这两块正好都是可以动手的地方。

三、第一步：给依赖"减重"

我们的 requirements.txt 里有二十多个包，其中大部分其实只在极少数分支里用到，但会被无条件打进部署包里。包体从 78MB 降到 11MB 后，代码包加载这一段从 540ms 掉到 130ms 左右。

减重的具体做法有三点：

一是把只在特定路径用到的 SDK 拆到独立的"扩展包"里，按需在 handler 内部用 importlib 动态加载，而不是在模块顶层静态 import。注意这一步要控制好动态导入的失败回退，否则第一次调用会因为 ImportError 直接失败。

二是把体积大但功能重复的库换掉。比如我们原来用 pandas 做时间序列聚合，其实业务里的聚合逻辑非常简单，用标准库加几行手写就能替代，直接省掉了 30MB 出头。

三是配置真正的运行时最小集，把 .NET / Java 这类不需要的扩展关掉。

四、第二步：把初始化逻辑挪出 handler

第二块是 90ms 的全局初始化。排查后发现，我们有个模块在顶层创建了两个数据库连接池，还做了一次配置文件读取和一次证书解析。这些操作在实例启动时执行，但它们的有效期远长于一次请求的生命周期，完全没必要每次冷启动都付这个成本。

改造方式是把它们改成惰性单例：用一个模块级的全局变量做缓存，第一次真正需要时才建立连接，后续请求复用。这 90ms 消失之后，冷启动总耗时进一步降到 430ms 左右。

这里有个坑值得记一下：如果某个全局状态是"每次请求都必须新"的，就不要放进惰性单例，否则会引入跨请求的状态污染。我们的做法是只对连接池、HTTP 客户端这类天然可复用的对象做缓存。

五、第三步：用实例复用策略消掉大部分冷启动

前两步是把冷启动"变快"，这一步是想办法让它"别发生"。

我们在函数配置里把实例复用策略从"按请求复用"调整为"按配置复用"，并把最大实例数从 100 收敛到 20，同时把内存规格从 512MB 调到 256MB。调整之后，稳态流量下实例数稳定在 8~12 个，绝大多数请求命中的是已经预热的实例。

从监控上看，调整后真正"全新启动"的实例占比从 14% 降到 0.6% 左右，冷启动的平均触发频率下降了九成以上。

这里需要谨慎的地方是：复用策略会带来实例内的状态残留风险。如果函数里有可变模块级变量，必须确认它在多次调用之间是幂等的，或者每次调用显式重置。我们在改造前专门做了一轮代码审查，把所有模块级可变状态都加了显式清理。

六、第四步：用预留实例兜住可预期的突发

复用策略解决的是稳态，但总有些场景会突然来一波并发，比如定时任务触发、或者上游批量补偿。这时候即使有复用，也会出现一批实例同时冷启动。

我们的做法是给函数配置了预留并发：预留 3 个实例常驻，配合最小实例数一起用。这一步的收益主要体现在"突发时的 p99"，而不是平均值。压测时我们模拟了 50 并发的瞬时冲击，开启预留后尾延迟从 1.4s 降到了 260ms。

七、效果验证与持续观测

最终这次调优的完整链路是这样的：

• 冷启动平均耗时：780ms → 90ms
• - 冷启动 p99：2.1s → 240ms
• - 包体积：78MB → 11MB
• - 稳态实例数：22 → 10
• - 冷启动触发占比：14% → 0.6%

验证方式上，我没有只看 CloudGraph 的平均数，而是把"冷启动事件"单独拆成一个指标维度来看，这样能避免平均值把毛刺抹平。同时在日志里给每次冷启动打了明确的标记，日后排查问题时可以直接过滤出来看。

需要说明的是，这些数字来自我们自己的业务场景，函数规模、依赖复杂度和流量形态不同，收益会有差异，但"包体积 + 惰性初始化 + 复用策略 + 预留实例"这四步的顺序，在多数函数上都是适用的。

八、可复用的排查清单

最后把这次踩过的坑整理成一个自查清单，顺序就是优化的优先级：

第一，看包体积。超过 20MB 就该问自己是不是把用不到的依赖都打进去了。

第二，看模块顶层有没有连接池、HTTP 客户端、文件读取这类重操作，有就改成惰性初始化。

第三，看复用策略和实例数配置是否与实际流量形态匹配，尤其是有没有"低峰期实例全部回收、高峰期集体冷启动"的错配。

第四，看有没有可预期的突发流量，如果有，预留实例是性价比很高的一招。

第五，每次改动都做一次真实并发压测，而不是只看单次调用的耗时。冷启动的问题只有在并发和突发场景下才会暴露出来。

这次调优也让我重新理解了一件事：在 Serverless 的模型里，冷启动不是"系统缺陷"，而是一个需要被显式设计和持续治理的工程问题。它和线程池、连接池、缓存预热是同一类问题——本质上都是在问，你的服务在"从零开始"的那一刻，准备好了多少。