用华为云 FunctionGraph 做定时任务：一次配置，告别自建 Cron 服务器

很多定时任务其实并不需要一台 7×24 小时开着的服务器来跑 Cron。我最近把几个每天、每周才跑一次的任务迁到了华为云 FunctionGraph（函数计算）上，用定时触发器代替自建 Cron，成本和运维负担都明显下降了。这篇短文记录一下做法和踩过的坑，供有类似需求的开发者参考。

一、为什么不用自建 Cron
自建 Cron 的问题不在写定时任务本身，而在它背后的那台机器：要保证机器不宕机、不重启、磁盘不被打满，还要处理日志轮转、时区、任务重叠和失败告警。任务越少，这台机器的性价比就越低。函数计算是按实际执行计费的，定时任务平时不运行、不占资源，只在触发时才执行一次，天然适合低频、短时的后台任务。

二、适合迁到 FunctionGraph 的任务
并不是所有定时任务都适合。首先看三个条件：单次执行时间比较短，一般在几分钟以内；任务之间没有强依赖，可以独立重试；不需要常驻内存或本地状态。符合这些条件的任务很多，例如每天凌晨清理临时文件、定时拉取第三方接口数据并写入数据库、每周生成一次运营报表、定时检查证书或配额到期时间并发送提醒。

三、三步完成配置
第一步，创建函数。进入 FunctionGraph 控制台新建函数，选择常用的运行时，例如 Python 3.10，入口函数保持默认即可。函数代码只做一件事，把业务逻辑写进 handler，输入参数就是触发器传来的事件。

第二步，配置定时触发器。在函数的触发器页签中新建定时触发器，选择按 Cron 表达式触发。例如每天凌晨 2 点执行，可以写成 0 0 2 * * ? *；每 10 分钟执行一次，可以写成 0 0/10 * * * ? *。保存前一定要确认时区，控制台默认按北京时间理解 Cron 表达式，跨时区的任务最容易在这里出错。

第三步，验证与看日志。先用测试事件手动触发一次，确认函数能正常返回，再等一个真实的定时触发周期，在日志里确认执行时间和结果。建议一开始把关键步骤都打日志，例如开始时间、处理条数、失败原因，出了问题不用猜，直接看日志就能定位。

四、一个最小可用的例子
下面是一个每天定时清理过期临时数据的函数骨架，实际使用时把清理逻辑换成自己的业务调用即可。

def handler(event, context):
    print('定时任务开始执行')
    # 1. 查询已过期的临时数据
    # 2. 分批删除，并记录删除条数
    # 3. 出现异常时记录错误并抛出，便于重试和告警
    print('定时任务执行完成')
    return {'status': 'ok'}

函数内部不要写死账号密码等敏感信息，需要访问其他云服务时，优先用函数配置的委托或环境变量传入凭证，并只给最小权限。

五、我踩过的三个坑
第一个坑是任务重叠。定时任务如果上一次还没跑完，下一次又触发了，两个实例同时跑很容易写脏数据。办法是让任务本身支持幂等，或者在 Cron 间隔上留出足够余量，执行时间接近触发间隔的任务要先做拆分。

第二个坑是超时设置。默认超时时间往往偏短，任务里一旦有慢接口调用就容易被中断。建议按历史最长耗时再留出余量来设置超时，并在代码里对慢接口单独设更短的超时，避免整个函数被拖住。

第三个坑是失败了没人知道。定时任务失败时不会有人盯着屏幕，所以一定要配告警：函数执行失败、执行时间异常、关键步骤返回非预期结果时，都要能收到通知。否则任务悄悄停了几天才发现，损失比多配一个告警大得多。

总结
低频、短时、可重试的定时任务，优先考虑用 FunctionGraph 加定时触发器实现：不用维护服务器，按量计费，配置一次就能长期运行。迁移时注意三点：确认 Cron 表达式和时区、保证任务幂等、配好失败告警。把这三点做好，定时任务就能真正做到配置完就不用管。