实战SOP:CodeArts操作FunctionGraph,白嫖算力

背景:不想买服务器,又想跑后台任务

个人项目总有一堆"跑在后台的小活":定时抓数据、每小时生成报表、接收第三方 Webhook、批量压缩图片。这些活的共同点很明显——跑得不多、但必须有人跑;不值得买台服务器,又不能永远手动执行。

函数工作流(FunctionGraph)正好卡在这个位置上:按需触发、按量计费、没有常驻实例要维护。更关键的是,它有相当可观的免费额度——个人量级的调用次数与执行时长,基本用不完。相当于白嫖一份算力。

但函数这东西,手工上线一趟并不轻松:写 handler、打依赖、建函数、配触发器、调超时与内存、看日志。每一步都在控制台里点。这次我把整套流程交给码道 CodeArts,从写代码到配触发器一次跑通。

方案:五步,从需求到定时任务

1. 先把"契约"写清楚。 CodeArts 让我先回答三个问题:输入是什么(定时触发还是 HTTP 请求)、处理多久(决定超时档位)、输出到哪(数据库、对象存储还是直接返回)。这三个答案决定了后面的所有参数。

2. 函数骨架(带返回格式的 handler):

import json

def handler(event, context):
    try:
        body = json.loads(event.get("body") or "{}")
        target = body.get("url", "")
        # 业务处理:抓取、转换、落库……
        return {
            "statusCode": 200,
            "headers": {"Content-Type": "application/json"},
            "body": json.dumps({"ok": True, "req": context.request_id}),
        }
    except Exception as e:
        return {
            "statusCode": 500,
            "body": json.dumps({"ok": False, "err": str(e)}),
        }

两个细节值得留意:handler 必须自己把异常兜住并转成标准返回,否则平台侧只会看到一个失败的调用;context.request_id 是排查问题时的串联依据,建议写进日志。

3. 打包依赖:

# 依赖与代码打进一个 zip(在 Linux 环境打包,避免二进制不兼容)
pip install -r requirements.txt -t libs/
zip -r func.zip main.py libs/

4. 部署(CLI 一次到位):

# 创建函数(参数以 hcloud FunctionGraph CreateFunction --help 为准)
hcloud FunctionGraph CreateFunction \
  --func_name=img-thumb \
  --runtime=Python3.10 \
  --handler=main.handler \
  --memory_size=256 \
  --timeout=30

建完函数再上传 zip、配环境变量(密钥一律走环境变量,不写进代码)。这一步 CodeArts 会逐一核对:地域对不对、内存档位够不够、超时是否高于预计执行时间。

5. 接触发器。 定时任务用定时触发器,cron 表达式(如每 10 分钟一次);HTTP 场景用 API 网关触发器,函数返回值按约定的 statusCode/headers/body 结构回给调用方。触发器的时区、频率、并发配额,都要在配置时确认。

跑通之后,我的报表任务就是"每 10 分钟自动跑一次,日志里看结果",服务器一台没买。

实践要点

1. 打包环境要和运行环境一致。 在 Windows 本机打的 zip,如果依赖里有 C 扩展,到 Linux 运行时会报"模块找不到"或二进制不兼容。正确做法是在 Linux 容器里 pip install -t,纯 Python 依赖才无所谓。
2. 内存档位决定 CPU 配额。 函数的 CPU 是按内存比例给的,128MB 档位算力很弱,压缩、解析类任务明显慢;256MB 或 512MB 往往是性价比拐点。用实测执行时长选档位,别用默认值硬扛。
3. 超时上限要算清楚。 默认 30 秒对轻任务够用;抓取、转码这类任务可能跑到几分钟,要显式调高超时。超过单函数上限的长任务,拆成"函数 + 状态机"或改异步触发,别指望一个函数跑到底。
4. 冷启动是常态,不是故障。 按需实例在空闲后会回收,下一次调用需要重新初始化(加载依赖、建连接)。定时任务如果对延迟敏感,可以靠"预热调用"或固定并发保活;不敏感就坦然接受,几秒的冷启动换零运维,划算。
5. 计费按"执行时长 × 内存",注意别让函数白醒着。 函数没在跑就不计费,但一次调用里"空转等待"也在计时。网络请求加超时、循环加边界,别让一个卡死的函数把额度耗在等待上。
6. 异步与重试的场景,函数必须幂等。 平台对失败调用可能重试,同一事件被执行两次是常态。写库用唯一键或"先查后写",生成文件用可覆盖的命名,别假设"只会跑一次"。
7. 日志是唯一的现场。 函数没有登录的服务器可查,问题都靠日志还原。把关键输入摘要、request_id、耗时写进日志,排查效率能差出十倍。

小结

这套组合的价值,不在于"免费"两个字,而在于它把"后台任务"从"运维资产"变成了"调用契约":你给我一个事件,我还你一个结果,中间没有服务器要操心。对个人开发者,这意味着可以把精力全放在逻辑上;对团队,它是最省事的定时任务载体。

白嫖算力的正确姿势,不是把免费额度用到极限,而是把合适的活放到合适的地方:事件驱动的、短时的、偶发的任务交给函数;常驻服务、长连接、重状态的东西,该上服务器还是上服务器。想清楚这条边界,函数工作流就是个人项目最好用的"隐形服务器"。