Scrapy 爬虫部署指南：Scrapyd、scrapyd-deploy 与 Zyte Scrapy Cloud 实战详解

本文基于 Scrapy 官方文档的"Deploying Spiders"主题，系统讲解将 Scrapy 爬虫从本地开发环境迁移到生产环境的两条主流路径：自托管的开源方案 Scrapyd，以及基于云端的 Zyte Scrapy Cloud。读完后你将理解 scrapy.cfg 中 [deploy] 配置段的设计原理、scrapyd-deploy 工具与 shub 命令的工作方式、Scrapyd HTTP API（如 schedule.json）的触发方式，以及如何在两种部署方案之间平滑切换——所有内容均以当前仓库源码与文档为证据支撑。

为什么需要部署：本地开发与生产运行的差距

Scrapy 官方文档（见 docs/topics/deploy.rst）开宗明义地指出：在（早期）开发阶段，在本地机器上运行 Scrapy 爬虫非常方便，但当你需要执行长时间运行的爬虫，或把爬虫迁移到生产环境持续运行时，本地运行的方式就显得力不从心了。这正是各种部署方案要解决的问题。

文档给出的当前主流选择有两个：

• Scrapyd（开源）：自建服务器部署；
• Zyte Scrapy Cloud（云服务）：托管部署。

值得强调的是，从源码结构看，Scrapy 主仓库本身并不内置爬虫调度服务器。早期的 Scrapyd 代码曾在 Scrapy 仓库中维护，但根据 docs/news.rst 中的历史变更记录（"Scrapyd changes: Scrapyd now uses one process per spider"、"New Scrapy service called scrapyd for deploying Scrapy crawlers in production" 等条目），Scrapyd 后来被拆分为独立项目单独维护。当前仓库中 docs/topics/scrapyd.rst 也明确说明："Scrapyd has been moved into a separate project"（Scrapyd 已迁移至独立项目）。这意味着本文讨论的部署能力来自 Scrapy 生态的配套工具链，而非 scrapy 包内可直接 import 的模块。

方案一：部署到 Scrapyd 服务器

Scrapyd 是什么

官方文档定义：Scrapyd 是一个用于运行 Scrapy 爬虫的开源应用，它提供一个带有 HTTP API 的服务器，能够运行并监控 Scrapy 爬虫。文档同时指出，Scrapyd 由部分 Scrapy 开发者共同维护（"Scrapyd is maintained by some of the Scrapy developers"），因此与 Scrapy 主项目保持较高的兼容性。

部署工具：scrapyd-deploy

向 Scrapyd 部署爬虫，使用的是 scrapyd-client 包提供的 scrapyd-deploy 命令行工具。官方文档建议读者参阅 scrapyd-deploy 的专门文档获取完整用法。这里补充一个容易被忽视的历史事实：Scrapy 1.0 之前存在内置的 scrapy deploy 命令，该命令已在 1.0 版本中移除，由独立的 scrapyd-deploy 工具取代——这一点在 docs/topics/commands.rst 中有明确说明（"The scrapy deploy command has been removed in 1.0 in favor of the standalone scrapyd-deploy"）。因此，如果你在旧资料中看到 scrapy deploy 的用法，在当前版本中已经不可用。

核心配置：scrapy.cfg 中的 [deploy] 段

scrapyd-deploy 读取的核心配置是项目根目录下的 scrapy.cfg 文件中的 [deploy] 段。Scrapy 项目模板中自带的 scrapy.cfg 内容如下（见 scrapy/templates/project/scrapy.cfg）：

# Automatically created by: scrapy startproject
#
# For more information about the [deploy] section see:
# https://scrapyd.readthedocs.io/en/latest/deploy.html

[settings]
default = ${project_name}.settings

[deploy]
#url = http://localhost:6800/
project = ${project_name}

各字段含义：

配置项	所属段	说明
default	[settings]	默认使用的 settings 模块，scrapy startproject 时由模板替换为实际项目名
url	[deploy]	目标 Scrapyd 服务器的 HTTP 地址，模板中默认被注释掉（#url = http://localhost:6800/），部署前需取消注释并填入真实地址；6800 是 Scrapyd 的默认端口
project	[deploy]	部署到 Scrapyd 的项目名，模板中默认为 ${project_name}

这个模板正是 scrapy startproject 命令的产物。从源码 scrapy/commands/startproject.py 可以看到，TEMPLATES_TO_RENDER 元组将 scrapy.cfg 列为第一个需要渲染的模板文件，其中 ${project_name} 占位符会在项目创建时被实际项目名替换。

scrapy.cfg 的查找与合并规则

scrapyd-deploy 与 Scrapy 命令行工具对 scrapy.cfg 的查找逻辑是一致的：Scrapy 会按以下标准位置查找 ini 风格的 scrapy.cfg 文件（详见 docs/topics/commands.rst 的 "Configuration settings" 小节）：

1. /etc/scrapy.cfg 或 c:\scrapy\scrapy.cfg（系统级）；
2. ~/.config/scrapy.cfg（$XDG_CONFIG_HOME）与 ~/.scrapy.cfg（$HOME）（用户全局）；
3. Scrapy 项目根目录内的 scrapy.cfg。

这些文件中的设置按上述顺序合并：项目级配置优先级最高，可覆盖用户级与系统级配置。

底层实现位于 scrapy/utils/conf.py：closest_scrapy_cfg() 从当前目录逐级向上遍历父目录查找最近的 scrapy.cfg；get_sources() 按"系统 → 用户 → 最近项目"的顺序组装配置来源列表，再由 get_config() 交给 ConfigParser 读取合并。另外 init_env()（scrapy/utils/conf.py）还会根据 scrapy.cfg 的 [settings] 段设置 SCRAPY_SETTINGS_MODULE 环境变量，并把项目目录加入 sys.path——这就是为什么 scrapyd-deploy 与 scrapy 命令都必须"站在"项目目录内（或其子目录内）才能正确定位项目配置。

通过 Scrapyd HTTP API 触发爬虫运行

部署只是第一步。Scrapyd 的 HTTP API 允许你在部署之后远程触发爬虫运行。一个典型的触发方式是 schedule.json 接口，docs/topics/practices.rst 中"分布式爬取"（Distributed crawls）小节给出了真实示例：把一个大型爬虫的 URL 列表切分为多个分区，再向三台不同的 Scrapyd 服务器分别发起调度请求，每个请求通过爬虫参数 part 指定要处理的分区：

curl http://scrapy1.mycompany.com:6800/schedule.json -d project=myproject -d spider=spider1 -d part=1
curl http://scrapy2.mycompany.com:6800/schedule.json -d project=myproject -d spider=spider1 -d part=2
curl http://scrapy3.mycompany.com:6800/schedule.json -d project=myproject -d spider=spider1 -d part=3

这里体现了 Scrapyd API 的两个关键能力：

• 按 project + spider 定位爬虫运行：-d project=myproject -d spider=spider1；
• 传递爬虫参数：-d part=1 这类额外参数会作为 spider arguments 传入。docs/topics/spiders.rst 也印证了这一点："Spider arguments can also be passed through the Scrapyd schedule.json API." 爬虫内可通过 self.crawler.job 或 spider arguments 读取这些参数。

docs/topics/practices.rst 还给出了整体思路：当你有许多爬虫时，自然的多服务器分发方式就是搭建多台 Scrapyd 实例，在各实例间分配爬虫运行任务；Scrapy 本身不提供内置的多服务器分布式机制，多机扩展正是通过 Scrapyd 层实现的。

方案二：部署到 Zyte Scrapy Cloud

Zyte Scrapy Cloud 是由 Zyte（Scrapy 背后的公司）提供的托管云服务。官方文档说明它的两个核心优势：

• 免去了自建和监控服务器的运维负担；
• 提供图形界面（UI），用于管理爬虫、查看抓取结果（items）、日志（logs）与统计信息（stats）。

向 Zyte Scrapy Cloud 部署爬虫，使用的是 shub 命令行工具，更多用法以 Zyte Scrapy Cloud 官方文档为准。

与 Scrapyd 的兼容性与平滑切换

官方文档中一个实用性很强的结论是：Zyte Scrapy Cloud 与 Scrapyd 兼容，两者可以按需切换，配置读取方式与 scrapyd-deploy 相同——都是从 scrapy.cfg 文件读取。

这一兼容性的技术基础可以推断为：Zyte Scrapy Cloud 作为云托管服务，复用了 Scrapyd 的 API 形态与部署协议，因此同一份 scrapy.cfg（含 [deploy] 段的 url 与 project 配置）在两种环境间切换时只需更换目标地址，无需改动爬虫代码与项目结构。这意味着"本地开发 → 自建 Scrapyd 试运行 → 迁移到云服务"的路径是平滑的。

两种方案对比与选型建议

维度	Scrapyd（自托管）	Zyte Scrapy Cloud（云服务）
性质	开源，自维护服务器	Zyte 提供的托管服务
部署工具	scrapyd-deploy（scrapyd-client 包）	shub 命令行工具
监控方式	HTTP API	图形界面管理爬虫、查看 items/logs/stats
运维成本	需自行搭建与维护服务器	无需搭建和监控服务器
配置载体	scrapy.cfg 的 [deploy] 段	同样读取 scrapy.cfg，与 Scrapyd 兼容可互切
多机扩展	可搭建多台实例分发爬虫运行（见 Distributed crawls 实践）	由云端调度

选型上，如果需要对爬取基础设施有完全控制、且具备运维能力，Scrapyd 是自然的开源选择，并可配合多台实例做爬虫运行分发；如果希望免去服务器运维、通过 UI 审阅抓取结果与日志，Zyte Scrapy Cloud 更合适，且从 Scrapyd 迁移过去无需改变项目配置结构。

另外，docs/faq.rst 中"生产环境推荐的爬虫部署方式是什么？"（What is the recommended way to deploy a Scrapy crawler in production?）一题也直接指向本主题，进一步说明部署是官方视角下从开发走向生产必须跨越的一环。

小结

Scrapy 自身的定位是"爬虫框架"，而"在哪里跑、怎么调度、如何监控"的部署能力由生态配套承担：

1. 生产部署的两大选项是开源的 Scrapyd 与云托管的 Zyte Scrapy Cloud；
2. 两者共用同一份 scrapy.cfg 配置约定（[deploy] 段的 url 与 project），实现方案间可切换；
3. 自托管路径使用 scrapyd-client 提供的 scrapyd-deploy 部署，内置 scrapy deploy 命令自 1.0 起已移除；
4. 部署后可通过 Scrapyd 的 schedule.json 等 HTTP API 触发爬虫运行并传递爬虫参数，天然支持多实例分发；
5. 当前仓库中的 scrapy.cfg 模板（scrapy/templates/project/scrapy.cfg）与配置加载实现（scrapy/utils/conf.py）是理解这一部署机制的最直接源码入口。