大雄行为锻炼去年帮一个做电商数据监测的客户搞弹性伸缩爬虫改造，客户原话我记得很清楚：“大促第一天爬虫集群撑不住了，监控大屏数据全断，商务那边电话被打爆。”这个场景在渠道商这边太常见了——爬虫跑得好好的，流量高峰一来就崩；可要是按高峰峰值配机器，平时又白白烧钱。这篇文章就是要把我们落地过的弹性伸缩爬虫方案掰开揉碎讲清楚，核心就三步：先让爬虫架构能横着加机器，再把弹性伸缩组配明白，最后用自动化“开关”接住流量高峰。做阿里云这块的渠道商、运维，或者自己爬虫项目遇到过负载问题的朋友，都能从这里拿到可以直接抄作业的配置思路。
1. 爬虫业务的流量规律：为什么固定配置机器总在“要么闲置、要么崩溃”
1.1 爬虫流量的三个典型特征
爬虫的流量模型跟常规Web应用差别很大。常规网站流量是用户行为驱动，早高峰、晚高峰、周末规律相对稳定；爬虫不一样，它的流量是被目标站点的数据更新节奏牵着的。
我总结了三个在实战里最明显的特征：
周期性明显。 很多目标站点数据在凌晨更新，或者每天固定时间点释放库存、放号、更新价格，这时候爬虫必须跟着冲。我之前一个客户做酒店价格监测，每天晚上11点到凌晨1点数据更新最频繁，爬虫负载是白天的四五倍。你要按这个峰值配机器，白天大部分时间CPU使用率不到10%。
突发性极强。 目标站点一搞活动、一发布新品，数据变化量瞬间暴涨。比如电商大促开场，商品详情页几分钟内可能变价几十次，爬虫为了抓完整数据链，采集频率得翻倍甚至是平时的十倍。这种突发没有任何规律可言，人工半夜起来扩机器根本来不及。
任务量不对称。 写一个能跑的爬虫很简单，但让它在高峰时能接住全部任务、不丢数据、不被封IP，这就不是脚本层面能解决的事了。大部分爬虫项目崩的不是解析逻辑，而是调度和资源分配。
1.2 固定配置的成本账：按峰值买是浪费，按均值买是赌博
很多客户一开始的想法是“直接上高配”，30台ECS全都按峰值负载来配。算一笔账就清楚了：
- 30台高配按量付费，假设单台一个月成本800元，一个月就是24000元。
- 如果峰值只在每天晚上出现两小时，一年下来大约只有1/12的时间真正需要这些资源，剩下11/12的资源等于在空转。
- 如果按均值配，比如只买15台，高峰期扛不住，数据链路断了，损失的不是几台机器的钱，而是客户对数据完整性的信任。
固定配置的问题在于它把“资源成本”和“服务质量”绑死在一起：想保质量就得承受浪费，想省钱就得冒崩的风险。弹性伸缩的存在就是把这组矛盾解开。
1.3 渠道商视角：客户真正要的不是服务器，是 SLA
做渠道商跟做自用还有一个区别：客户不关心你底层是ECS还是裸金属，不关心你用的是伸缩组还是手工加机器，他们只关心两件事——数据完整率多少，月底账单多少。
所以我们在给客户设计方案时，从来不说“我帮你配了弹性伸缩”，而是说“你的爬虫在流量高峰也能保证数据完整率在99.9%，并且平时不会为用不上的机器多花一分钱”。弹性伸缩是手段，保障SLA才是目的。
想通这一点，后面的所有技术选型就都有了判断标准：任何设计如果让架构更复杂却换不来SLA提升或成本下降，都是多余的。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 第1步：把爬虫从单机进程改造成“可横向扩展的积木”
2.1 无状态化：弹性伸缩的前提条件
弹性伸缩最怕遇到“有状态”的应用。什么是“有状态”？就是你这一台机器挂了，它身上的任务、缓存、会话也跟着丢了，新机器接手不了。
很多爬虫项目早期是单机跑的，状态全攒在本地：
- 待抓取的URL列表放在进程内存里
- 请求去重用的集合是本地的一个set
- 抓取进度、断点信息写在磁盘文件里
- 甚至有的把代理IP池也维护在本地内存
这种架构别说弹性伸缩，连换个机器重启都是灾难。我接手过一个客户，爬虫跑到一半服务器宕机，重启之后从断点继续跑的逻辑没写好，结果同一个页面被重复抓了十几万次，数据全是脏的。
所以要改造的第一步，就是把所有状态从机器里“赶出去”：
| 原本存在哪 | 问题 | 改造后放哪 |
|---|---|---|
| 待抓取URL在进程内存 | 重启丢失 | Redis List / Stream |
| 去重集合在本地set | 多机无法共享 | Redis Set / Bloom Filter |
| 进度断点写在磁盘 | 机器释放即丢 | Redis / 数据库 |
| 调度任务靠crontab | 无全局视角 | Celery Beat / 自研调度 |
改造完之后，每一台爬虫机器就变成了一个“无状态工人”：它不关心自己接的是哪个任务，不关心上一个任务是谁干的，任何一台新机器起来之后，只要能从Redis里拉到任务，就能立刻进入工作状态。
2.2 任务调度层：Redis队列 + Worker的经典组合
无状态化改造的核心是任务队列。爬虫场景里最常用也最稳的组合是“Redis队列 + 多Worker消费”。
我习惯把整个爬虫拆成三层：
采集层（Worker）：只负责发HTTP请求、拿HTML/JSON、做初步解析。每个Worker是无状态的，数量可以随便横向扩。
调度层（Queue/Scheduler）：用Redis做任务池。采集层把需要抓的URL按优先级推进队列，Worker从队列里LPOP/BRPOP出来执行。用Redis的好处是它本身支持高并发读写，而且你可以在队列长度上做文章——队列积压多少，就代表当前负载有多高，这个特性后面做弹性伸缩会非常有用。
存储层（Storage）：抓到的数据统一写到数据库或OSS，Worker不落任何本地数据。
具体选型上，两个主流方案：
- 如果你用的是Scrapy全家桶，直接上
scrapy-redis，它就是把Scrapy原本在本地跑的调度器和去重器换成了Redis实现，改造量很小，把DUPEFILTER_CLASS、SCHEDULER等配置指到scrapy-redis就行。 - 如果你的爬虫是自己用
requests/httpx写的，那直接用Celery做异步任务分发最顺。Celery自带重试、优先级、任务路由，配合Redis Broker非常成熟。
2.3 抓取节点的横向扩展能力
改完无状态之后，要让“新机器启动即干活”，还需要把环境固化成镜像。
我强烈建议你用阿里云的ECS自定义镜像或者镜像模板把Python环境、依赖库、爬虫代码、启动脚本全部打进去。这样新实例一启动，不需要再执行pip install、不需要再git clone代码，直接执行启动命令就能变成爬虫Worker。
这里有个细节很多人忽略：镜像里的代码要做成“启动时自更新”。因为你打包镜像的那一刻和真正扩容的那一刻中间隔了很久，代码可能已经更新了好几版。最简单的做法是写一个启动脚本：
bash复制#!/bin/bash
# 拉取最新代码
cd /opt/spider
git pull origin master
# 安装新依赖（如果requirements有变化）
pip3 install -r requirements.txt --quiet
# 启动 Worker，注册到 Redis 队列
nohup python3 worker.py > /var/log/worker.log 2>&1 &
这样做的好处是：镜像不用频繁重新制作，代码更新之后新实例启动时自动拉新版本；坏处是启动时间会因为git pull和pip install而变长。所以更讲究一点的做法是把“拉代码”流程去掉，代码直接打进镜像，用容器镜像的tag管理版本，扩出来的机器秒级进入工作状态。
不管用哪种，都要保证一个核心指标：从实例创建到开始消费任务，时间尽量控制在2分钟以内。这一步做不好，后面所有弹性伸缩的效果都会打折扣。
3. 第2步：搞定弹性伸缩组的三个核心配置（附操作示例）
3.1 伸缩组、伸缩配置、伸缩规则的关系
很多第一次接触阿里云弹性伸缩的人会被一堆概念搞晕：伸缩组、伸缩配置、伸缩规则、报警任务、生命周期挂钩、冷却时间……其实理清楚很简单：
- 伸缩配置：定义“新机器长什么样”，相当于一份实例启动模板，包含镜像ID、实例规格、安全组、登录密钥、UserData等。
- 伸缩组：定义“这些机器归谁管”，指定地域、可用区、交换机、负载均衡、最大/最小实例数。
- 伸缩规则：定义“什么时候扩、什么时候缩”，可以是定时执行，也可以是云监控报警触发。
- 生命周期挂钩：定义“机器被释放前能不能给我点时间处理后事”。
实际操作路径是：先做伸缩配置，再建伸缩组，然后在伸缩组里绑定伸缩规则和生命周期挂钩。
我给你的最小可运行配置：
| 配置项 | 推荐值 | 说明 |
|---|---|---|
| 地域/可用区 | 与目标站在同一地域 | 减少网络延迟 |
| 交换机 | 至少2个可用区各一个 | 避免单可用区故障 |
| 负载均衡 | 如无对外服务可不挂 | 爬虫一般不需要对外暴露入口 |
| 最小实例数 | 2 | 保留基础水位，防止任务断流 |
| 最大实例数 | 20 | 控制成本上限，防止预算失控 |
| 默认冷却时间 | 300秒 | 防止频繁伸缩抖动 |
| 移出实例保护 | 建议开启 | 重要！防止缩容时杀掉正在跑任务的机器 |
这里特别提醒那句“移出实例保护”：如果你的伸缩组里同时跑着别的业务服务，或者你希望缩容时由你的逻辑来决定哪些机器退出，一定要开启这个保护。不开启的话，伸缩组会优先释放最早创建的实例，可能正好就是你正在跑大任务的那台。
3.2 伸缩规则：定时任务和报警任务怎么配合
伸缩规则有两种主要类型，我分别说一下适用场景。
定时任务：适合能提前预知的流量高峰。比如客户明天零点做秒杀活动，你可以提前创建好定时任务，在晚上10点先扩到20台，凌晨2点再缩回5台。这种方式最大的优势是“从容”，机器提前就位，流量来了直接扛。
报警任务：适合无法预知的突发流量。基于云监控的指标（CPU利用率、内存使用率、负载等）设置阈值，突破了就触发扩容。
但纯用报警任务有一个坑：CPU指标严重滞后。爬虫这类IO密集型应用，CPU通常不会飙得很高，往往是Redis队列里积压了几十万个任务，CPU才刚到60%。如果只盯CPU扩容，等你看到CPU升高再触发扩机器，到新机器能开始消费任务，可能已经过去五六分钟了，积压只会越来越严重。
所以我的经验是：定时任务打底，自定义指标扩容。定时任务保证大促前资源先到位；自定义指标（比如Redis队列积压量）保证突发情况下能快速反应。关于自定义指标，我在第4小节详细说。
3.3 冷却时间、最小/最大实例数的正确姿势
冷却时间这个参数，默认300秒，新手经常会问“要不要调短一点让扩容更快”。我的建议是：扩容侧可以通过生命周期挂钩绕开冷却限制，但缩容侧的冷却时间千万别调太短。
原因很简单：爬虫任务的负载是波动的，队列积压可能只是某几分钟的瞬时现象。如果缩容冷却时间太短，伸缩组会把刚扩出来的机器又缩回去，过几分钟流量再上来又得重新扩，一来一回实例创建销毁的成本比你省下的机器费用高得多。
最小实例数和最大实例数则是你安全护栏：
- 最小实例数建议设置成“能扛住基本业务流量的数量”，保证队列不会因为实例全被缩掉而完全没人消费。
- 最大实例数设置成“预算能接受的上限”，哪怕是报警规则误触发了，也不会造成账单失控。
我见过一个客户，最大实例数没设，结果某天某个规则写错了，一夜之间扩出来一百多台按量实例，第二天看到账单人都傻了。这个护栏谁也别省。
4. 第3步：让“流量高峰”自动打开爬虫的扩缩容开关
4.1 更灵敏的“水位计”：用消息队列积压量当伸缩指标
现在要解决一个核心问题：怎么才算是“流量高峰”？
我们的答案是：别看机器指标，看队列积压量。
爬虫架构改成“Redis队列 + Worker”之后，Redis里的待处理任务数量就是最理想的负载指标。它天然反映了“当前需要多少计算资源”：积压多，说明Worker不够；积压少，说明资源富余。
阿里云弹性伸缩支持自定义云监控指标，流程是这样的：
- 在每台爬虫Worker上，用Python脚本定期从Redis读取队列长度（
LLEN key），这个脚本作为自定义监控数据上报给云监控。
python复制# report_metric.py
import json
import redis
from aliyunsdkcore.client import AcsClient
from aliyunsdkcms.request.v20190101 import PutCustomMetricRequest
r = redis.Redis(host='your-redis-host', port=6379, db=0)
client = AcsClient('your-access-key', 'your-secret', 'cn-hangzhou')
def report():
# 读取待处理爬虫任务队列长度
pending = r.llen('spider:tasks')
metrics = [{
"metricName": "spider_pending_tasks",
"dimensions": {"instanceId": "scaling-group"},
"value": pending,
"type": "gauge"
}]
request = PutCustomMetricRequest.PutCustomMetricRequest()
request.set_MetricList(json.dumps(metrics))
client.do_action_with_exception(request)
if __name__ == '__main__':
report()
- 在云监控控制台创建自定义监控项
spider_pending_tasks。 - 在弹性伸缩组的报警任务中，选择该自定义指标，设置规则：例如“积压任务数大于10000持续5分钟”触发扩容，“积压任务数小于1000持续10分钟”触发缩容。
这样一套下来，扩容和缩容完全跟着真实业务压力走，不再被CPU、内存这些二手指标误导。
4.2 生命周期挂钩：缩容之前先让爬虫“优雅下班”
这是整个方案里最容易被忽略但最关键的环节。
默认情况下，弹性伸缩缩容是直接释放ECS实例的。如果你的Worker正在跑一个页面抓取任务，请求发出去还没收到响应，实例被释放，这一条任务就平白丢了。短时间丢掉几个任务还好，如果每次都丢，数据完整性根本达不到客户SLA。
解决方案就是生命周期挂钩。
流程是这样的：
- 手动创建生命周期挂钩，关联到伸缩组上，指定触发动作是“缩容”。
- 当伸缩组准备释放一个实例时，它先不立即释放，而是让实例进入“等待状态”，同时往一个MQTT/消息通知发一条事件，告诉你有实例即将被释放。
- 你的Worker收到通知后，先停止从Redis队列拉新任务，把正在进行的请求处理完，然后再调用API上报处理完成。
- 伸缩组收到“处理完成”信号后，继续执行释放流程。
操作上关键就是那段“收尾逻辑”，我用Celery Worker举个例子：
python复制from celery.signals import worker_shutting_down
@worker_shutting_down.connect
def on_shutdown(sender, **kwargs):
# 1. 停止接收新任务
sender.control.cancel_consumer()
# 2. 等待当前执行中的任务完成（设置超时）
sender.control.time_limit()
# 3. 通知伸缩组可以释放实例
call_complete_lifecycle_action()
如果收尾时间太长，生命周期挂钩有超时机制，默认最长等待时间你可以调整。我建议设成300秒，同时你在Worker里要保证一个请求的最大超时时间小于这个值，宁可放弃个别超时任务，也不能让整批机器卡在收尾阶段。
4.3 完整闭环：从积压到扩容再到缩容的自动化流程
把所有环节串起来，完整的自动化闭环是这样的：
- Redis队列里积压的任务数持续上涨。
- Worker上报的自定义监控指标
spider_pending_tasks超过阈值。 - 云监控触发伸缩组报警任务。
- 弹性伸缩组执行扩容规则，创建新ECS实例。
- 新实例启动，镜像里的启动脚本自动拉取最新代码并启动Worker。
- Worker连接Redis并注册自己，开始消费积压任务。
- 队列积压逐渐下降。
- 持续一段时间低于缩容阈值后，伸缩组触发缩容。
- 生命周期挂钩截住即将释放的实例，让Worker完成收尾。
- 实例释放，整个架构回到基础水位。
这套流程在凌晨两三点流量突发时尤其有价值——不需要任何人工干预。我之前有一次半夜被客户电话叫醒，结果打开控制台一看，扩缩容已经自动跑完了，数据分析大屏数据一条没断。
5. 实战中踩过的坑和能直接抄的优化方案
5.1 扩容后实例“不干活”的老大难问题
第一次上线这套方案时，我们在压测阶段就发现一个问题：伸缩组确实扩容了，新实例状态也显示运行中，但Redis队列里的积压任务就是没被消费。
排查下来，原因有两个：
一是新实例启动后，Worker注册到Redis的耗时比预期的长。启动脚本里有git pull和pip install，在依赖很多的情况下，这个过程可能超过5分钟。这个阶段实例虽然活着，但还不具备消费能力。
二是scrapy-redis在Worker启动时，会从Redis里拉取分配给自己的一批任务。如果新Worker启动速度慢，等它拉任务的时候，积压的任务可能已经被其他Worker分了，新Worker就处于“看着活着、实际闲置”的状态。
解决方案：
- 把依赖完全打进镜像，禁止启动时执行
pip install。 - 用健康检查机制：实例启动后，先确认Worker进程已经在Redis里注册成功，再让伸缩组认为实例“健康”。可以通过UserData脚本在Worker成功注册后写入一个标志文件，云监控再根据这个做健康检查。
- 给扩容规则增加一个“预热时间”的概念：新实例需要一两分钟才能开始消费任务，所以触发扩容的阈值要稍微激进一点，让扩容动作提前发生。
5.2 缩容时正在执行的请求被硬杀
这是生命周期挂钩没做好之前我们遇到的第二个坑。当时客户反馈数据有缺口，查日志发现大量请求发出去了，但响应没存上。原因是缩容时实例被直接释放，Socket连接被掐断，请求自然就废了。
解决路径在前面已经写了：生命周期挂钩 + Worker信号处理。补充一个要点：收尾逻辑一定要测。我们后来专门写了一个脚本模拟缩容信号，确认进程能处理完当前请求再退出。这里花半天时间测试，比你在生产环境丢数据再排查要划算得多。
另外，如果你用的是Scrapy，要注意Scrapy在收到SIGTERM后会先等当前Request完成再退出，但这个行为在新版本里有过变化，最好自己在信号处理里加一个显式确认，别完全依赖框架默认行为。
5.3 出口IP被封的问题：弹性公网IP和代理池策略
爬虫扩容之后，Worker数量变多，出口IP也随之变多。如果目标站点对单IP的请求频率有限制，你会发现一个尴尬的局面：机器多了，但被封的IP也多了，整体抓取成功率反而下降。
这里有两个方向：
一是出口统一走NAT网关或者弹性公网IP池，把出口IP收敛到少数几个，然后在代码里控制每个IP的并发数和请求频率。适合目标站点对IP数量不敏感、只看频率的场景。
二是维护一个代理IP池，Worker每次请求轮换出口IP。适合目标站点对单IP请求数卡得很死的场景。代理池本身要单独部署，也可以用市面上成熟的付费代理服务。
不管哪种方向，我都要提醒一句：爬虫的边界是合规采集，只抓你有权限访问的数据，遵守目标站点的robots规则和平台条款。这个咱们做技术的心里得有根弦。
5.4 费用失控的防守：混合付费模式与实例保护
弹性伸缩如果配置不当，费用失控是分分钟的事。我的防守策略是三层：
第一层：把常驻的基础池用包年包月实例。比如最小实例数2台，这两台走包年包月，价格比按量便宜很多，稳定扛基础流量。
第二层：弹性池用按量实例，弹性伸缩创建的实例全部是按量付费，用多少付多少，高峰过了就释放。
第三层：如果能容忍任务中断重试，可以把弹性池换成抢占式实例。抢占式实例价格是按量的两折左右，但存在被系统回收的风险。对爬虫场景来说，任务中断了无非是重新入队重试，用生命周期挂钩断点续跑，整体成本能再降一半。
我之前给一个客户做完这套混合策略，客户月初看到账单之后专门跑来问“是不是漏算了什么”——成本比之前纯按量降了60%多。
6. 渠道商落地这套方案的实操清单与交付思路
6.1 上线前必须做的三件验证
我自己不论给哪个客户做方案，上线前有三件事是雷打不动的：
压测验证扩容效果。 不要等到大促当天才看效果。提前用脚本往Redis队列里塞大规模的任务，触发扩容规则，记录下从任务注入到全部消费完成的时长。至少要验证两轮：扩容阶段和缩容阶段。
演练缩容收尾。 手动触发缩容规则，观察Worker是否能优雅退出，Redis里是否还有遗留任务。如果缩容后队列里还有没消费完的积压，说明你的收尾逻辑有问题，得调整。
验证监控告警链路。 故意把Redis队列塞满，确认自定义监控指标能正常上报、云监控告警能触发、伸缩组能接到报警。这三环任何一个环节断掉，前面的所有配置等于白做。
6.2 给客户的报价和服务清单
做渠道商，一份清晰的报价方案比技术方案更容易签单。我的经验是把服务分成两部分报价：
基础服务：包含常驻实例的包年包月费用、负载均衡、数据库、Redis等固定成本，按月或按年报价。
弹性服务：包含按量付费实例的预估费用、弹性伸缩组的管理费用、监控服务费用。这块我通常给客户一个区间预估，比如“每月弹性费用预计在X到Y之间，封顶Z”，让客户心里有底。
交付文档里一定要包含这几样东西：架构图（画清楚数据流）、伸缩规则配置表（每条规则触发条件、扩缩容数量）、应急预案（监控告警了谁来看、怎么处理）、费用模型（什么情况下费用最坏会到多少）。
6.3 值得提前准备的模板和脚本
做渠道商做久了就会发现，不同客户的爬虫架构虽然长得不一样，但改造思路和伸缩配置高度相似。把通用部分沉淀成模板，能大幅降低交付成本。我现在手头常备这几套东西：
- 一套无状态化改造检查清单（哪些代码必须改、哪些可以留）
- 一个标准的Worker启动脚本模板（拉代码、装依赖、启动、上报健康状态）
- 一组生命周期挂钩的收尾代码（分别给Celery和Scrapy写了版本）
- 一份伸缩组配置表格（各项参数怎么填，附带推荐值和理由）
- 一个费用测算Excel（输入日活任务量、目标站点规模，自动估算弹性费用区间）
有这五样东西在手，一个客户从首次交流到方案落地，周期能从两周压缩到两三天。对渠道商来说，这省下来的时间就是利润。
最后再分享一点个人体会：弹性伸缩这个东西，配置本身不复杂，复杂的是你得对业务负载模型有足够深的理解。只想着“配置一个伸缩组”是不够的，你得先想清楚流量从哪里来、积压怎么衡量、机器退场时任务怎么办。这套逻辑理清了，无论用阿里云还是别的平台，都是同一套思路。踩过几次坑之后我最大的心得就是：先把架构改造成能扩缩的样子，再去做弹性伸缩的配置，顺序千万别反过来。