做了几年爬虫了，一直没有好好总结爬虫架构类的知识，最近不那么忙，就抽空写下经验心得。
目前最流行通用的爬虫框架就是scrapy-redis了，或其衍生出来的一系列比较通用的爬虫框架，爬虫框架基本都用了scrapy的调度器-引擎-爬虫模块-下载器-中间件-数据处这种思路。目前我所搭建的框架也大致沿用这种思路，只不过针对公司的业务需求又有所不同，比较其区别主要有一下几点：
- 就整体架构比较而言，目前架构解耦性更高，调度器，爬虫服务，任务推送，数据处理入库，这几个功能作为了独立的项目拆散开来，个人认为更利于监控，调试和做分布式。而类scrapy的框架把这些都集成到了一起，适合更轻量的爬虫需求，分布式得依赖redis或是其他消息中间件。
- 从任务推送的方式比较而言，其实两者都是在redis中读取任务来做，区别在任务是如何进到redis中的。目前框架是通过定期读mysql库来推送任务，通过每条数据的唯一性来间接得达到了任务去重的效果，且每次推送任务后任务量是确定了的，再就是meta数据在此时同时提供。而类scrapy框架则是需要调度器对url进行一系列的hash计算并去重，且在爬取过程有可能会生成新的任务需要进入去重队列，也就是任务数不在开始就确定，再就是meta数据会在爬取过程中被传送。
- 从爬虫服务而言，目前架构的爬虫服务采用tornado做web服务对调度器提供接口，也方便个人直接对某个单独任务直接调试。每个平台爬虫都是单独一个文件模块做破解反爬还有数据解析。类scrapy架构是没有提供web服务的，每个平台爬虫会作为一个爬虫类（这点倒是区别不大）。
- 就爬虫调度而言，目前架构是通过配置每一个平台爬虫的启动参数开一个进程调用tornado提供的接口，获得的数据进行公共处理再入队列，任务的消耗速度，ETA时间，错误率等等都在这里进行统计。类scrapy框架则是用引擎来负责调度任务，从调度器那里活得任务，再交给下载器，拿到返回的数据后再把结果交给爬虫类解析，其突破反爬的手段是及其有限或者说是不方便的，因为它只能在爬虫中间件那里干预UA还有代理等，也可以多写其他中间件，但总归是不太适用于爬取高难度反爬的网站。
- 就入库程序而言，目前框架使用rabbitmq作为消息中间件，调度程序拿到结果会存放进相应队列，入库程序阻塞式的读取里面的数据入库，消耗后会确认，这样能更大保证每条数据的入库精确性和可靠性。类scapy框架则是使用pipeline，程序挂掉会丢失数据。
- 就分布式搭建和并发请求方式来说，两者都会使用redis或是rabbitmq等做消息中间件，实现断点续爬，分布式爬取等功能。目前框架使用请求库是aiohttp，而类scrapy框架则使用twisted网络请求的部分，实现并发的方式主要还是用线程，也可扩展为协程。
- 就监控而言，个人认为目前的框架监控起来方便得多，结合了elk+filebeat，当初设计的时候就想着每个平台的更新作为了一个单独的爬虫个体，通过其报出来的日志来监控爬虫的状态。而类scrapy框架监控就不那么方便。不过爬虫监控可以说的东西太多了，以后再单独写篇文章总结一下。
最主要的区别就这些了，其他的边边角角都可配置，没有说的必要。
