近几年，Python名声大噪，爬虫框架Scrapy更是为大众所乐道。现在就让我们拿相对成熟的Java分布式爬虫框架和Scrapy作对比，看看Scrapy距离实际使用，还有哪些需要补充的地方。
Java分布式爬虫框架
逻辑架构
模块说明
模块 | 职能 |
信源管理层 | 管理网站的采集配置。采集配置，包括抓取链接的组成方式、结构化数据的抽取规则、衍生任务的生成逻辑等。若网站的采集配置发生变更，通知采集层；并提供相应的接口，返回变更的信息 |
采集管理层 | 管理网站的采集作业。将待采集的一次性作业或周期性作业推送到采集层；实时展示作业的执行进度，并将执行完的作业的数据由采集层同步，供用户下载 |
资源管理层 | 管理采集时所需的资源。资源，包括爬虫、网站Cookie等。若资源发生变更，通知采集层；并提供相应的接口，返回变更的信息 |
采集层作业类API | 用于管理作业的一整套流程。从获取采集场景状态开始，到推送作业，到监控作业进度，再到获取作业结果。若作业执行中，出现异常，可直接取消作业。作业完成后，可查看作业的采集概况；也可通过采集的具体数据，查看采集详情 |
采集层Captain | 规则或场景发生变更时，由Captain将变更的规则或场景新增/更新至采集层数据库，并加载至Captain内存且发布变更通知。资源发生变更时，由Captain将变更的资源同步至采集层数据库，并加载至Captain内存。Captain，除协调任务、爬虫资源和采集资源的配额外，还需监控作业的采集情况，支持断点续作 |
采集层Soldier | 接收Captain传入的规则或场景变更的通知，将变更的内容由采集层数据库同步至内存。接收Captain传入的任务，对任务进行抓取、抽取、衍生、存储、后处理等一系列操作，并将结果保存至指定位置 |
交互上，采用基于Redis的订阅发布来通知变更、采用Java Web来返回变更情况、采用基于Netty的网络通讯来双向连接Captain和Soldier。
存储上，MySQL存储采集配置，Redis存储原生任务和衍生任务，ES存储采集的数据。
Python爬虫框架Scrapy
逻辑架构
模块说明
模块 | 职能 |
Scrapy Engine（引擎） | 负责Spider、ItemPipeline、Downloader、Scheduler中间的通讯，信号、数据传递等 |
Scheduler（调度器） | 它负责接受引擎发送过来的Request请求，并按照一定的方式进行整理排列，入队，当引擎需要时，交还给引擎 |
Downloader（下载器） | 负责下载Scrapy Engine（引擎）发送的所有Requests请求，并将其获取到的Responses交还给Scrapy Engine（引擎），由引擎交给Spider来处理 |
Spider（爬虫） | 它负责处理所有Responses，从中分析提取数据，获取Item字段需要的数据，并将需要跟进的URL提交给引擎，再次进入Scheduler（调度器） |
Item Pipeline（管道） | 它负责处理Spider中获取到的Item，并进行进行后期处理（详细分析、过滤、存储等）的地方 |
Downloader Middlewares（下载中间件） | 可以当作是一个可以自定义扩展下载功能的组件 |
Spider Middlewares（Spider中间件） | 可以理解为是一个可以自定扩展和操作引擎和Spider中间通信的功能组件（比如进入Spider的Responses和从Spider出去的Requests） |
Java分布式爬虫框架 VS Python爬虫框架Scrapy
背景知识
Netty和Scrapy的核心理念是共通的。Netty是一个高性能、异步事件驱动的NIO框架；Scrapy是一套基于Twisted的异步处理框架，而Twisted是一个事件驱动型的网络引擎。
结论
列举的Java分布式爬虫框架和Scrapy虽然核心理念共通，但采集中抽象的层面不同。Java分布式爬虫框架以采集任务为原子单位；而Scrapy是对采集任务的执行流程（抓、抽、存、衍等）为原子单位，在Java分布式爬虫框架中充当着采集层Soldier的角色。
所以，要想将Scrapy投入实际使用，还需补全Java分布式爬虫框架中除了采集层Soldier外的其它模块。
