维护一台常年不关的采集服务器，是一件性价比越来越低的事：要盯安全补丁、要防磁盘写满、月底还要交一笔固定账单——而它的实际工作，不过是每天定时跑几十秒的采集任务。这类「定时干一会儿」的负载，正是函数计算（FC）的主场。 这篇把一台采集服务器迁移到「定时触发器 + 函数 + OSS」的过程完整走一遍，含代码、存储选型、安全配置和踩坑。
一、目标架构
定时触发器（cron） → 函数（Python） → 调搜索数据接口 → 结果写 OSS → 日志进 SLS
六个要点：没有服务器、按运行计费、密钥走环境变量与服务角色、结果落对象存储、日志与告警托管。
二、函数代码骨架
在函数计算控制台创建 Python 函数，入口形如 main.handler：
import os, json, datetime, requests
def handler(event, context):
api_key = os.environ["SERPBASE_API_KEY"] # 在函数配置的环境变量里设置
keywords = ["关键词1", "关键词2", "关键词3"]
rows = []
for kw in keywords:
resp = requests.post(
"https://api.serpbase.dev/google/search",
headers={
"Content-Type": "application/json", "X-API-Key": api_key},
json={
"q": kw, "gl": "cn", "hl": "zh-cn"},
timeout=(3, 20),
)
data = resp.json()
if data.get("status") != 0:
# 失败落日志即可，别抛异常让整次调用崩掉
print(f"[WARN] {kw} status={data.get('status')} req={data.get('request_id')}")
continue
for r in data.get("organic", [])[:10]:
rows.append({
"kw": kw, "rank": r.get("rank"),
"title": r.get("title"), "link": r.get("link"),
})
payload = json.dumps(rows, ensure_ascii=False).encode("utf-8")
return {
"count": len(rows), "bytes": len(payload)}
三个工程要点：status 先判（业务失败不崩函数）、失败只记日志（部分失败不拖垮整批）、返回结构化摘要（便于云监控看指标）。
三、存储：结果落哪儿
函数是无状态的，结果必须外置。三种落点按场景选：
| 落点 | 形态 | 适合 |
|---|---|---|
| OSS 对象存储 | 按天分区的 JSON/CSV 文件 | 首选：便宜、免运维、便于后续分析（Parquet 也能放） |
| 表格存储 OTS | 结构化行记录 | 需要即时查询、点位查询的场景 |
| 日志服务 SLS | 日志行 | 只做监控不沉淀数据的轻场景 |
写 OSS 用官方 oss2 SDK，注意两点：把 oss2 打进代码包或做成依赖层；权限用「函数计算服务角色」授权到指定 Bucket，不要在代码里放 AK。
四、关键配置清单
- 环境变量：
SERPBASE_API_KEY放函数配置的环境变量（不要写进代码包） - 超时：按任务时长设置并留余量（函数超时上限以控制台当前限制为准）
- 内存：内存与费用相关；采集任务 I/O 为主，小规格通常够用
- 定时触发器：cron 表达式配置采集时间；注意时区——确认触发器时区与你预期的本地时间一致
- 重试与幂等：触发器可能重试，写存储时按「日期 + 关键词」去重（写同一路径覆盖或按唯一键 upsert），保证重跑不脏
五、观测与告警
- 日志：函数的
print自动进日志服务，用request_id检索一次调用的完整轨迹 - 指标：云监控直接给出调用次数、错误率、执行时长——给「错误率 > 0」和「执行时长异常」配告警
- 通知：告警动作接钉钉/邮件，和自建方案比，这条链路零代码
六、成本量级
函数计算按「调用次数 + 资源使用」计费，定时采集的场景（每天跑几十秒、每月几百次调用）通常落在很低的量级；OSS 存几 MB 到几百 MB 的 JSON 费用可忽略。对比一台常年开机的小服务器，Serverless 的第一个好处就是「不为闲置付费」。
七、踩坑记录
坑 1：把 AK 写进代码。 权限最小化的正解是「函数计算服务角色 + OSS 权限策略」，代码里只有业务逻辑。
坑 2：依赖没打包。 requests、oss2 不在默认环境里，本地跑通不等于云端能跑。依赖打 zip 或用层。
坑 3：超时设置拍脑袋。 定时任务配了 3 秒超时，一上量就超。按最慢批次两倍留余量，别贴边。
坑 4：忘了时区。 触发器跑在你没预期的时刻，日报全错位。上线前对照一次日志时间戳。
坑 5：重试把数据写重。 触发器重试 + 无幂等键 = 重复行。写入按 (日期, 关键词, link) 唯一化。
坑 6：失败静默。 单关键词失败悄悄跳过，月底才发现数据缺块。WARN 日志 + 云监控错误告警双保险。
小结
把定时采集搬到函数计算，本质是把「运维一台机器」换成「运维一段代码」：触发器管调度、OSS 管存储、SLS 管日志、云监控管告警，你只保留业务逻辑和密钥。对「每天跑一小会儿」的采集任务，这是目前综合成本最低的部署形态之一。
接口的响应信封（status、request_id）字段说明见 SerpBase 官方文档。利益相关说明：文中提到的数据服务是我自己在用的方案，花自己的钱，独立体验；云产品具体限制以阿里云官方文档为准。你的采集任务跑在服务器还是 Serverless 上？评论区聊聊。
