先给结论：
我们把采集系统从单机迁到集群，不是因为跑不动了，而是因为开始不敢相信结果了。
一、单机采集一开始真的没问题
最早的系统很简单：
一台服务器
Python + requests
多线程
定时任务跑完入库
业务是金融、舆情类数据监控。
在很长一段时间里：
不报错
不报警
数据“看起来”正常
所以单机爬虫本身没有错，它非常适合探索期。
二、真正的问题，出现得很安静
转折点不是宕机，而是一句反馈：
“这天的数据，怎么比前一天少？”
程序是跑完的
HTTP 状态码大多是 200
但数据不完整。
这是单机爬虫最危险的一类失败。
三、单机采集最致命的问题：失败是无声的
复盘下来，问题集中在三点：
IP 被封不一定报错，返回空页面也算成功
稳定性依赖工程师经验，而不是系统感知
出问题后只能人工排查和补跑
系统本身并不知道自己“不可靠”。
四、为什么我们没有继续“再优化一下单机”
当时也讨论过：
多加线程
多接代理 IP
多写异常处理
但这些做的只是提高成功概率。
而业务真正问的是：
“今天的数据，完整吗？”
单机爬虫回答不了这个问题。
五、集群化之后，我们只做了两件关键改变
第一，调度和执行彻底分离
第二，代理 IP 从补丁升级为基础设施
执行节点不做判断，只做执行。
六、核心代码示例：Worker 为什么可以这么“傻”
下面这段代码，就是集群中 Worker 节点的核心执行逻辑。
它的设计目标只有一句话：
不追求聪明，只追求可控。
1. 亿牛云爬虫代理统一配置
# 代理配置（所有 Worker 统一使用）
PROXY_HOST = "proxy.16yun.cn" # 代理域名
PROXY_PORT = "8000" # 代理端口
PROXY_USER = "your_username" # 代理用户名
PROXY_PASS = "your_password" # 代理密码
proxy_url = f"http://{PROXY_USER}:{PROXY_PASS}@{PROXY_HOST}:{PROXY_PORT}"
proxies = {
"http": proxy_url,
"https": proxy_url
}
这一步的意义不是“能翻墙”，而是：
所有请求的失败率，第一次变成了可统计、可评估的指标。
2. Worker 执行单条任务（无状态）
import requests
import time
def fetch(url, retry=3):
"""
Worker 只负责执行请求，不负责全局判断
"""
headers = {
"User-Agent": "Mozilla/5.0 (compatible; Spider/1.0)"
}
for _ in range(retry):
try:
resp = requests.get(
url,
headers=headers,
proxies=proxies,
timeout=10
)
# 成功的定义非常保守
if resp.status_code == 200 and resp.text.strip():
return resp.text
time.sleep(1)
except Exception:
time.sleep(1)
# 失败结果直接返回，由调度层决定后续策略
return None
注意这里刻意没有：
任务重试策略升级
失败告警
数据入库
日志聚合
原因很简单：
Worker 越复杂，系统越不可控。
3. 失败交给调度层，而不是 Worker“自作主张”
在集群模式下：
Worker 只回答一件事：
“这个任务，我成功了，还是失败了？”
至于：
要不要重试
要不要换节点
要不要标记为异常数据
这是调度层的职责。
七、迁移完成后，真正改变的是什么
不是“抓得更快了”，而是：
哪条数据没抓到，是已知的
哪天数据不完整，可以提前告知
失败不再靠人兜底
在金融、舆情这种场景里，这比吞吐量重要得多。
八、最后一句复盘
如果只留一句话：
爬虫从单机到集群，往往不是技术升级，而是你开始为结果负责了。
当你需要回答“数据可不可靠”这个问题时，
单机方案，基本已经走到尽头。
