企业级网络爬虫应用（1） 开篇

开篇不打算写太多技术细节，只想来阐述一下计划写该系列博客的初衷。

公司有一项业务是做政策收集及发布的，说白了就是人工查看哪些政府网站有新的政策发布了，就复制粘贴，修改下格式发布到我们的网站上，这算是一个政策信息的聚合平台吧。但是这种方式确实是费时费力，搞得这方面的人手一直紧张。后来leader一看一直招人也不是个办法，就想着能不能做个爬虫来自动抓取和发布信息，后来听说我会些python，就把这项光荣而艰巨的任务交个了我。其实博主也只是在实习期间学习过一段时间的python，这么长时间不用早就忘了，更别说之前对爬虫只是听说，没有任何的概念。没办法困难来了，硬着头皮也要上啊。

经过一个多月的加班奋战，终于在2015年年底完成了爬虫的第一个版本。该版本是基于大名鼎鼎的Scrapy框架开发的，由于python自身的队列不支持分布式，采用了Redis来作为url排重和队列，以实现爬虫的分布式抓取；存储采用的是mongodb数据库；动态网页采用的是Selenium模拟浏览器加载。其中实现了政策信息标题、时间、内容的自动抽取，地域、行业的自动划分等功能。

转眼到了2016年的年底，一年时间就这样过去了，这一年间该爬虫运行还算稳定，公司leader对这套系统也算满意，并表示希望能通过爬虫覆盖全国的网站，每当这时我都感觉羞愧难当，因为我深知这套系统还远远达不到令我满意的效果，随着对爬虫技术的不断了解，这种感觉越来越明显，但是苦于忙于其他事情，一直抽不出时间来改，很是着急。

正好年底做计划时leader把爬虫的改版任务列入了明年的计划中，博主也想借这个机会再系统的了解下爬虫，并写个系列的博客，一方面是通过总结加深理解，另一方面也希望我的文章能对一些人有所帮助。粗略规划了下下一步要改进的方面:

1. 增加可视化调度系统
   目前版本的爬虫系统的启动、停止、重启只能通过登录每台虚拟机通过命令行的方式进行操作，费时费力。采用图形化的调度处理，点点按钮就可以启动、停止爬虫线程，方便快捷，而且可以实时监控爬虫的运行状态。
   初步规划使用可视化调度架构Dagobah实现。

2. 改变爬虫部署环境
   目前爬虫部署方式是，在服务器下用VMWare建立多个Linux虚拟机，分别用来部署爬虫。这种方式的缺点是对资源消耗较多，且难以维护。
   规划使用Docker作为爬虫的部署容器。

3. 动态页面处理
   目前爬虫系统内部处理动态页面都是采用PhantomJS来模拟浏览器，但整体效率感觉还是达不到要求。Scrapy官方推荐的处理动态页面的方式为scrapyjs，规划改用这种方式。

4. 系统故障预警
   像爬虫系统这样要求实时性较高的系统，故障预警显得尤为重要，能够避免因程序、网络或数据库故障导致数据抓取保存失败，而相关人员却不知道而造成的损失。
   规划在程序中加入相关监控机制，出现故障及时邮件通知相关人员。

5. 数据存储方式
   目前版本系统的数据是存储在mongodb中，初期这种存储方式效率会很高。但随着数据量的不断增加，查询写入速度会变的越来越慢。
   规划下个版本改用HBase作为抓取数据的存储方式。

6. 增加消息队列
   目前版本系统数据都是直接操作数据库进行数据的存取的，但是这种方式随着爬虫线程的增加，对数据库会造成很大的压力。
   下个版本规划使用kafka做消息队列，所有数据都通过kafka再实例化到数据库。

7. 数据可视化
   开发数据可视化系统，以图形图像方式展现数据。可使用的框架有D3.js、Echarts等。

8. 页面配置优化
   目前我们的抓取规则都是通过人工配置XPath的方式，从浏览器复制xpath再粘贴到配置页面，还是有些麻烦的，下个版本计划做一个类似八爪鱼那样的配置客户端，通过集成模拟浏览器，来实现区域的选中，省去了复制粘贴的繁琐。

以上就是规划的下个版本要优化的功能，可以看出真正的抓取功能只是占整个系统的很少的一部分，大部分还是集中在系统的完整性和数据的展现方面。稍后几篇博客可能就会介绍整体架构设计和其中的一些细节的功能，希望我能坚持写完直到整个系统上线。

同时恳请看到博客的大佬们，如果其中有什么观点存在错误或歧义的，请留言指出，博主一定尽快修正，以免误人子弟，先在此谢过。