大规模无状态爬虫系统设计
这篇文章记录的是一套大规模无状态爬虫系统的设计。
先说明一下参与边界：这套系统不是我一个人独立设计完成的。我主要负责爬虫端的核心设计和实现，另一位同事是项目主要负责人，他有十余年的架构设计经验，整体系统设计、调度中心以及很多关键取舍都由他主导。我在这个系统里更多是站在爬虫端视角，参与了一套大规模无状态爬虫体系的落地。
也正因为那时自己还是初入职场，所以这套设计对我的意义不只是“写了一个爬虫”，而是第一次比较完整地看到：爬虫在工程系统里不应该只是脚本，它可以是一个被调度、被扩容、被监控、可替换的采集节点。
本文只讨论在授权和合规范围内的数据采集系统设计，不涉及绕过站点安全机制或采集敏感数据。
为什么没有继续用 Scrapy
Section titled “为什么没有继续用 Scrapy”在做这个项目之前，Scrapy 是很自然会被想到的方案。
它有成熟的爬虫生命周期、调度器、下载器、中间件、管道、去重、状态管理等能力。对于中小规模、结构清晰、业务变化不频繁的采集任务来说，Scrapy 确实是一套完整方案。
但这套系统面对的问题不太一样。
我们更关注的是大规模任务下的采集吞吐、任务调度、账号分配、异常处理和快速扩容。Scrapy 自带的体系虽然完整，但学习成本较高，入手较慢，架构也相对复杂。尤其当系统需要把任务状态、账号状态、异常流转、代理分配、补偿处理这些能力统一放到一个调度中心管理时，爬虫本身再保留太多状态，反而会让边界变得不清楚。
所以最后的方向是：不沿用 Scrapy 的架构模式，而是结合现有高并发框架，设计一套更轻、更快、更容易水平扩展的无状态爬虫系统。
爬虫核心只负责一件事：拿到任务后尽快完成数据抓取，包括必要的增量更新，然后把结果交给后续链路。
系统整体结构
Section titled “系统整体结构”按当时的架构草图抽象后，整体链路大概是这样：
在这个体系里，Java 服务承担调度中心的角色。它负责任务协调、账号分配、账号状态管理、异常状态流转、代理下发等能力。
爬虫端则被刻意设计得很薄。
爬虫启动后向调度中心领取任务。调度中心在下发任务时，会同时给出这次采集所需的账号和代理。爬虫拿到这些一次性上下文后开始采集，采集完成后把数据写入 Kafka，并向调度中心汇报任务结果和心跳状态。
这里的“一次性”不是指账号用一次就丢弃，而是指一次采集任务内绑定一次任务、账号和代理。任务结束后，账号会根据结果重新回到有效账号池，或者进入异常账号池，等待专门的登录模块重新处理。
为什么要让爬虫无状态
Section titled “为什么要让爬虫无状态”我觉得这套系统里最关键的设计，就是把爬虫做成无状态。
传统爬虫经常会在自己内部维护很多信息：当前任务跑到哪一步、账号是否可用、代理是否失效、失败后要不要重试、异常应该怎么处理、下次从哪里继续等。
这些能力当然有价值，但如果所有爬虫节点都各自维护状态，系统规模一大，就会出现几个问题：
- 单个爬虫节点变重，扩容和迁移成本变高。
- 账号、代理、任务状态分散在各处，难以统一判断。
- 某个节点异常退出后，恢复逻辑复杂。
- 错误处理混在采集逻辑里，爬虫代码越来越难维护。
无状态的思路是反过来的：爬虫只负责执行当前任务，不负责长期持有状态。
它不决定一个账号后续应该怎么处理，也不决定一个异常任务最终怎么补偿。它只把采集过程中的结果、错误和心跳上报给调度中心，由调度中心再调度给对应的处理模块。
这样做以后，爬虫端会变得非常轻。
如果某个爬虫节点挂了，系统只需要感知它心跳消失，再把未完成任务重新调度出去。爬虫本身不需要承担复杂恢复逻辑。对于我当时负责的爬虫端来说，这个设计最大的好处就是：代码目标非常明确，采集就是采集，错误就是上报。
单次任务为什么能做到很快
Section titled “单次任务为什么能做到很快”这套系统里，爬虫单次采集任务大约 15 秒左右就可以完成。
它能快起来，原因不只是“并发写得高”，更重要的是系统边界清楚。
调度中心已经提前准备好了任务、账号和代理，爬虫不需要在执行过程中再做大量决策。拿到任务后，爬虫可以直接进入采集流程。它只处理当前任务所需的请求、解析、增量判断和结果投递。
采集结果进入 Kafka 后，后面的清洗、聚合、存储交给 Flink 和 ES 链路。爬虫不在本地做过多处理，也不会把数据链路和采集链路耦合在一起。
从工程上看，这其实是在减少爬虫节点的职责。
节点职责越少，单次任务越短，失败成本也越低。即使某个任务失败，也可以快速上报并进入调度中心的异常处理流程，而不是让爬虫自己在本地反复纠缠。
为什么用 Docker 部署爬虫
Section titled “为什么用 Docker 部署爬虫”爬虫选择 Docker 部署，是因为这个系统天然需要横向扩容。
如果爬虫直接跑在固定机器上，扩容会比较麻烦。新机器环境要配置，依赖要安装，版本要对齐，启动方式也容易不一致。Docker 把运行环境打包后，爬虫就可以在任意一台机器上快速启动。
这带来了两个非常直接的好处。
第一，可以一键扩容。
当采集任务变多，或者需要在短时间内提高吞吐时，只需要增加爬虫容器数量。因为爬虫是无状态的，新启动的容器不需要同步复杂上下文，只要能连上调度中心，就可以开始领取任务。
第二，可以按数据采集情况动态调整数量。
任务高峰期增加爬虫节点，任务低谷期减少节点。爬虫节点本身不保存长期状态，所以扩容和缩容都比较自然。
这也是无状态设计和容器化部署非常契合的地方：一个节点随时可以来，也随时可以走，系统的长期状态不依赖它。
为什么架构图里没有代理模块
Section titled “为什么架构图里没有代理模块”从图上看，可能会有一个疑问：代理池去哪了？
实际设计里，代理也由调度中心负责。
爬虫在领取任务时，调度中心会把任务、账号、代理一起下发。对于爬虫来说，它不需要自己去代理池里挑选代理，也不需要判断某个代理是否还应该继续使用。它只需要使用调度中心给出的代理完成当前任务，并把结果反馈回去。
这样设计的好处是统一。
任务、账号、代理在一次采集里是绑定关系。如果采集失败，调度中心可以结合错误类型判断问题出在哪里：可能是任务本身异常，可能是账号失效，也可能是代理不可用。爬虫端只提供事实，不做最终裁判。
这让异常处理有了更清晰的入口。
账号池和异常流转
Section titled “账号池和异常流转”账号管理是这个系统里非常重要的一部分。
有效账号池保存当前可用账号。调度中心给爬虫下发任务时，会从有效账号池里分配账号。任务完成后，如果账号表现正常，就重新回到有效账号池，等待后续继续使用。
如果采集过程中发现账号异常，爬虫不会自己尝试修复账号，而是把异常上报给调度中心。调度中心再把账号放入异常账号池，由账号登录模块或专门处理模块去恢复。
恢复成功后，账号重新进入有效账号池；恢复失败，则继续留在异常状态，等待后续处理或下线。
这套流转看起来绕了一步，但它让职责非常清楚：
- 爬虫负责发现和上报异常。
- 调度中心负责状态流转和资源分配。
- 账号登录模块负责账号恢复。
- 有效账号池只保留可用于任务分配的账号。
当系统规模变大时，这种职责拆分会比“爬虫自己判断一切”更稳。
数据链路：Kafka、Flink 和 ES
Section titled “数据链路：Kafka、Flink 和 ES”爬虫采集到的数据不会直接写入最终存储，而是先进入 Kafka。
Kafka 在这里承担缓冲和解耦作用。爬虫只需要稳定地把采集结果投递出去，不需要关心后续清洗、转换和索引写入的具体细节。
Flink 负责消费 Kafka 中的数据，做实时清洗、转换、去重或补充处理。处理后的数据再写入 ES，供后续检索和查询使用。
这条链路的好处是采集和处理分离。
爬虫节点只追求采集效率，数据处理链路则可以按自己的节奏扩展。如果后续清洗逻辑变复杂，也不会直接拖慢爬虫侧的执行。
这套设计对我最大的影响，是让我第一次真正理解“少做一点”有时候是更好的工程设计。
刚开始做爬虫时，很容易觉得爬虫应该什么都管：任务、状态、账号、代理、重试、异常、存储，最好都封装在一个完整框架里。但在大规模系统里，爬虫越重，越容易变成难以扩展的节点。
这套系统反而让我看到另一种思路：
爬虫不需要成为系统中心。它可以只是一个高性能、可替换、可扩容的执行单元。真正的状态和调度逻辑，应该放到更适合统一管理的位置。
对当时初入职场的我来说，这个认知很重要。
我开始意识到，架构设计不是把所有能力都堆进一个模块里，而是决定每个模块应该知道什么、不应该知道什么。一个模块越清楚自己不负责什么，边界往往越稳定。
回头看，这套无状态爬虫体系最让我印象深刻的地方，就是它把复杂性从爬虫端拿走了。
爬虫只领取任务、执行采集、上报结果；调度中心统一管理任务、账号、代理和异常；数据进入 Kafka、Flink、ES 组成的后续链路。每一层都有自己的职责，每一层也都可以独立扩展。
这比单纯写一个“能跑的爬虫”要更接近真正的工程系统。