Oxylabs等公司提供的网络抓取服务即使对于未做过网络抓取活动的人来说也十分简单。只需要一点编程知识(通常是Python),就能轻松上手。当然,需要扩大规模时,就另当别论了。那时简单的方法完全不足以对付。
用于小项目的自制网络爬虫处理小型任务可谓游刃有余。但在需要大量数据或持续抓取时,事情就比较棘手了。负载管理是个问题,IP拦截接踵而至,新的服务器也需要采购,等等。没有一个良好的基础,整个工作容易变得迟缓,甚至完全行不通。
大规模抓取概览
所有网络抓取都以相同方式开始,采用相同模式运作。有一个可以执行抓取的自动应用程序,一个或多个作为数据来源的URL,以及交付目标(即,通常是JSON或CSV文件)。
小规模抓取项目通常会原封不动地保留上面概括的结构。无需增加额外的复杂度,因为发送请求的人只有所有者,并且数据库存储在本地。通常也没有将数据库迁移到别处的打算。
但是,扩大规模时,就必须升级,比如说,想办法远距离与爬虫交互。有时,这意味着开发或使用API来发送命令。但是,由于可以远程访问爬虫,结果也应该远程交付。
这意味着开发一种方法来通过互联网呈现所发现的结果。如果将其存储在文件或数据库中,就需要获取对存储空间的访问权。打印出结果可能适用于单个请求,不过,在许多情况下,可能需要历史数据。
如果需要历史数据,则有可能数据库必须从原始机器迁移到独立服务器上。现在就有必要开发一种方法,以便在多台机器之间同时通信。
最后,到一定时候,传递的请求数量会高得无法应对。这时需要更多机器。这些机器必须与主服务器通信,后者充当负载管理系统并收集队列。然后,如何优化队列并发送作业到恰当的机器也是一个问题。
总的来说,现在这个三步式项目的运作方式如下:
1.通过API发送一个请求。
2.主服务器收到该请求,并检查现有队列。
3.负载均衡器提取该请求。
4.该请求被发送到某个地方进行解释和执行。
5.然后,数据将发送到存储空间,直接发送给被请求者,或者发送到临时服务器上。
6.在这个过程的某个节点,必须进行日志记录,以方便进行故障诊断。
之前是单台机器执行同步代码,而现在情况变成几十台甚至上百台机器异步执行许多不同的操作,彼此通信,并将数据传递到多个第三方。
这个看起来很简单的过程沿许多不同方向扩充增长,最后变成的样子与原始项目简直天壤之别。我们必须摸索出自己的恰当做事方法。不一定非得是那种方法。
用正确的方式打基础
Oxylabs爬虫API经历了类似的几个阶段。事实上,第一个原型用于解决一个特定问题。它甚至无法扩展。但是,公司逐渐从频繁发生的问题中吸取了经验教训。克服这些问题可以节省大量时间和资源。
哪些方面必须频繁地进行扩展?当然,使用足够的服务器来执行抓取和/或解析工作是很有必要的。但是,根据Oxylabs的经验,这一点并非经常出现瓶颈的地方,因为潜在的问题很容易识别。
令人感到讽刺的是,核心集群却很容易被忽视。事实上,Oxylabs经常在队列管理工具和负载均衡器处遇到瓶颈。这样说固然有点事后诸葛亮,不过他们应该预料到,主要的请求通路最终会被拥堵。但是,在繁忙的紧要关头,人们很容易开始四处查找问题,却忽视了根源所在。
另一方面,为故障诊断目的进行日志记录可能是一件令人头疼的事情。日志记录需要足够详细,才能为可能显现的任何问题提供见解。但是,如果针对如此复杂的过程的详细记录日志,要记录的东西实在太多。这就意味着,每个日志会占据很大的空间。此外,这些日志还得保留一定时间。过早删除日志,整个日志记录过程就白费了。
在Oxylabs,员工们一度需要很频繁地升级详细的日志记录服务器。但是,重要的决策是找出很好的删除时间。由于公司的服务器每天会产生几十个TB的故障诊断日志,找到同时满足客户和公司要求的合适时间至关重要,因为这样就能在恰当的管理下释放大量资源。
结论
随着网络抓取项目的改善,其复杂度几乎难免会提高。在同时升级软件和硬件功能时,很容易见树不见林。没有恰当的基础设施,能够实施的优化是比较有限的。要避免频繁的硬件改进,就得时刻牢记上面概括的可能瓶颈,以便周密安排整个项目。
作者:JurasJursenas,Oxylabs.io的运营官
