华为云 FunctionGraph 冷启动治理实战：从首调 504 到稳定 3 秒内响应

引言

用华为云 FunctionGraph 做 Serverless 后端，最常见的“第一印象”往往不是弹性与免运维，而是一次突如其来的 504：白天调得好好的接口，隔一段时间再调，第一次请求超时，第二次却又恢复正常。很多开发者第一反应是“网关不稳定”或者“函数写错了”，反复改代码、升内存，却发现问题依旧时有时无。

本文结合一个真实的端云一体项目——HarmonyOS 待办清单应用（端侧 ArkTS，后端为部署在 FunctionGraph 上的 Node.js 云函数，经由 APIG 专享版转发，数据存放在 RDS for MySQL）——系统梳理冷启动的成因、定位方法与五类治理手段。文中涉及的具体数值均来自该项目公开的案例文档与华为云官方文档的一般性说明，结论可直接复用到同类 Serverless 后端上。

一、冷启动到底在“冷”什么

冷启动不是一个单一事件，而是一串初始化动作的总和。一次冷启动通常包含三个阶段：

1. 运行环境准备。 平台为函数分配沙箱、拉起 Node.js 运行时、解压并加载部署包。部署包越大、文件越多，这个阶段越长。把 node_modules 里用不上的依赖打进 ZIP 包，是最常见的拖慢因素。

2. 网络与连接建立。 如果函数需要访问 VPC 内的 RDS，平台要为函数挂载弹性网卡（ENI）并建立内网通路。上述待办清单案例的文档明确记载：VPC 冷启动约 6 秒，超过了 APIG 后端默认的超时时间，因此首次调用会返回 504。这 6 秒不是函数代码慢，而是网络平面在“热身”。

3. 应用层初始化。 包括加载业务模块、建立数据库连接池、读取环境变量、初始化 SDK 客户端等。这一阶段完全由开发者控制，也是最容易优化的部分。

理解这三段划分很重要：只有分清耗时花在哪一段，才能选对优化手段。给函数升内存能缓解运行时启动慢，但对 VPC 网卡挂载的耗时几乎没有帮助；而连接池复用能省掉每次建连的开销，却省不掉第一次挂载网卡的时间。

二、先分清：是冷启动，还是配置问题

动手优化之前，先用 10 分钟做定位，避免在错误的方向上投入。

第一步，看错误码与耗时分布。 如果报错集中在长时间空闲后的“第一次调用”，且第二次调用立即恢复，大概率是冷启动；如果每次调用都慢或都报错，应优先检查函数配置、SQL 与下游依赖。

第二步，查函数日志。 FunctionGraph 控制台提供函数执行日志与监控指标，重点关注初始化阶段耗时与是否存在 Cannot find module 这类依赖缺失错误。依赖缺失与冷启动无关，但症状相似——函数启动失败后重试也会表现为间歇性超时。

第三步，做一个最小诊断函数。 上述待办清单项目内置了一个 diag 诊断函数：只做最轻量的连通性检查，不执行业务逻辑。排障时先调 diag，再调业务函数：如果 diag 也慢，问题在环境与网络层；如果只有业务函数慢，问题在业务初始化或 SQL 层。这种“分层探针”的思路，比直接在业务函数里加日志更高效。

定位完成后再谈优化。下面五类手段按“投入产出比”排序，建议按顺序实施。

三、手段一：给部署包做减法

冷启动的第一性原理是“少加载、快加载”。

只打生产依赖。 部署前检查 package.json，把测试框架、脚手架、类型定义等 devDependencies 排除在外；只保留运行时真正 require 的包。上述待办清单项目的部署脚本只打包 harmony_cloud/functions 下的函数代码与必需的 node_modules，不把端侧代码与文档打进函数包。

按函数拆包，而不是一个包打天下。 该项目把注册、登录、任务增删改、建表初始化、诊断拆成 8 个独立函数，每个函数只引入自己需要的模块。登录函数不需要任务模块的代码，加载量自然小。反模式是把全部业务写进一个“万能函数”，每次冷启动都要加载全部依赖。

警惕“隐形大依赖”。 有些包体积不大，但初始化时会做大量同步工作（如加载庞大的规则表、编译模板）。升级或替换这类依赖前，先在本地用 node --cpu-prof 或简单的启动计时确认它的初始化成本。

四、手段二：把初始化移到“全局”，让连接池跨请求复用

FunctionGraph 的执行环境在请求之间会被复用：同一个实例处理第二次请求时，全局变量依然存在。正确做法是把“建一次、反复用”的资源放在 handler 之外。

// handler 之外：只初始化一次，实例复用时直接使用
const mysql = require('mysql2/promise');
let pool = null;

function getPool() {
  if (!pool) {
    pool = mysql.createPool({
      host: process.env.DB_HOST,
      user: process.env.DB_USER,
      password: process.env.DB_PASSWORD,
      database: process.env.DB_NAME,
      waitForConnections: true,
      connectionLimit: 5,
      dateStrings: true, // 日期以字符串返回，避免时区换算导致的时间差
    });
  }
  return pool;
}

exports.handler = async (event) => {
  const body = parseBody(event); // 见下文：APIG 透传的 body 可能是 base64
  const pool = getPool();
  const [rows] = await pool.query('SELECT * FROM tasks WHERE user_id = ?', [body.userId]);
  return { code: 0, message: 'ok', data: rows };
};

这段代码里有三个容易踩的坑，值得展开：

坑一：每次请求都新建连接。 如果把 createPool 写在 handler 内部，每次请求都要经历 TCP 握手、MySQL 认证，耗时几百毫秒起步，并发一高还可能打满数据库连接数。连接池只建一次，是 Serverless 后端最基础、收益最大的优化。

坑二：忘记解 base64。 经由 APIG 转发的请求体可能被 base64 编码，函数内必须先判断并解码，否则 JSON.parse 会报 Unexpected token。该案例的故障库把这一条列为高频问题，处理方式是封装统一的 parseBody()，所有函数共用。

坑三：时区。 云函数运行环境默认使用 UTC，而 MySQL 的 dateStrings 若不开启，驱动会把数据库时间按本地时区换算，端侧看到的时间可能差 8 小时。案例的做法是连接池开启 dateStrings: true，再由业务层统一用北京时间格式化，从根上消除时区漂移。

五、手段三：超时与重试必须成对设计

冷启动无法彻底消除时，正确姿势是让它“可承受”：网关超时、函数超时、端侧重试三者要成对配置。

1. 函数超时要大于最坏冷启动。 该项目把函数超时设为 30 秒，留出 VPC 冷启动约 6 秒加上业务执行的时间余量。把函数超时设得比网关超时还短没有意义——函数还没跑完，网关已经先断开了。

2. 端侧要有带退避的重试。 待办清单 App 的端侧网络层内置了 3 次重试：首次 504 属于冷启动的预期现象，重试 2–5 次后一般即可恢复。重试必须配合幂等设计：案例中任务创建使用幂等 upsert（按业务唯一键去重），重试不会产生重复任务。没有幂等的重试，比没有重试更危险。

3. 区分“可重试”与“不可重试”。 超时、502、504 可以重试；400、401、业务错误码（如 code:1 表示业务错误、code:2 表示未登录）重试也没有用，应直接把错误展示给用户。重试前先判断状态码，是客户端健壮性的基本功。

六、手段四：预热与保活——有效，但要算账

如果业务对首调延迟非常敏感（例如登录接口），可以用定时触发器周期性调用函数，保持少量实例处于热状态。做法通常是每 5–10 分钟触发一次轻量探针（如调 diag 函数），成本是少量调用次数与执行时长。

但预热不是万能药：突发流量到来时平台仍需扩容出新实例，新实例一样会冷启动；预热频率过高又会产生不必要的费用。对大多数内部工具与低频应用来说，做好重试往往比预热更划算。建议先评估“首调慢 6 秒”对业务的实际影响，再决定是否值得为预热付费。

七、手段五：把冷启动变成可观测的指标

治理的最后一环是度量，否则优化效果无从验证：

• 记录初始化耗时。 在函数入口打点，分别记录模块加载、建池、首次查询的耗时，输出到日志。
• 监控冷启动率。 结合 FunctionGraph 的调用量与延迟指标，关注 P95/P99 而不是平均值——冷启动影响的是长尾。
• 保留诊断入口。 像 diag 这样的轻量探针函数应长期保留，联调与值班排障时都能直接使用；但注意部署完成后删除为调试临时建的公网触发器，避免留下公开的初始化入口。
• 上线前做一轮“冷态验收”。 等待实例回收后（通常数十分钟无流量），重新调一遍核心接口，确认首调表现符合预期，再交付。

八、上线前检查清单

• [ ] 部署包只含生产依赖，单个函数只加载自身需要的模块
• [ ] 数据库连接池在 handler 之外创建并复用，连接数上限与数据库规格匹配
• [ ] 请求体统一做 base64 解码，业务接口统一返回 {code, message, data} 结构
• [ ] 日期字段开启 dateStrings，时区处理收敛到一处
• [ ] 函数超时（30 秒）大于网关超时与最坏冷启动耗时之和
• [ ] 端侧实现带退避的有限重试，且写操作具备幂等性
• [ ] 保留 diag 诊断函数，删除临时公网触发器与调试入口
• [ ] 敏感信息只放环境变量与 .env，不进代码仓库；DEBUG 日志自动剔除密码与 token
• [ ] 做一轮冷态验收：空闲后首调登录接口，确认 2–5 次重试内恢复

结语

冷启动是 Serverless 架构为弹性付出的代价，而不是缺陷本身。治理它的正确顺序是：先定位分段、再做减法、复用连接、配对超时与重试，最后用预热与可观测性收尾。上述待办清单项目用这套方法，把“首调 504、重试即恢复”从偶发故障变成了可预期、可度量的行为——用户几乎感知不到冷启动的存在，而开发者也不用再为它半夜排障。

如果你也在用 FunctionGraph 搭建端云一体后端，不妨按本文的检查清单逐项核对：很多时候，首调从 6 秒降到 3 秒以内，并不需要升级任何规格，只需要把初始化放对位置、把超时与重试配成一对。