无头集群与云原生抓取

本文基于模型知识整理，建议核对官方文档（见 参考资料）。

一句话定义

云原生抓取把 worker（含无头浏览器）容器化，交给容器编排或定时触发器调度，实现「按需伸缩、失败自动重启、零手工运维」的采集基础设施。

为什么重要

手工跑在个人电脑上的采集任务无法承诺可靠性（断电、休眠、IP 变动）。容器化 + 云调度让「每天 6 点自动跑、挂了自动重试、结果落对象存储」成为零值守的默认形态——这是采集任务从脚本变成服务的最后一步。

前置知识

kp-022（分布式拓扑）、kp-013（无头浏览器）。

核心概念

• 容器化：把运行环境（Python + 依赖 + 浏览器内核）打成镜像，任何宿主机行为一致。
• 资源账：无头 Chromium 单实例约 300–600MB 内存；容量规划按「并发实例数 × 内存」算。
• 定时触发：云函数定时器 / Kubernetes CronJob / 系统 crontab，按计划拉起任务。
• 无状态约束：Serverless 函数限时（常见 5–15 分钟）且不保状态——长任务须改为「分片入队，多次触发消费」（kp-021 队列复用）。

原理与机制

容器化 worker 的最小形态（Dockerfile 骨架）：

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt \
    && python -m playwright install --with-deps chromium
COPY . .
CMD ["python", "worker.py"]          # worker 内部: 连队列→抓取→回写( kp-022 )

部署拓扑（把 kp-022 的图搬上云）：

定时器(每天06:00) → 触发 seed 任务: 生成/刷新 URL 队列入 Redis
队列(Redis/云队列) ← 消费 ← worker 容器 × N (自动伸缩, 崩溃即重启)
                              ↓
                    结果 → 对象存储(raw层) / 数据库(clean层)
监控: 心跳指标外发( kp-023 ) → 阈值告警推送

Serverless 适配要点：把「一次抓全站」改写成「每次触发消费队列 100 条」；实例内用 asyncio（kp-019）提满限速上限内的吞吐；冷启动敏感的浏览器任务倾向常驻小实例而非纯函数。

实例或案例

价格监控上云后的形态：一台 2C4G 主机跑 Docker，两个常驻 worker（各绑一个出口）+ crontab 触发种子任务；七个月零人工干预，期间三次站点改版均由 kp-023 告警在 1 小时内发现。总成本低于一杯咖啡/月——可靠性来自架构，不来自人力值守。

常见误区

• 误区一：镜像里忘装浏览器依赖。 Playwright 的 --with-deps 或官方镜像可避免「本地能跑容器里缺 so」的经典坑。
• 误区二：Serverless 硬塞长任务。 超时被杀导致半截数据；必须分片化并依赖队列续传。
• 误区三：无监控上云。 云端「安静失败」更隐蔽（无人看日志）；kp-023 的心跳与水位线是上云前置条件而非事后补充。

自测题

1. 无头浏览器的容量如何估算？

答：按并发实例数 × 单实例内存（约 300–600MB）+ 系统余量；并发受限速约束而非机器上限。

1. Serverless 跑采集的核心改造是什么？

答：长任务分片化——每次触发消费固定批量队列，状态在队列与存储中，函数本身无状态。

1. 上云前必须就位的三件事？

答：容器化镜像（含浏览器依赖）、任务队列与断点续抓、心跳监控与告警。

与其他知识点的关系

kp-022 提供分布式拓扑，本篇是其云上落地；kp-019 决定 worker 内部并发模型；kp-023 是云上可观测性的实现。

延伸阅读

Playwright 官方 Docker 文档；Kubernetes CronJob 官方文档（概念部分）。