高级架构师实战：如何用最小的代价完成爬虫需求

一  缘起

在我工做的多家公司，有众多的领域，如房产，电商，广告等领域。尽管业务相差很大，但都涉及到爬虫领域。开发爬虫项目多了后，天然而然的会面对一个问题——

• 这些开发的爬虫项目有通用性吗？

• 有没有可能花费较小的代价完成一个新的爬虫需求？

• 在维护运营过程当中，是否可以工具化，构建基于配置化的分布式爬虫应用？

这就是是咱们今天要讨论的话题。

二  项目需求

立项之初，咱们从使用的脚度试着提几个需求。

1. 分布式抓取
因为抓取量可能很是庞大，一台机器不足以处理百万以上的抓取任务，所以分布式爬虫应用是首当其冲要面对并解决的问题。
     
2. 模块化，轻量
咱们将爬虫应用分红“应用层，服务层，业务处理层，调度层” 四个脚色。

3. 可管理，可监控
管理监控是一个体系，即配置可管理化，运行实时监控化。在系统正常运行时，能够变动爬虫的配置，一旦实时监控爬虫出现异常，可实时修正配置进行干预。全部的一切，都可以经过UI界面进行操做。

4. 通用性，可扩展。
爬虫业务每每多变，不一样领域的爬取需求不尽相同。举例说，房源抓取包含图片抓取，小区信息抓取，房源去重等模块。新闻抓取包括内容抓取，正文提取，信息摘要等相关。
所以，系统须要可以支持业务扩展需求，能够支持不一样的业务使用同一套框架进行应用开发。 

三  模块分解

针对业务需求，咱们将系统分解成多个应用模块。

应用层

    
应用层是针对管理员，系统维护人员使用。主要分红两个模块，系统配置模块和运营管理模块。

• 系统配置模块：系统配置模块包含抓取网站管理配置，在线测试等功能。

• 运营管理模块：运营管理模块包含实时抓取量统计，分析，正确率等。甚至包括失败缘由，失败量。
   

系统运营人员能够根据运营模块获得实时的反馈，使用系统配置模块进行配置修正，在线测试正确后将配置生效，再实时监控新的配置产生的效果。
    

服务层

服务层是整个系统传输的中枢，至关于整个分布式集中的系统总线和数据总线。服务层提供一个http/thrift接口，读取数据库，输出配置信息。

1. 提供网站爬虫配置接口。从数据库中实时读取配置信息，响应业务层的配置请求。

2. 提供业务层输出写入接口。接受业务层实时爬取的信息汇总，包括正确数据量，错误数据量，以及错误缘由。

3. 提供实时报表统计分析。响应应用层的运营管理模块，查询数据库，实时提供数据分析报告。

业务处理层

     
业务处理层是整个爬虫系统的核心，可分红多台应用服务器进行处理。业务处理层主要包含解决两件事情。

• 如何获取url

• 获得url后，如何处理

（一）  如何获取url

对于爬虫来讲，如何获取url相当重要。咱们将这一过程定义为发现系统。对于发现系统而言，目标为如何发现待抓取网站的详细url列表，尽量的发现更全。

假设场景 A
咱们逛一个电商网站：打开首页-打开分类页-可能会有多层分类页-逐层点击-直至最小的分类页面。
打开这个分类页会发现该分类页下的全部分页页面，一页一页往下翻，就可以得到该分类页的全部商品。

假设场景 B
咱们逛一个汽车网站：打开首页-找到品牌页-接着找到车系-最后找到车款页面。

经过以上场景分析能够获得一个结论，人能很是智能的找到全部待抓取的详细页面，即电商的商品，汽车的车款页面。那么，是否能够经过配置方式来模拟这一过程呢？

请看下图：

备注以下：

1. root_info：
定义发现模块的入口页面，如同人打开汽车站的网页，后续的发现都是起始于这些入口页。
这里给出的实例是，某汽车网的品牌列表页，根据“模板化”套用变量的配置，共有100个入口页。

2. steps: 
依次遍历这100个入口页，分别会执行steps中定义的步骤。机器模拟人的方式进行查看浏览。
每一个step中，会使用"link_module"定义的类进行逻辑进行处理。

1. 读取入口页的html，结合"sub_prefix","sub_suffix"和"select"定义的内容，得到页面子区域html。

2. 使用"link_match_method"的方法（含前缀包含，匹配等）,抽取子区域的连接。

3. 每一个连接 和"link_pattern"进行匹配，匹配成功的url进入下一步。

4. 每一步获得的url，自动进和地下一步处理，处理逻辑为递归上面a-c，直至"last_step"为true为止。

此处，即"last_step"为true中发现的url，即为发现系统最终须要获取的url列表。发现系统总结，经过配置的方式，结合人类的浏览习惯，经过若干步迭代，最终获取网站的详细页url列表。

因为每一步的抽取连接规则，以及步数据都是人为定义，所以，能够适配绝大部分网站的发现系统。固然，越复杂的网站发现配置可能更多一些、更为繁杂，但万变不离其宗。

（二）获得url后，如何处理

前提固然是每一个业务的处理各不相同，有抽取页面属性功能、有正文提取、有图片获取，甚至有和当前系统对接等。

因为业务处理不一致，很天然想到的是经过配置方式，定义职责链系统，如同著名框架Netty中的Pipeline设计。在处理过程当中，定义一个Context上下文处理类，而且，全部的中间结果都暂缓在这个Context中。

描述比较空洞，仍是结合实际案例来看。

备注以下：

获得一个url后，读取配置，当url和"site"匹配时，适用当前"site"规则。

1 pipeline定义职责链的处理过程
此处的定义为“抓取模块，Javascript处理模块，通用解析模块”。对应的处理以下：
先执行抓取模块，获得html。紧接着执行Javascript处理模块，输入为html，解析html，此处多是评论，也多是价格，总之处理的是动态加载项目，紧接着处理“通用解析模块”

2  "parser_rules"定义的是解析模块
最终输出的是kv，在java中是map，python中是dict。即从上一步的html中，找到每一荐的"sizzle"，执行"prefix","suffix"即先后缀移除(过滤如同“价格：xxx元，前缀为“价格:"，后缀为元)。
对了，sizzle也是一个开源技术，听说之前鼎鼎有名的Jquery也是"sizzle"引擎。Java中可使用Jsoup解析处理。
怎么知道须要取的"sizzle"内容是什么呢？具体能够结合firebug插件，选中便可得。选中后，结合应用层的管理工具，便可进行测试。

3  “isrequire"
能够看到，配置项中有“isrequire"，表示这项内容是否必须。若是必须，且在实际处理中获取不到，那么在抓取的过程当中，就会记录一个错误， 错误缘由天然是“$key is null"。此外，每个module均可能出错，一旦出错，就没有必要日后去执行。
所以，在抓取过程当中，业务处理层从服务层得到一批url(默认100个）后，在处理这一百个url结束后，会向服层report，report内容为：
当前任务处理机器，于什么时间处理100个页面。不一样网站成功多少、失败多少、什么模块失败多少，解析模块什么字段失败多少。
全部这些信息，均是实时统计，并在运营监控系统中以图表形示绘制出来，必要时能够发出报警，交由维护人员实时干预。

Q: 提一个问题，新增一个anotherauto.com网站怎么办？

A: 其实也很简单，再增长一个配置呗。业务定义pipeline，若是有解析需求，填写对应的解析项便可。

以上两个系统，发现系统和处理系统，在咱们实际生产中，是经过如下步骤贯穿。

1. 发现系统累计发现待抓取网站的详细页，由于是一个累计持续的过程。所以有把握持续无限接近网站的100%页面。

2. 处理系统经过服务层，每次去取配置信息（可能维护人员在实时修正）及待抓取的列表进行处理。

待抓取的列表根据业务的优先级，分普通队列及优先级队列，经过任务调度系统进行统一管理和配置。

调度层

• 调度层主要是业务系统。

• 新增一个网站任务调度

• 网站发现频率，包括增量发现频率和全量发现频率

• 网站抓取优先级推送至队列

• 断点续抓管理

• ......

四  系统架构设计

• 从业务模块上看

应用层，服务层，业务处理层，调度层

• 从功能系统上看

发现系统，抓取系统， 配置系统，监控系统

• 从扩展性上看

自定义职责链，自定义属性提取

• 从实时性上看

实时抓取，实时配置生效，实时监控，实时测试

• 从系统架构上看

分布式架构，服务层主从切换设计，轻量（仅依赖于队列，数据库，java)

五  图例

①　

②　

③　

*爬虫模块 ui二 (1.6  任务配置) ：
定义每一个爬虫任务的处理执行职责链，不一样的爬虫任务能够有不一样的处理链。对于系统而言，处理每个待爬取的url，都会按照职责链的顺序执行。后置处理类则是一批任务执行后（如上文的100个url)，批量提交的方式。如文件落地，入库，推往线上系统等。经过任务处理定义，则能够自定义各种不一样场景的爬虫业务，在不编码的前提下增长系统的灵活性。*

④　​

*属性配置：
如图所示，维护人员增长条测试的url，同时定义须要提取的属性，则可在线定义该页面对应的属性输出，可见便可得。
在增长便利性，可测试性的基础上，又能灵活的选取页面的任意属性，值得一提的是，能够经过firefox插件获取sizzle的配置。*

⑤　

*1.9查看明细：

在爬虫系统的运行过程当中，几乎能够实时的进行任务的监控。因为爬虫任务实时将爬取的状态写入数据库，所以彻底能够经过ui界面进行管理及监控。1. 监控：监控爬虫任务当前时间成功次数，错误次数，什么模块错误，甚至某个属性提取错误。2. 管理：维护人员观测监控效果后，可实时进行编辑及管理（见上一张图），以应对不一样网站的改版需求。全部编辑实时生效，编辑完成后，无需重启服务，又可实时监控爬虫任务的最新效果。*

反爬虫
文章来源：http://bigsec.com/

踏浪无痕  岂安科技高级架构师 

十余年数据研发经验，擅长数据处理领域工做，如爬虫、搜索引擎、大数据应用高并发等。担任过架构师，研发经理等岗位。曾主导开发过大型爬虫，搜索引擎及大数据广告DMP系统目前负责岂安科技数据平台开发与搭建。