Scrapy架构概览

下面的图总结了Scrapy的架构：



你或许已经注意到这个架构主要操作的三种数据类型——

Request

、

Response

和

Item

，而爬虫处于架构的核心位置，它们产生

Request

，处理

Response

并且产生

Item

和更多的

Request

。

每个由爬虫产生的

Item

都会被一个序列的

Item Pipeline

用它们的

process_item()

进行后处理。通常情况下，

process_item()

方法修改

Item

并通过返回这些

Item

来把它们传递给后续的

Item Pipeline

。有时候，比如出现了重复或者无效的数据，我们也会丢弃这个

Item

，可以通过抛出一个

DropItem

异常来达到这个目的。在这种情况下，后续的

Item Pipeline

不会再收到这些

Item

。如果我们提供了

open_spider()

或者

close_spider()

方法，它们会分别在爬虫开启和关闭时调用。而此时正是一个对其进行初始化或清理残余的机会。通常情况下，

Item Pipeline

是用来执行一些有问题的或者基础设施的操作，例如，清理数据或者把

Item

插入到数据库中。你会发现你可能会在多个工程中都会使用这些

Item Pipeline

，尤其是在它们跟你的基础设施（如数据库）相关的时候。

我们通常通过爬虫发送

Request

，然后得到

Response

，就这样工作着。Scrapy透明地处理了cookies、认证、缓存等等问题，我们所需要做的仅仅是时不时地调整一些设置即可。大多数上面说的那些功能是以下载器中间件的形式来实现的，通常比较复杂而且很有技术地处理了

Request/Response

的内部。你了可以实现自己的下载器中间件来使得Scrapy按照你想要的方式来进行

Request

的处理。

下载器是实际执行下载操作的引擎。如果你不是Scrapy代码的贡献者，那就不会修改到这个部分。

有时候你可能需要去写爬虫中间件。它们在爬虫之后、下载器之前处理

Request

，并且以相反的顺序来处理

Response

。通过使用下载器中间件，你可以重写URL，以便使用HTTPS而不是HTTP，不管这个爬虫要抓取的是什么。它实现的功能是针对工程的特定需要，可以在所有的爬虫中间通用。下载器中间件和爬虫中间件之间主要的区别是当下载器中间件得到一个

Request

时，它会返回一个

Response

。在另一方面，如果有需要，爬虫中间件可以丢弃

Request

。爬虫中间件之于

Request

和

Response

就像

Item Pipeline

之于

Item

。爬虫中间件也接收

Item

但是通常情况下不会修改它们，因为这在

Item Pipeline

中更容易做到。

最后来说一下扩展。扩展的应用很广泛，实际上是在

Item Pipeline

之后应用最广泛的组件。它们就是普通的类，在爬虫启动时被加载，并且可以访问设置，crawler、给信号注册回调函数或者定义它们自己的信号。信号是一种Scrapy API，在系统发生某件事时，它的回调函数就会被调用，例如，抓取或者丢弃了一个

Item

，或爬虫开启。有很多预定义的信号，在以后的介绍中会慢慢涉及到。扩展在某种意义上说是万能的，因为它允许你写出你可以想你到的任何功能，而不会给你任何的帮助（像是

Item Pipeline

的

process_item()

方法）。我们必须关联到信号上，并实现自己的功能。例如，在抓取特定数目的

Item

或者页面之后停止爬虫这个功能就是用扩展实现的。



稍微严格点说，Scrapy把这些类都看做是中间件（通过

MiddlewareManager

类的子类来管理），并且允许我们通过实现

from_crawler()

或者

from_settings()

方法，来分别从一个

Crawler

或者

Settings

对象来初始化它们。由于可以从

Crawler

对象中获取

Settings

对象（

crawler.settiings

)，所以

from_crawler()

方法用的更加多一点。如果不需要

Cralwer

和

Settings

对象，那就不用实现这两个方法了。

这时是一张表，可以帮助你决定解决一个问题的最佳方案：