Node.js 浏览器引擎 + Python 大脑：Playwright 混合架构爬虫系统深度解析
当 requests 拿不到数据、Selenium 跑不动并发时，这套架构救了我
一个让我失眠的夜晚
去年秋天接了一个电商价格监控的项目，甲方要求实时抓取日本雅虎拍卖的商品数据——当前出价、剩余时间、竞拍人数，延迟不能超过 5 秒。
一开始我想得挺简单：requests + BeautifulSoup，半小时写完，跑起来一看——页面一片空白。
原因不复杂：雅虎拍卖的商品页是典型的 SPA（单页应用），价格和倒计时全部通过 JavaScript 异步加载。requests 拿到的只是一个空壳 HTML，真正的数据根本不在里面。
换 Selenium？我试了。开了 20 个浏览器实例，机器 CPU 直接飙到 96%，内存暴涨，跑不到 20 分钟容器就 OOM 崩了。甲方还在催，我差点想跑路。
后来折腾出来的这套方案，就是今天想跟大家聊的——Node.js 做浏览器引擎，Python 做大脑的 Playwright 混合架构。
为什么要搞混合架构？
直接说结论：纯 Python Playwright 不是不能跑，但在高并发场景下，资源开销是个大问题。
Playwright 本身是多语言支持的——Python、Java、.NET、Node.js 都能用。但有一个细节很多人没注意到：Node.js 版本的 Playwright 不会像 Python 版本那样为每个浏览器窗口生成一个新进程，因此在管理多个标签页时，CPU 和内存开销要小得多。
什么意思呢？简单说——
-
Python Playwright：每个浏览器上下文会启动独立的子进程，开 20 个实例基本就把机器榨干了 -
Node.js Playwright：事件驱动模型，同一个进程里可以高效管理多个浏览器实例
所以我的思路很直接：用 Node.js 专门管浏览器（体力活），用 Python 做调度和数据处理（脑力活） 。两者通过 REST API 通信。
架构长什么样？
整体拆成三层：
┌─────────────────────────────────────────────────┐
│ Python 调度层 │
│ 任务队列 → 调用渲染接口 → 解析数据 → 落库 │
└────────────────────┬────────────────────────────┘
│ REST API / JSON
┌────────────────────▼────────────────────────────┐
│ Node.js 浏览器服务层 │
│ 浏览器池管理 → 页面渲染 → 执行 JS 交互 │
└────────────────────┬────────────────────────────┘
│ CDP 协议
┌────────────────────▼────────────────────────────┐
│ 无头 Chromium 实例 │
└─────────────────────────────────────────────────┘
这个分层的好处很明显：浏览器服务可以独立扩容，Python 调度器完全不用关心浏览器怎么跑。想加并发？多部署几个 Node.js 服务实例就行。
Node.js 浏览器服务：核心代码
浏览器服务我用 Express 搭了一个 HTTP 接口，核心是维护一个浏览器实例池：
const express = require('express');
const { chromium } = require('playwright');
const app = express();
app.use(express.json());
const PORT = 3000;
const browserPool = {};
const MAX_BROWSERS = 5;
asyncfunction getBrowserInstance(id) {
if (!browserPool[id]) {
browserPool[id] = await chromium.launch({
headless: true,
args: ['--no-sandbox']
});
}
return browserPool[id];
}
app.post('/render', async (req, res) => {
const { url, js_actions, session_id = 'default' } = req.body;
try {
const browser = await getBrowserInstance(session_id);
const context = await browser.newContext({
userAgent: 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36'
});
const page = await context.newPage();
await page.goto(url, { waitUntil: 'networkidle', timeout: 60000 });
// 执行自定义 JS 操作（点击、滚动等）
for (const action of js_actions || []) {
if (action.type === 'click') {
await page.click(action.selector);
await page.waitForTimeout(2000);
} elseif (action.type === 'scroll') {
await page.evaluate(() =>window.scrollTo(0, document.body.scrollHeight));
await page.waitForTimeout(1000);
}
}
const content = await page.content();
const screenshot = await page.screenshot({ fullPage: true });
await context.close();
res.json({
success: true,
html: content,
screenshot: screenshot.toString('base64')
});
} catch (error) {
res.status(500).json({ success: false, error: error.message });
}
});
app.listen(PORT, () => console.log(`Browser service running on port ${PORT}`));
踩坑提醒：浏览器实例池的大小要根据机器配置来调。我实测 8 核 16G 的机器，每个浏览器进程大概吃 150~250MB 内存，MAX_BROWSERS 设到 5 是比较稳妥的。想跑更多？上容器拆分。
Python 调度器：大脑怎么指挥手脚
Python 这边就简单多了——发 HTTP 请求让 Node.js 去干活，拿到 HTML 后用 BeautifulSoup 解析：
import requests
from bs4 import BeautifulSoup
import time
BROWSER_API = "http://localhost:3000/render"
def fetch_rendered_page(url, actions=None):
payload = {
"url": url,
"js_actions": actions or [],
"session_id": "default"
}
resp = requests.post(BROWSER_API, json=payload, timeout=120)
if resp.status_code == 200:
data = resp.json()
if data.get('success'):
return data.get('html')
returnNone
def parse_product_data(html):
soup = BeautifulSoup(html, 'html.parser')
# 这里写具体的解析逻辑
price = soup.select_one('.product-price')
title = soup.select_one('.product-title')
return {
'price': price.text.strip() if price elseNone,
'title': title.text.strip() if title elseNone
}
# 调度循环
urls = ['https://example.com/item/1', 'https://example.com/item/2']
for url in urls:
html = fetch_rendered_page(url, [
{'type': 'scroll'}, # 先滚动加载更多
{'type': 'click', 'selector': '.load-more'} # 再点加载按钮
])
if html:
data = parse_product_data(html)
# 存数据库...
time.sleep(2) # 礼貌爬虫，控制频率
关键点：js_actions 这个设计让 Python 可以灵活控制浏览器的行为——滚动、点击、输入，全都能远程指挥。这样就算页面逻辑再复杂，Python 调度层也不需要改动，只需调整 actions 参数就行。
反爬怎么办？三层防御
这套架构跑通之后，第二个问题来了：雅虎的反爬不是吃素的。
我踩过的坑包括：IP 封禁、自动化特征检测、请求频率限制。解决方案分三层：
第一层：指纹伪装
普通的 Playwright 跑的是 Chromium 标准构建版本，反爬系统早就把特征研究透了——哪些 JavaScript API 行为和真实 Chrome 不一样、Canvas 渲染有什么细微差异、WebGL 特征码对不上，全都有档案。
最基本的伪装：
browser = await p.chromium.launch(
headless=True,
args=['--disable-blink-features=AutomationControlled'] # 关掉自动化标记
)
context = await browser.new_context(
user_agent='Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/120.0.0.0 Safari/537.36',
viewport={'width': 1920, 'height': 1080}
)
更狠的可以用 playwright-stealth 这类库来抹掉自动化痕迹。但注意，老版的 playwright-stealth 已经停更了，现在推荐用 pw-stealth-enhanced。
第二层：代理轮换
高并发请求下，固定出口 IP 很快就会被封。我的做法是给每个浏览器会话分配独立代理：
proxies = get_proxy_from_pool() # 从代理池取一个
context = await browser.new_context(
proxy={
'server': f'http://{proxies["host"]}:{proxies["port"]}',
'username': proxies['user'],
'password': proxies['pass']
}
)
第三层：行为模拟
很多反爬系统会分析鼠标轨迹、点击节奏这些行为特征。纯粹的无头浏览器很容易被识破。解决方案是引入 humanization-playwright 这类库，模拟贝塞尔曲线的鼠标移动、随机延迟等人类行为。
这三层叠起来，我的采集系统现在已经稳定跑了 3 个月，日均采集超 10 万条数据。
异步改造：从串行到并发
一开始我用的是同步模式，一个一个爬，效率惨不忍睹。后来改成了 asyncio + Playwright 异步模式：
import asyncio
from playwright.async_api import async_playwright
asyncdef fetch_page(url, proxy=None):
asyncwith async_playwright() as p:
browser = await p.chromium.launch(headless=True)
context = await browser.new_context(proxy=proxy)
page = await context.new_page()
await page.goto(url, wait_until='networkidle')
content = await page.content()
await browser.close()
return content
asyncdef main():
urls = ['url1', 'url2', 'url3', ...]
semaphore = asyncio.Semaphore(10) # 限制并发数
asyncdef fetch_with_limit(url):
asyncwith semaphore:
returnawait fetch_page(url)
results = await asyncio.gather(*[fetch_with_limit(url) for url in urls])
# 处理结果...
asyncio.run(main())
注意：并发数不是越大越好。我实测 10 个并发是比较舒服的数字，再高就容易触发反爬或者把机器搞崩。用 asyncio.Semaphore 做限流是基本操作。
这套架构的适用场景
折腾完这套东西之后，我总结了一下它最适合的场景：
-
SPA 单页应用：React/Vue 渲染的页面，requests 完全拿不到数据的那种 -
需要交互操作的采集：要点击、滚动、登录才能看到完整内容的页面 -
高并发的动态渲染需求：纯 Python Playwright 扛不住并发的时候
不适合的场景：静态页面、简单的 API 接口采集——杀鸡用牛刀了，requests 一把梭更高效。
最后说几句
这套架构我从立项到稳定运行大概花了三周时间。最大的感悟是：不要在一个技术栈里死磕，合适的事情交给合适的工具。
Node.js 的 Playwright 管浏览器就是比 Python 版本省资源，这是架构层面的优势，不是写代码能弥补的。Python 做调度和数据处理就是方便，生态丰富。两者结合起来，各取所长。
如果你也在被 SPA 爬虫折磨，或者正愁 Python Playwright 跑不动并发，不妨试试这个思路。
- 点赞
- 收藏
- 关注作者
评论（0）