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对象，那就不用实现这两个方法了。

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