关于Scrapy中Middleware和Pipeline的一些感悟--国庆期间研究小结

首先不管你使用requests还是urllib抑或是爬虫框架(此文指Scrapy)本质上都是获取数据.

查了不少文档, 10年来各种写法都有. 不得不感慨下搜索引擎保留的资料时间之长久.而要获取最新的文档, 默认还是谷歌最好.

那么为什么使用Scrapy, 答: 为了效率.

可能运行效率比不上跑分级原生手写request代码, 但是作为爬虫工程来说, 绝对框架爬虫是首选. 这里面包含日后的维护, 改动, 全局修改, 入库, scheduler, 维护, 记录, 健康管理 等各种问题, 框架都是首选.

-----------

行业观察:

那么在学习框架的过程中, 查询正宗的Scrapy架构写法的时候, 往往被网上的五花八门的"半架构"的写法耽误了不少时间.这里比如:

明明官方有中间件来统一管理所有的request, 有些人非要在main里实现request. 这不就成了"半自动"步枪了么. 明明可以全自动的. 

曾经看到一种写法:

为了躲避 scrapy.middlewares.redirect.RedirectMiddleware , 直接在setting里面禁用之, 然后自己写cookie封装.

我曾经一度对这种操作表示困惑, 期间为了搞清楚原因还在github上潜伏了好几天,看了很多工程代码, 很多类似的写法, 搞得我一阵晕.

直接重写中间件啊大哥们.在 process_request() 里面直接做统一的重写啊 一改全改了.

甚至还看到一个哥们在pipeline里面为了应对yeild Request的重定向, 又单独用request先通过HEAD方式请求一次,拿到reponse.text里面的Location 重定向url, 然后再yield Request给spider引擎, 尼玛, 他不仅重写了一次request, 又单独传递了一次cookie...还放github了..尼玛这什么操作...一个中间件拦截request增加cookies就搞定了呀

结论就是多花的3天时间看这些垃圾代码真的是浪费了生命了. 

------------------- 

我说几点规范:

1. 数据清洗一般在pipelines里面做, 代码量大的话放到 items 里面具体的item里面吧, 我一般封装成一个save()供pipeline调用, 这样代码很干净. 我最近就实现了, 文件名的清洗, 然后下载的资源比如图片的裁切,水印涂抹,网状水印对AI面部的规避, 存储到mysql, mongdb, redis, elasticsearch, excel这些都是在pipeline里面进行细分.

2. 控制spider的request, 比如proxypool啊, 可变agent啊这些, cookies分类啊, 一定要使用middleware中间件来做, 不然那代码太乱了, 后期维护的工作量非常大, 远远高于运行效率.