小任务别再租整台机器了：聊聊 FunctionGraph 的触发器、冷启动和计费那些事

前阵子有个朋友问我：每天凌晨要跑一个脚本，从 OBS 拉一批文件做格式转换再写回去，数据量不大，几分钟就完事。这种活儿，你会给他开一台 ECS，24 小时挂着吗？

开吧，浪费；不开吧，总不能每天定个闹钟爬起来手动跑。这种“偶尔跑一次、跑完就闲着”的任务，正是 Serverless 最擅长的场景。华为云的 FunctionGraph 就是干这个的：你只管写函数，什么时候跑、跑多少实例、机器怎么维护，都交给平台。

一、先搞懂 FunctionGraph 到底是个啥

一句话：把代码传上去，配一个“什么时候跑”的触发器，剩下的不用管。

不用登录服务器，不用打系统补丁，并发上来了平台自己扩。函数不跑的时候不占资源，计费也是按量来：请求次数加上资源使用量（内存×时间），用多少算多少。开头那种凌晨跑批的小任务，一个月下来可能也就几块钱，比包一台 ECS 便宜一个数量级。

但它不是万能药，先泼三盆冷水。

第一，长时间跑的任务别硬塞。函数有单次执行时长上限，几十分钟的批处理，老老实实用 ECS 或者批量计算服务。

第二，调用频率很低、又对延迟敏感的场景，要掂量冷启动。函数长时间没人调，实例会被回收，下一次调用得重新拉起环境，多花几百毫秒到几秒。后台定时任务无所谓，但直接面向用户的实时接口，就得评估这一下能不能接受。

第三，状态别放函数里。函数实例是无状态、随时可能被回收的，需要持久化的数据丢给 OBS、RDS 或者 Redis，别写本地磁盘指望下次还在。

二、触发器：函数的“闹钟”和“门铃”

函数自己不会跑，得有人“叫”它。FunctionGraph 的触发器就是干这个的，常用的几类：

定时触发器，用 cron 表达式，最省心的就是开头说的凌晨跑批。写的时候注意时区，别把“每天凌晨 3 点”写成“每小时的第 3 分钟”，这种错见过不止一次。

APIG 触发器，给函数挂一个 HTTP 入口，适合做 webhook 和小型 API。对接个消息推送回调，一个函数就搞定，不用起一整个服务。

OBS 触发器，桶里进了新对象就触发，图片压缩、文件格式转换的经典链路：上传→触发→处理→写回新路径，一气呵成。

SMN、LTS、DIS 这些，消息通知、日志、流数据，适合把多个环节串成事件驱动的链条。

选触发器的思路其实就一句话：谁产生事件，就让谁来触发。千万别写个轮询脚本每分钟去查一次，那是把 Serverless 用成了“更贵的定时器”。

三、几个容易踩的配置坑

内存和超时，填之前先想清楚。内存给小了，任务跑一半被掐掉；超时设短了，大文件转到一半直接中断。建议先按预估的 1.5 倍设，跑几次看监控曲线再往下调。调优要有依据，别拍脑袋。

要访问 VPC 里的资源，记得配网络。函数默认跑在公网环境，要连 VPC 里的 RDS、Redis，得给函数配置 VPC、子网和安全组。配完函数就有了内网身份。但要注意，进了 VPC 的函数再想访问公网，得看路由规划，可能要走 NAT，提前验证，别上线才发现调不通外部接口。

依赖和环境变量，打包一次说清楚。Python 函数的第三方包打进 zip，或者用层（Layer）来管理公共依赖。版本一多就容易乱，所以善用版本和别名：发新版先切一小部分流量验证，别名始终指向稳定版，出问题一键回滚，心里不慌。

日志别只看控制台输出。函数执行日志会接入 LTS，报错先去日志里翻堆栈，再看监控里的执行时长和错误率曲线。很多所谓的“偶发失败”，看一眼曲线就知道是冷启动抖动还是下游超时。

四、计费：便宜是真便宜，但要会算

FunctionGraph 按量计费，核心两块：请求次数，资源使用量（内存×执行时间）。低频小任务用它，账单通常很友好。

但有两个地方容易超预期。一是函数里调用了别的收费服务，账单算在人家头上，别赖函数头上；二是超高频调用，每秒几百上千次请求，请求次数的费用会累积，这时候反而不如一台常驻实例划算。算账的方法：预估月请求量和 GB-秒，跟 ECS 月租比一下，哪个低用哪个，就这么简单。

五、给新手的三步上手建议

第一步，先拿定时触发器练手。写个最简单的函数，每天往 SMN 发一条消息，把“写函数→配触发器→看日志”全链路跑通。

第二步，加上日志和告警。出问题第一时间知道，而不是等用户来找你。

第三步，再玩串联。OBS 上传→函数转码→写回新桶，一条事件链跑通，你对 Serverless 的理解基本就到位了。

最后说一句：Serverless 不是银弹，但它把“跑个小任务”的门槛降到了最低。下次再遇到那种“每天跑几分钟”的活儿，先想想函数，别急着开机器。