用华为云 FunctionGraph 打造 Serverless 定时任务系统：原理到落地

一、为什么用 Serverless 做定时任务

传统定时任务往往需要一台常驻的服务器跑 cron，利用率低、运维成本高。Serverless 函数天然适合"短时、周期性、突发"的任务：平时零成本，触发时才计费。本文以华为云 FunctionGraph 为例，讲清如何搭建一个可靠的定时任务系统。

二、核心组件

• 函数：承载业务逻辑的最小单元，按需执行；
• 定时触发器：用 cron 表达式周期性触发函数；
• 环境变量/委托：存放配置与访问其他云服务的权限。

把定时触发器绑定到函数，就得到一个"无需服务器的 cron"。

三、幂等与并发：定时任务的两个大坑

Serverless 定时任务最容易踩的两个坑：重复执行与超时重试导致的双跑。可靠的做法：

def handler(event, context):
    task_key = "daily_report_" + today()   # 以"任务+日期"为幂等键
    if redis.setnx(task_key, "1") == 0:    # 已执行过则直接返回
        return {"skipped": True}
    redis.expire(task_key, 86400)
    try:
        do_work()
    except Exception:
        redis.delete(task_key)             # 失败释放，允许重试
        raise

用分布式锁（Redis）做幂等，保证同一任务周期只真正执行一次。

四、超时与重试设计

函数有最大执行时长限制。长任务要拆分：把大任务切成多个小批次，用队列或状态机串起来；对可重试的错误配置重试次数与退避；对不可重试的（如参数错误）直接记录告警。让每个函数都在超时前完成一小步，是 Serverless 任务设计的基本原则。

五、可观测性

没有服务器意味着更要依赖日志与指标：把关键节点日志结构化输出，接入日志服务做检索；对执行时长、错误率、冷启动设置告警。任务是否"按时、按次、按量"执行，全靠这些指标说话。

六、踩坑与经验

1. 幂等优先：分布式锁 + 任务键，杜绝重复执行；
2. 大任务拆小：避免触碰函数超时上限；
3. 退避重试：区分可重试与不可重试错误；
4. 结构化日志：无服务器更要靠日志排障。

七、小结

FunctionGraph + 定时触发器，是搭建低成本定时任务系统的利器。把幂等、拆分、可观测三件事做好，它完全可以承载生产级的定时任务。