三步搞定弹性伸缩爬虫：架构改造与流量高峰自动扩缩容

去年帮一个做电商数据监测的客户搞弹性伸缩爬虫改造，客户原话我记得很清楚：“大促第一天爬虫集群撑不住了，监控大屏数据全断，商务那边电话被打爆。”这个场景在渠道商这边太常见了——爬虫跑得好好的，流量高峰一来就崩；可要是按高峰峰值配机器，平时又白白烧钱。这篇文章就是要把我们落地过的弹性伸缩爬虫方案掰开揉碎讲清楚，核心就三步：先让爬虫架构能横着加机器，再把弹性伸缩组配明白，最后用自动化“开关”接住流量高峰。做阿里云这块的渠道商、运维，或者自己爬虫项目遇到过负载问题的朋友，都能从这里拿到可以直接抄作业的配置思路。

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提升或成本下降，都是多余的。

2. 第1步：把爬虫从单机进程改造成“可横向扩展的积木”

2.1 无状态化：弹性伸缩的前提条件

弹性伸缩最怕遇到“有状态”的应用。什么是“有状态”？就是你这一台机器挂了，它身上的任务、缓存、会话也跟着丢了，新机器接手不了。

很多爬虫项目早期是单机跑的，状态全攒在本地：

• 待抓取的URL列表放在进程内存里
• 请求去重用的集合是本地的一个set
• 抓取进度、断点信息写在磁盘文件里
• 甚至有的把代理IP池也维护在本地内存

这种架构别说弹性伸缩，连换个机器重启都是灾难。我接手过一个客户，爬虫跑到一半服务器宕机，重启之后从断点继续跑的逻辑没写好，结果同一个页面被重复抓了十几万次，数据全是脏的。

所以要改造的第一步，就是把所有状态从机器里“赶出去”：

改造完之后，每一台爬虫机器就变成了一个“无状态工人”：它不关心自己接的是哪个任务，不关心上一个任务是谁干的，任何一台新机器起来之后，只要能从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等。
• 伸缩组：定义“这些机器归谁管”，指定地域、可用区、交换机、负载均衡、最大/最小实例数。
• 伸缩规则：定义“什么时候扩、什么时候缩”，可以是定时执行，也可以是云监控报警触发。
• 生命周期挂钩：定义“机器被释放前能不能给我点时间处理后事”。

实际操作路径是：先做伸缩配置，再建伸缩组，然后在伸缩组里绑定伸缩规则和生命周期挂钩。

我给你的最小可运行配置：

这里特别提醒那句“移出实例保护”：如果你的伸缩组里同时跑着别的业务服务，或者你希望缩容时由你的逻辑来决定哪些机器退出，一定要开启这个保护。不开启的话，伸缩组会优先释放最早创建的实例，可能正好就是你正在跑大任务的那台。

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不够；积压少，说明资源富余。

阿里云弹性伸缩支持自定义云监控指标，流程是这样的：

1. 在每台爬虫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()

2. 在云监控控制台创建自定义监控项spider_pending_tasks。
3. 在弹性伸缩组的报警任务中，选择该自定义指标，设置规则：例如“积压任务数大于10000持续5分钟”触发扩容，“积压任务数小于1000持续10分钟”触发缩容。

这样一套下来，扩容和缩容完全跟着真实业务压力走，不再被CPU、内存这些二手指标误导。

4.2 生命周期挂钩：缩容之前先让爬虫“优雅下班”

这是整个方案里最容易被忽略但最关键的环节。

默认情况下，弹性伸缩缩容是直接释放ECS实例的。如果你的Worker正在跑一个页面抓取任务，请求发出去还没收到响应，实例被释放，这一条任务就平白丢了。短时间丢掉几个任务还好，如果每次都丢，数据完整性根本达不到客户SLA。

解决方案就是生命周期挂钩。

流程是这样的：

1. 手动创建生命周期挂钩，关联到伸缩组上，指定触发动作是“缩容”。
2. 当伸缩组准备释放一个实例时，它先不立即释放，而是让实例进入“等待状态”，同时往一个MQTT/消息通知发一条事件，告诉你有实例即将被释放。
3. 你的Worker收到通知后，先停止从Redis队列拉新任务，把正在进行的请求处理完，然后再调用API上报处理完成。
4. 伸缩组收到“处理完成”信号后，继续执行释放流程。

操作上关键就是那段“收尾逻辑”，我用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 完整闭环：从积压到扩容再到缩容的自动化流程

把所有环节串起来，完整的自动化闭环是这样的：

1. Redis队列里积压的任务数持续上涨。
2. Worker上报的自定义监控指标spider_pending_tasks超过阈值。
3. 云监控触发伸缩组报警任务。
4. 弹性伸缩组执行扩容规则，创建新ECS实例。
5. 新实例启动，镜像里的启动脚本自动拉取最新代码并启动Worker。
6. Worker连接Redis并注册自己，开始消费积压任务。
7. 队列积压逐渐下降。
8. 持续一段时间低于缩容阈值后，伸缩组触发缩容。
9. 生命周期挂钩截住即将释放的实例，让Worker完成收尾。
10. 实例释放，整个架构回到基础水位。

这套流程在凌晨两三点流量突发时尤其有价值——不需要任何人工干预。我之前有一次半夜被客户电话叫醒，结果打开控制台一看，扩缩容已经自动跑完了，数据分析大屏数据一条没断。

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（输入日活任务量、目标站点规模，自动估算弹性费用区间）

有这五样东西在手，一个客户从首次交流到方案落地，周期能从两周压缩到两三天。对渠道商来说，这省下来的时间就是利润。

最后再分享一点个人体会：弹性伸缩这个东西，配置本身不复杂，复杂的是你得对业务负载模型有足够深的理解。只想着“配置一个伸缩组”是不够的，你得先想清楚流量从哪里来、积压怎么衡量、机器退场时任务怎么办。这套逻辑理清了，无论用阿里云还是别的平台，都是同一套思路。踩过几次坑之后我最大的心得就是：先把架构改造成能扩缩的样子，再去做弹性伸缩的配置，顺序千万别反过来。