如何构建垂直网络爬虫平台

写一个爬虫很简单，写一个可持续稳定运行的爬虫也不难，但如何构建一个通用化的垂直网络爬虫平台？

这篇文章主要介绍垂直网络爬虫平台的构建思路。

爬虫简介

首先介绍一下什么是爬虫？

网络爬虫（又被称为网页蜘蛛，网络机器人），是一种按照一定的规则，自动地抓取网页信息的程序或者脚本。

很简单，爬虫就是指定规则自动采集数据的程序脚本，目的在于拿到想要的数据。

爬虫主要分两类：

• 通用网络爬虫（搜索引擎）
• 垂直网络爬虫（特定领域）

由于第一类的开发成本较高，故只有搜索引擎公司在做，如谷歌、百度等。

而大多数企业在做的是第二类，成本低、数据价值高。例如一家做电商的公司只需要电商领域有价值的数据，那开发一个电商领域的爬虫平台，意义较大。

这篇文章主要针对第二类的平台构建提供设计与思路。

如何写爬虫

首先从最简单的开始，我们先了解一下如何写一个爬虫？

简单爬虫

这个爬虫比较简单，大致流程为：

• 定义页面URL和解析规则
• 发起HTTP请求
• 解析HTML，拿到数据
• 保存数据

任何爬虫，要想获取网页上的数据，都是经过这几步。

当然，这个简单爬虫效率比较低，只能抓完一个网页，再去抓下一个，有没有提高效率的方式呢？

异步爬虫

经过优化，我们完成了异步版本的爬虫代码。

由于爬虫要抓的网页一般很多，提高效率是爬虫最基本的技能，由于下载网页都是阻塞在网络IO上，那我们可以利用多线程或异步的方式，提高抓取效率。

有了这些基础知识之后，我们看一个完整的例子，如何抓取一个整站数据？

整站爬虫

此爬虫以豆瓣图书为例，抓取整站信息，大致思路为：

• 从标签页进入，提取所有标签URL
• 进入每个标签页，提取所有列表URL
• 进入每个列表页，提取每一页的详情URL和下一页列表URL
• 进入每个详情页，拿到书名
• 如此往复循环，直到数据抓取完毕

这就是抓取一个整站的思路，很简单，无非就是分析我们浏览网站的行为轨迹，用程序来进行自动化的请求、抓取。

理想情况下，我们应该能够拿到整站的数据，但实际情况对方网站往往会采取防爬虫措施，在抓取一段时间后，我们的IP就会被禁。

那如何突破这些防爬错误，拿到数据呢？我们继续优化代码。

防反爬的整站爬虫

这个版本的爬虫代码，加上了随机代理和请求头，这也是突破防爬措施的常用手段，使用此手段，加上一些质量高的代理，应对一些小网站的数据抓取，不在话下。

当然，这里只为了展示一步步写爬虫、优化爬虫的思路，来达到抓取数据的目的，现实情况的抓取与反爬比想象中的更复杂，需要具体场景具体分析。

现有问题

经过上面这几步，我们想要哪个网站的数据，分析网站网页结构，写出代码应该不成问题。
抓几个网站可以这么写，但抓几十个、几百个网站，你还能写下去吗？

由此暴露的问题：

• 爬虫脚本繁多，管理困难
• 规则定义零散，重复开发
• 后台脚本，无监控
• 数据输出困难，业务接入慢

这些问题都是我们在爬虫越写越多的情况下，难免会遇到的问题。

此时，我们迫切需要一个更好的解决方案，来更好地开发爬虫，爬虫平台应运而生。

平台架构

我们来分析每个爬虫的共同点，结果发现：写一个爬虫无非就是规则、抓取、解析、入库这几步，那我们可不可以把每一块分别拆开呢？如图：

• 配置服务：包括抓取页面配置、解析规则配置、清洗配置
• 采集服务：专注网页下载与采集，并提供防爬策略
• 代理服务：提供稳定可持续输出的代理
• 清洗服务：针对同一类型业务进行字段清洗
• 数据服务：数据展示及业务数据对接

我们把一个爬虫的每一个环节，拆开做成一个个单独的服务模块，各模块各司其职。

每个模块维护属于自己领域的功能，可独立升级和优化。

详细设计

配置服务

此模块主要包括采集URL配置、页面解析规则配置、清洗配置。

我们把爬虫的规则从爬虫脚本中抽离出来，单独配置与维护，这样也便于重用与管理。

由于此模块专注配置管理，那我们可以对配置进一步拆开，配置支持各种方式的数据解析模式，如正则解析、CSS解析、XPATH解析，每种模式配置对应的表达式即可。

采集服务可以写一个配置解析器与配置服务进行对接，此配置解析器内部实现各种模式具体的解析逻辑。

清洗配置主要可配置每个爬虫输出后对应的清洗worker。

采集服务

此模块比较纯粹，就是写爬虫逻辑的模块，我们可以像之前那样开发、调试、运行爬虫脚本，但这一切工作都只能在命令行脚本进行，有没有一种好的方案是可以可视化操作的呢？

我们调研了市面上比较好的爬虫框架，发现pyspider符合我们的需求，此框架的特点：

• 支持分布式
• 配置可视化
• 可周期采集
• 支持优先级
• 任务可监控

pyspider架构图：

正所谓站在巨人的肩膀上。我们决定对其进行二次开发，并增强其一些组件，使爬虫开发成本更低，更符合我们的业务规则。

• 开发配置解析器，对接配置服务
• spider handler定制爬虫模板，分类采集任务，生成模板，降低开发成本
• fetcher新增代理调度机制，对接代理服务，并增加代理调度策略
• result_worker输出定制化，对接清洗服务

由此我们可做出一个分布式、可视化、任务可监控、可生成爬虫模板的采集服务模块。

代理服务

做爬虫的都知道，代理是突破防抓的常用手段，如何获取稳定且持续的代理呢？

此模块内部维护代理的质量和数量，并输出给采集服务，供采集使用。

主要包括两部分：

• 免费代理
• 付费代理

免费代理

免费代理主要由我们自己的代理采集程序采集获得，大致思路为：

• 收集代理源
• 定时采集代理
• 测试代理
• 输出代理

付费代理

免费代理的质量和稳定性相对较差，对于采集防爬比较厉害的网站，还是不够用。
这时我们会购买一些付费代理，专门用于采集这类防爬的网站，此代理一般为高匿代理，并定时更新。

清洗服务

此模块比较简单，主要接收采集服务输出的数据，然后根据对应的规则执行清洗逻辑。

例如网页字段与数据库字段归一转换，特殊字段清洗定制化等。

这个服务模块运行了很多worker，最终把输出结果输送到数据服务。

数据服务

此模块会接收最终清洗后的结构化数据，统一入库。且针对其他业务系统需要的数据进行统一推送输出：

• 数据平台展示
• 数据推送
• 数据API

解决的问题

经过这个平台的构建，基本解决了最开始困扰的几个问题：

• 爬虫管理、配置可视化
• 降低开发成本
• 进度可监控、易跟踪
• 数据输出便捷
• 业务接入迅速

爬虫技巧

爬虫技巧从整体上来说，其实核心思想就一个：尽可能地模拟人的行为。

例如：

• 随机UserAgent（github fake-useragent）
• 随机代理IP（高匿代理、代理策略）
• Cookie池
• JS渲染页面（phantomjs）
• 验证码识别（OCR、机器学习）

当然，做爬虫是一个相互博弈的过程，有时没必要硬碰硬，遇到问题换个思路不免是一种解决办法。例如，对方的PC站防抓厉害，那去看一看对方的WAP站可不可以搞一下？APP端是否可以尝试一下？在有限的成本拿到数据才是爬虫的目的。

以上就是构建一个垂直网络爬虫平台的大致思路，从最简单的爬虫脚本，到写越来越多的爬虫，到难以维护，再到整个爬虫平台的构建，一步步都是遇到问题解决问题的产物，在我们真正发现核心问题时，解决思路也就不难了。

前端解决跨域问题的8种方案（最新最全）

document.domain = 'a.com';

function loadScript(url, func) {
  var head = document.head || document.getElementByTagName('head')[0];
  var script = document.createElement('script');
  script.src = url;

  script.onload = script.onreadystatechange = function(){
    if(!this.readyState || this.readyState=='loaded' || this.readyState=='complete'){
      func();
      script.onload = script.onreadystatechange = null;
    }
  };

  head.insertBefore(script, 0);
}
window.baidu = {
  sug: function(data){
    console.log(data);
  }
}
loadScript('http://suggestion.baidu.com/su?wd=w',function(){console.log('loaded')});
//我们请求的内容在哪里？
//我们可以在chorme调试面板的source中看到script引入的内容

function startRequest(){
    var ifr = document.createElement('iframe');
    ifr.style.display = 'none';
    ifr.src = 'http://www.cnblogs.com/lab/cscript/cs2.html#paramdo';
    document.body.appendChild(ifr);
}

function checkHash() {
    try {
        var data = location.hash ? location.hash.substring(1) : '';
        if (console.log) {
            console.log('Now the data is '+data);
        }
    } catch(e) {};
}
setInterval(checkHash, 2000);

//模拟一个简单的参数处理操作
switch(location.hash){
    case '#paramdo':
        callBack();
        break;
    case '#paramset':
        //do something……
        break;
}

function callBack(){
    try {
        parent.location.hash = 'somedata';
    } catch (e) {
        // ie、chrome的安全机制无法修改parent.location.hash，
        // 所以要利用一个中间的cnblogs域下的代理iframe
        var ifrproxy = document.createElement('iframe');
        ifrproxy.style.display = 'none';
        ifrproxy.src = 'http://a.com/test/cscript/cs3.html#somedata';    // 注意该文件在"a.com"域下
        document.body.appendChild(ifrproxy);
    }
}

//因为parent.parent和自身属于同一个域，所以可以改变其location.hash的值
parent.parent.location.hash = self.location.hash.substring(1);

<head>
  <script>
  function proxy(url, func){
    var isFirst = true,
        ifr = document.createElement('iframe'),
        loadFunc = function(){
          if(isFirst){
            ifr.contentWindow.location = 'http://a.com/cs1.html';
            isFirst = false;
          }else{
            func(ifr.contentWindow.name);
            ifr.contentWindow.close();
            document.body.removeChild(ifr);
            ifr.src = '';
            ifr = null;
          }
        };

    ifr.src = url;
    ifr.style.display = 'none';
    if(ifr.attachEvent) ifr.attachEvent('onload', loadFunc);
    else ifr.onload = loadFunc;

    document.body.appendChild(iframe);
  }
</script>
</head>
<body>
  <script>
    proxy('http://www.baidu.com/', function(data){
      console.log(data);
    });
  </script>
</body>

<script>
    window.name = '要传送的内容';
</script>

<iframe id="ifr" src="b.com/index.html"></iframe>
<script type="text/javascript">
window.onload = function() {
    var ifr = document.getElementById('ifr');
    var targetOrigin = 'http://b.com';  // 若写成'http://b.com/c/proxy.html'效果一样
                                        // 若写成'http://c.com'就不会执行postMessage了
    ifr.contentWindow.postMessage('I was there!', targetOrigin);
};
</script>

<script type="text/javascript">
    window.addEventListener('message', function(event){
        // 通过origin属性判断消息来源地址
        if (event.origin == 'http://a.com') {
            alert(event.data);    // 弹出"I was there!"
            alert(event.source);  // 对a.com、index.html中window对象的引用
                                  // 但由于同源策略，这里event.source不可以访问window对象
        }
    }, false);
</script>

var xdr = new XDomainRequest();
xdr.onload = function(){
    console.log(xdr.responseText);
}
xdr.open('get', 'http://www.baidu.com');
......
xdr.send(null);

var xhr =  new XMLHttpRequest();
xhr.onreadystatechange = function () {
    if(xhr.readyState == 4){
        if(xhr.status >= 200 && xhr.status < 304 || xhr.status == 304){
            console.log(xhr.responseText);
        }
    }
}
xhr.open('get', 'http://www.baidu.com');
......
xhr.send(null);

function createCORS(method, url){
    var xhr = new XMLHttpRequest();
    if('withCredentials' in xhr){
        xhr.open(method, url, true);
    }else if(typeof XDomainRequest != 'undefined'){
        var xhr = new XDomainRequest();
        xhr.open(method, url);
    }else{
        xhr = null;
    }
    return xhr;
}
var request = createCORS('get', 'http://www.baidu.com');
if(request){
    request.onload = function(){
        ......
    };
    request.send();
}

function handleResponse(response){
    console.log('The responsed data is: '+response.data);
}
var script = document.createElement('script');
script.src = 'http://www.baidu.com/json/?callback=handleResponse';
document.body.insertBefore(script, document.body.firstChild);
/*handleResonse({"data": "zhe"})*/
//原理如下：
//当我们通过script标签请求时
//后台就会根据相应的参数(json,handleResponse)
//来生成相应的json数据(handleResponse({"data": "zhe"}))
//最后这个返回的json数据(代码)就会被放在当前js文件中被执行
//至此跨域通信完成

var socket = new WebSockt('ws://www.baidu.com');//http->ws; https->wss
socket.send('hello WebSockt');
socket.onmessage = function(event){
    var data = event.data;
}

在服务器上排除问题的头 5 分钟

遇到服务器故障，问题出现的原因很少可以一下就想到。我们基本上都会从以下步骤入手：

一、尽可能搞清楚问题的前因后果

不要一下子就扎到服务器前面，你需要先搞明白对这台服务器有多少已知的情况，还有故障的具体情况。不然你很可能就是在无的放矢。

必须搞清楚的问题有：

• 故障的表现是什么？无响应？报错？
• 故障是什么时候发现的？
• 故障是否可重现？
• 有没有出现的规律（比如每小时出现一次）
• 最后一次对整个平台进行更新的内容是什么（代码、服务器等）？
• 故障影响的特定用户群是什么样的(已登录的, 退出的, 某个地域的…)?
• 基础架构（物理的、逻辑的）的文档是否能找到?
• 是否有监控平台可用? （比如Munin、Zabbix、 Nagios、 New Relic… 什么都可以）
• 是否有日志可以查看?. （比如Loggly、Airbrake、 Graylog…）

最后两个是最方便的信息来源，不过别抱太大希望，基本上它们都不会有。只能再继续摸索了。

二、有谁在?

$ w

$ last

用这两个命令看看都有谁在线，有哪些用户访问过。这不是什么关键步骤，不过最好别在其他用户正干活的时候来调试系统。有道是一山不容二虎嘛。（ne cook in the kitchen is enough.）

三、之前发生了什么?

$ history

查看一下之前服务器上执行过的命令。看一下总是没错的，加上前面看的谁登录过的信息，应该有点用。另外作为admin要注意，不要利用自己的权限去侵犯别人的隐私哦。

到这里先提醒一下，等会你可能会需要更新 HISTTIMEFORMAT 环境变量来显示这些命令被执行的时间。对要不然光看到一堆不知道啥时候执行的命令，同样会令人抓狂的。

四、现在在运行的进程是啥?

$ pstree -a

$ ps aux

这都是查看现有进程的。 ps aux 的结果比较杂乱， pstree -a 的结果比较简单明了，可以看到正在运行的进程及相关用户。

五、监听的网络服务

$ netstat -ntlp

$ netstat -nulp

$ netstat -nxlp

我一般都分开运行这三个命令，不想一下子看到列出一大堆所有的服务。netstat -nalp倒也可以。不过我绝不会用 numeric 选项 （鄙人一点浅薄的看法：IP 地址看起来更方便）。

找到所有正在运行的服务，检查它们是否应该运行。查看各个监听端口。在netstat显示的服务列表中的PID 和 ps aux 进程列表中的是一样的。

如果服务器上有好几个Java或者Erlang什么的进程在同时运行，能够按PID分别找到每个进程就很重要了。

通常我们建议每台服务器上运行的服务少一点，必要时可以增加服务器。如果你看到一台服务器上有三四十个监听端口开着，那还是做个记录，回头有空的时候清理一下，重新组织一下服务器。

六、CPU 和内存

$ free -m

$ uptime

$ top

$ htop

注意以下问题:

• 还有空余的内存吗? 服务器是否正在内存和硬盘之间进行swap?
• 还有剩余的CPU吗? 服务器是几核的? 是否有某些CPU核负载过多了?
• 服务器最大的负载来自什么地方? 平均负载是多少?

七、硬件

$ lspci

$ dmidecode

$ ethtool

有很多服务器还是裸机状态，可以看一下：

• 找到RAID 卡 (是否带BBU备用电池?)、 CPU、空余的内存插槽。根据这些情况可以大致了解硬件问题的来源和性能改进的办法。
• 网卡是否设置好? 是否正运行在半双工状态? 速度是10MBps? 有没有 TX/RX 报错?

八、IO 性能

$ iostat -kx 2

$ vmstat 2 10

$ mpstat 2 10

$ dstat --top-io --top-bio

这些命令对于调试后端性能非常有用。

• 检查磁盘使用量：服务器硬盘是否已满?
• 是否开启了swap交换模式 (si/so)?
• CPU被谁占用：系统进程? 用户进程? 虚拟机?
• dstat 是我的最爱。用它可以看到谁在进行 IO： 是不是MySQL吃掉了所有的系统资源? 还是你的PHP进程?

九、挂载点 和 文件系统

$ mount

$ cat /etc/fstab

$ vgs

$ pvs

$ lvs

$ df -h

$ lsof +D / /* beware not to kill your box */

• 一共挂载了多少文件系统?
• 有没有某个服务专用的文件系统? (比如MySQL?)
• 文件系统的挂载选项是什么： noatime? default? 有没有文件系统被重新挂载为只读模式了？
• 磁盘空间是否还有剩余?
• 是否有大文件被删除但没有清空?
• 如果磁盘空间有问题，你是否还有空间来扩展一个分区？

十、内核、中断和网络

$ sysctl -a | grep ...

$ cat /proc/interrupts

$ cat /proc/net/ip_conntrack /* may take some time on busy servers */

$ netstat

$ ss -s

• 你的中断请求是否是均衡地分配给CPU处理，还是会有某个CPU的核因为大量的网络中断请求或者RAID请求而过载了？
• SWAP交换的设置是什么？对于工作站来说swappinness 设为 60 就很好, 不过对于服务器就太糟了：你最好永远不要让服务器做SWAP交换，不然对磁盘的读写会锁死SWAP进程。
• conntrack_max 是否设的足够大，能应付你服务器的流量?
• 在不同状态下(TIME_WAIT, …)TCP连接时间的设置是怎样的？
• 如果要显示所有存在的连接，netstat 会比较慢， 你可以先用 ss 看一下总体情况。

你还可以看一下 Linux TCP tuning 了解网络性能调优的一些要点。

十一、系统日志和内核消息

$ dmesg

$ less /var/log/messages

$ less /var/log/secure

$ less /var/log/auth

• 查看错误和警告消息，比如看看是不是很多关于连接数过多导致？
• 看看是否有硬件错误或文件系统错误?
• 分析是否能将这些错误事件和前面发现的疑点进行时间上的比对。

十二、定时任务

$ ls /etc/cron* + cat

$ for user in $(cat /etc/passwd | cut -f1 -d:); do crontab -l -u $user; done

• 是否有某个定时任务运行过于频繁?
• 是否有些用户提交了隐藏的定时任务?
• 在出现故障的时候，是否正好有某个备份任务在执行？

十三、应用系统日志

这里边可分析的东西就多了, 不过恐怕你作为运维人员是没功夫去仔细研究它的。关注那些明显的问题，比如在一个典型的LAMP（Linux+Apache+Mysql+Perl）应用环境里:

• Apache & Nginx; 查找访问和错误日志, 直接找 5xx 错误, 再看看是否有 limit_zone错误。
• MySQL; 在mysql.log找错误消息，看看有没有结构损坏的表， 是否有innodb修复进程在运行，是否有disk/index/query 问题.
• PHP-FPM; 如果设定了 php-slow 日志, 直接找错误信息 (php, mysql, memcache, …)，如果没设定，赶紧设定。
• Varnish; 在varnishlog 和 varnishstat 里, 检查 hit/miss比. 看看配置信息里是否遗漏了什么规则，使最终用户可以直接攻击你的后端？
• HA-Proxy; 后端的状况如何？健康状况检查是否成功？是前端还是后端的队列大小达到最大值了？

结论

经过这5分钟之后，你应该对如下情况比较清楚了：

• 在服务器上运行的都是些啥？
• 这个故障看起来是和 IO/硬件/网络 或者 系统配置 (有问题的代码、系统内核调优, …)相关。
• 这个故障是否有你熟悉的一些特征？比如对数据库索引使用不当，或者太多的apache后台进程。

你甚至有可能找到真正的故障源头。就算还没有找到，搞清楚了上面这些情况之后，你现在也具备了深挖下去的条件。继续努力吧！