教你用一段程序打造百亿市值的公司

事情的缘由是这样的，这两天一篇文章《估值175亿的马蜂窝 竟是一座僵尸和水军构成的鬼城？》将马蜂窝推上了风口浪尖。文章通过爬虫采集和大数据的分析，有理有据的揭穿了马蜂窝“2100w真实点评"的本来面目。紧接着一篇文章，直指马蜂窝的游记——这也是重度污染区。大家感兴趣自己搜索阅读。

这事儿的基本步骤应该是这样：

1. 准备种子，进行采集，种子可能是自己网站的店家，当然也可以是其他网站一锅端过来的

2. 爬虫采集，开始下载网页

3. 页面解析抽取，拿出来想要的点评

4. 机器拼装新的点评，例如加入新的要推广的广告

5. 人工检查，甚至人工修正、拼装部分点评

6. 分散到不通过的小班长的账号，机器批量点评

这事儿如果做得好，技术水平比较高的话，马蜂窝的运营人员应该是不需要太多的。2100w的点评数据，其实给一个资深的程序员，写程序+采集数据，我估计一周就搞定了。2100w在爬虫的世界，不是什么大的数据量。真正的爬虫大户，百度、搜狗哪一家不是千亿级别以上的网页了。不过，这是另一个层次的爬虫了，下面就聊聊想马蜂窝这样的爬虫，该怎么弄，会有哪些门槛。以下的内容基本上需要一些编程的基础了。

爬虫说白了就是输入一些网页，作为种子，根据某些遍历算法，将遍历到的网页都下载下来的工具。遍历的方法也就深度优先，还是宽度优先。开发的过程中，大家会利用各种工具，以马蜂窝的这个量级，我们用Scrapy就可以了，使用Python语言实现，是一个基于异步事件的高性能的架构——堪称神奇。Scrapy简单好用，容易扩展为分布式，真是居家旅行，成就百亿公司的必备工具。Scrapy的架构如下：

主要有以下的组件：

Scrapy Engine

引擎负责控制数据流在系统中所有组件中流动，并在相应动作发生时触发事件。 数据流我们在后端介绍

调度器(Scheduler)

调度器从引擎接受request并将他们入队，以便之后引擎请求他们时提供给引擎。这里我们可以根据自己的需求，进行特殊定制，比如分布式的改造，就从这里定制开始。

下载器(Downloader)

下载器负责获取页面数据并提供给引擎，而后提供给spider。

Spiders

Spider是Scrapy用户编写用于分析response并提取item(即获取到的item)或额外跟进的URL的类。 每个spider负责处理一个特定(或一些)网站。 这个也可以理解为任务，要开始某一个采集的任务，就定义一个Spider。

Item Pipeline

Item Pipeline负责处理被spider提取出来的item。典型的处理有清理、 验证及持久化(例如存取到数据库中)。 针对下载的结果进行的处理，如抽取链接、抽取某部分内容等。抽取链接将会根据需求变成新的任务。

下载器中间件(Downloader middlewares)

下载器中间件是在引擎及下载器之间的特定钩子(specific hook)，处理Downloader传递给引擎的response。 其提供了一个简便的机制，通过插入自定义代码来扩展Scrapy功能。

Spider中间件(Spider middlewares)

Spider中间件是在引擎及Spider之间的特定钩子(specific hook)，处理spider的输入(response)和输出(items及requests)。 其提供了一个简便的机制，通过插入自定义代码来扩展Scrapy功能。

下面说一下数据流，可能对整个爬取处理的过程会更加明了。

1. 引擎从爬虫得到初始请求；

2. 引擎在调度器中调度请求，并请求下一个要爬取的请求；

3. 调度器返回引擎下一个要爬取的请求；

4. 通过下载中间件，引擎将请求发送到下载器；

5. 页面下载完毕之后，下载器生成一个该页面的响应，并通过下载中间件发送给引擎；

6. 引擎收到来自下载器的响应，并通过爬虫中间件，将它发送到爬虫进行处理；

7. 爬虫处理响应，而后返回抓取到的items和新的请求到引擎，返回还要要通过爬虫中间件；

8. 引擎将处理好的items发送到Item Pipelines，然后发送已处理的请求到调度器，并询问下个可能的请求；

9. 这个过程重复进行（从1开始），直到调度器没有更多的请求。

一个程序员，下载了scrapy学习个半天，基本上一个简易版的爬虫就能够完整的写下来。Scrapy的架构非常清晰，各司其职，对扩展非常友好，哪里是性能的瓶颈就扩展哪里。一个分布式的爬虫，也可以在这个基础上扩展起来。大家有感兴趣的分布式爬虫，可以留言交流。

数据搞下来了，剩下的数据清洗、处理相对容易一些，因为这都是垂直的网站采集，网页的格式都是固定的，所以抽取出来相应的内容很简单。但也会有失误，例如马蜂窝的点评会多带一些内容——略显尴尬。

简单科普下robots.txt协议，这个行业内的人都知道，是君子协定，并不是规范，更不能保护网站的隐私。而且一般是针对大型搜搜引擎公司的，这些公司可能比较讲究，还一定程度遵守一下下。但对这些垂直的爬虫，尤其是竞争对手的爬虫，就没人在意了。

我们团队长期积累了比较丰富的爬虫经验，当然也意味着丰富的防爬经验。这些都长期对抗的持久战，没有哪一种方法能够彻底的解决。这里简单分享一些爬虫的技巧和经验。

1. 爬取要尽量寻找突破口，因为大多数的都是HTTP请求，突破口难易程度从小到大: APP  > WAP > WEB

2. 要有高匿的代理IP池

3. 当然要有分布式的采集方式

4. 对于JS生成cookie的方式多用chrome headless或者phantomjs搞定

5. 对于验证码，比较难的考虑接入打码平台的API搞定

6. 对于大厂，API版本或者JS版本都可以利用下，比如某微博的登录分了N多版本，新老交替不会那么快ban掉老版本的方法

7. 有些网站的部分信息，需要从CSS渲染的字体里抠出来，有点意思吧

经验还有很多，但不能再讲了，还要留着吃饭不是~。大多都是需要大量的耐心才能发现，一攻一防，谁有耐心谁就能发现漏洞。其实通常来讲，就是看哪边懒了，现在越来越多的网站需要账号登录，爬虫爬取就难很多，且不说登录的麻烦，就是有些网站，搞一个账号都很难经过一系列的审核。有一些网站，还会对请求的参数进行加密，这样破解起来就颇费时间。但往往也只是费时间。有耐心，漏洞总是有的。

大数据时代，大家越来越重视数据的重要性。但与之相匹配的安全性并没有得到充分的提高。如果大家不信，我们随便找一下新上线的一些比较火的app，抓一下包，有的甚至都是明文密码登录的。

另外，大多数的网站、app，尤其是比较大的公司，管理上会有一些疏忽，团队换人、换负责人了，为了优化、重构等目的会升级一版API，但用户不知道这些，可能还在用着旧版的，这时候往往就是旧版的API泄露了数据。之前一个朋友闲聊，他讲了一个案例，一家小公司就靠着一个大公司的某一个版本的API，每年活得还是挺滋润的。这~，该如何是好。

另外，有些公司为了数据安全，采取的措施，直接影响到了用户体验。这是一个很矛盾的点，因为爬虫觉得很难的时候，也会影响到用户的体验。一个我们实际中的例子，QCC为了防爬虫，整个网站升级，公司基本信息的查看都需要登录，但没两天就回滚到之前的版本了。因为这样用户体验实在太差，一时防住了爬虫，但是用户也被逼到了竞争对手那边。

多聊几句防爬，防爬我觉得不要想着一招解决。其核心点就在成本上。如果我们能够比较低成本的使得爬虫获取数据要花费比较高的成本，就已经算是成功了。比如我们限制频率，爬虫要更多的IP。比如经常的修改网页的结构，基本上每次都能让爬虫瘫痪半天。这样的方法也有很多。

欢迎大家留言讨论更多的爬虫趣闻和反爬的策略。

最后，掌握了爬虫的程序员太可怕，互联网时代，得罪谁都不要得罪程序员。