网页抓取迁移到云端

我尝试解决的问题

上个月，我在做一个需要从多个JavaScript密集型网站抓取数据的项目。我一开始使用了常见的工具——本地运行Puppeteer和Playwright——但很快就遇到了瓶颈。我的笔记本风扇不停地转，内存使用率飙升，而且扩展到几个并发请求以上似乎是不可能的。

我心想："一定有更好的方法可以做到这一点，而不会把我的MacBook变成一个暖气片。"

于是我开始研究基于云的替代方案，这些方案可以处理浏览器自动化的重任，同时保持我的本地环境轻量化。以下是我花了一周时间测试不同解决方案后的发现。

我测试的基于云的无头浏览器服务

Apify：一站式平台

我首先尝试了Apify，它感觉就像是"网页抓取的AWS"。他们的云平台提供预构建的"Actors"（可以理解为抓取用的无服务器函数），内置了代理、调度和存储等所有功能。

我最喜欢的是，我可以拿我现有的Node.js爬虫代码，做最小的修改，然后将其部署为无服务器Actor。他们提供的Crawlee库使这个转换过程出奇地顺利。

仪表板让你可以查看运行情况、内存使用和日志——这比我在本地使用console.log进行调试的方式要先进得多。

Browserless.io：当你只需要浏览器时

接下来，我尝试了Browserless.io，它采用了更加专注的方法。它本质上是一个托管的无头Chrome和Playwright环境，你可以通过REST API访问。

最棒的部分？我可以保留大部分现有的Puppeteer代码，只需将其指向他们的服务，而不是启动本地浏览器。他们的API在后台处理所有的代理轮换和CAPTCHA解决方案。

对于已经投入使用Puppeteer/Playwright工作流的团队来说，这感觉是阻力最小的路径。

ScrapingBee：一行代码解决方案

ScrapingBee采用了一种不同的方法，在我只想要结果而不想费心处理浏览器自动化代码的日子里，我真的很欣赏这种方法。

他们的API非常简单——发送一个带有目标URL的HTTP请求，然后获取完全渲染的HTML。不需要管理浏览器实例，处理JavaScript执行，或担心被封禁。

// 这真的就是全部所需的代码
const response = await fetch(
  `https://app.scrapingbee.com/api/v1/?api_key=${apiKey}&url=${targetUrl}&render_js=true`,
)
const html = await response.text()

当我需要快速结果而不想承担浏览器自动化的认知负担时，我发现自己会选择这种方式。

其他值得一提的服务

我还简单测试了：

Zyte API（前身是Splash）：凭借其反封禁技术，非常适合JavaScript密集型页面
PhantomBuster：如果你需要自动化抓取之外的工作流程，这是一个很好的选择
ScrapingBot：使用真实浏览器规避检测的可靠选项
Scrapy Cloud：如果你已经在使用Scrapy，这是完美的选择

无服务器路线：DIY云抓取

对于某些项目，我想要更多地控制执行环境，同时仍然避免本地资源限制。这时我开始探索在无服务器函数中部署无头浏览器：

AWS Lambda实验

我在Lambda Layers中打包了带有无头Chrome的Puppeteer，令人惊讶的是它工作得很好。设置比使用专用服务更复杂，但对于我偶尔的抓取需求来说，按执行时间计费的模式很合理。

关键的发现是使用

chrome-aws-lambda

包，它提供了一个适当编译的Chromium版本，保持在Lambda的大小限制之内。

Google Cloud Functions体验

Google Cloud Functions（第二代）设置起来更容易，因为它已经包含了无头Chrome所需的许多系统包。我只需要使用

puppeteer-core

来保持部署大小可控。

这种方法为我提供了最佳的控制和可扩展性平衡，特别是在那些需要围绕抓取过程进行自定义逻辑的项目中。

我学到的经验和建议

经过几周的测试，如果你面临类似的挑战，以下是我的实用建议：

如果你刚刚开始：先尝试ScrapingBee。单个API调用的简单性将为你节省数小时的设置时间。
如果你有现有的Puppeteer/Playwright代码：Browserless.io提供了最平滑的过渡，只需最少的代码更改。
对于大规模、复杂的项目：Apify提供了最完整的生态系统，内置了调度、存储和代理管理。
如果你熟悉云服务：部署到AWS Lambda或Google Cloud Functions可以给你最大的控制权，潜在成本更低，特别是对于间歇性工作负载。

我学到的最大教训？**不要让基础设施问题限制你的数据收集项目。**这些云解决方案已经成熟到了这样一个程度：几乎没有什么好理由在本地机器上运行资源密集型浏览器。

我的抓取项目下一步计划

目前，我采用了一种混合方法：

ScrapingBee用于快速、一次性的抓取任务
Apify用于定期运行的计划数据收集作业
AWS Lambda用于需要自定义逻辑的专门抓取器

在我的下一篇文章中，我将分享一些实际的代码示例，展示我如何将这些服务集成到一个统一的数据管道中，为我的分析系统提供数据。

你尝试过这些服务吗？或者你有其他推荐的云抓取解决方案吗？请在评论中告诉我！

目录