Open ydf0509 opened 3 hours ago
典型的scrapy方式写法,极其难用和不灵活。
funboost框架如果用于爬虫和国内那些90%仿scrapy api的爬虫框架,在思想上完全不同,会使人眼界大开,思想之奔放与被scrapy api束缚死死的那种框架比起来有云泥之别
funboost(或boost_spider)框架是自动调度一个函数,而不是自动调度一个url请求,一般框架是yield Requet(),所以不兼容用户自己手写requests urllib的请求, 如果用户对请求有特殊的定制,要么就需要手写中间件添加到框架的钩子,复杂的需要高度自定义的特殊请求在这些框架中甚至无法实现,极端不自由。
此框架由于是调度一个函数,在函数里面写 请求 解析 入库,用户想怎么写就怎么写,极端自由,使用户编码思想放荡不羁但整体上有统一的调度。 还能直接复用用户的老函数,例如之前是裸写requests爬虫,没有规划成使用框架爬虫,那么只要在函数上面加一个@boost的装饰器就可以自动调度了。
而90%一般普通爬虫框架与用户手写requests 请求解析存储,在流程逻辑上是严重互斥的,要改造成使用这种框架改造会很大。 此框架如果用于爬虫和国内那些90%仿scrapy api的爬虫框架,在思想上完全不同,会使人眼界大开,思想之奔放与被scrapy api束缚死死的那种框架比起来有云泥之别。 因为国内的框架都是仿scrapy api,必须要继承框架的Spider基类,然后重写 def parse,然后在parse里面yield Request(url,callback=annother_parse), 请求逻辑实现被 Request 类束缚得死死的,没有方便自定义的空间,一般都是要写middware拦截http请求的各个流程,写一些逻辑,那种代码极端不自由,而且怎么写middware, 也是被框架束缚的死死的,很难学,例如scrapy 集成selenium浏览器没几个人搞定,就算实现了也是同步阻塞导致scrapy的并发成为了废物,当你把scrapy的并发调度弄成了废物了还有必要用什么scrapy。 例如崔庆才 写的scrapy集成selenium浏览器,文章在 https://cuiqingcai.com/8397.html ,如果网站网页需要渲染30秒,那么此时scrapy爬虫慢的吐血,因为这种扩展scrapy的方式是错误的。 还有人在scrapy的Spider类的解析方法里面用浏览器重复请求一次url,scrapy的parse不是并发的,只有yield Request类请求是自动并发,下面parse中写浏览器请求,scrapy就变成了个废物。 def parsexx(self,response): driver.get(response.url)
分布式函数调度框架由于是自动调度函数而不是自动调度url请求,所以天生不存在这些问题。
用其他爬虫框架需要继承BaseSpider类,重写一大堆方法写一大堆中间件方法和配置文件,在很多个文件夹中来回切换写代码。 而用这个爬虫,只需要学习 @boost 一个装饰器就行,代码行数大幅度减少,随意重启代码任务万无一失,大幅度减少操心。
看了baiduspider的文件夹,目录结构和scrapy太像了, 写法也需要 class Myspider 继承,写def parse,和scrapy写法太像了,那就代表是和scrapy一样极其复杂难用。设计框架时候,思维不是很开阔,被scrapy框架思维束缚的死死的。
横冲直闯大开大合思维的框架绝对比scrapy api 写法框架简单很多。