从爬虫到分布式：一个杭州外包仔的技术自救指南
大家好，我是阿杰，坐标杭州未来科技城。白天在一家创业公司做后端，晚上接点外包单子搞副业——说白了就是个斜杠程序员，主业求稳，副业求富（虽然目前还在“求”字阶段）。重度依赖 ChatGPT 和 Claude 写代码，不是因为我懒（好吧，确实有点懒），而是 deadline 压得人喘不过气，能用 AI 提效的绝不手搓。最近半年接了几个数据采集相关的活儿，顺带把分布式系统那套东西啃了一遍，今天就来唠唠这段“技术探索与实践优化”的血泪史。
起因：为了多赚点钱，我接了个“魔鬼”需求
事情要从去年双11前说起。一个老客户（之前帮他做过一个电商后台）突然微信我：“兄弟，能不能搞个爬虫？抓全网的商品价格，每天更新，要快、要稳、别被封。” 我一听，心里咯噔一下——又是爬虫，又是反爬，又是高并发，典型的“既要又要还要”。
但转念一想，这单子报价不错，够我下个月房租+奶茶自由了。于是硬着头皮接了。毕竟在杭州，阿里网易边上混，不搞点高并发、分布式、反反爬，都不好意思说自己是搞技术的。
初版方案：天真如我，以为 requests + BeautifulSoup 就够了
一开始，我直接上手写了最经典的组合拳：
import requests
from bs4 import BeautifulSoup
def scrape(url):
resp = requests.get(url, headers={"User-Agent": "Mozilla/5.0..."})
soup = BeautifulSoup(resp.text, 'html.parser')
return extract_price(soup)
本地跑了几百个 URL，一切正常。测试通过！开心地提交给客户。
结果上线三天，IP 被封了，任务队列积压到爆，服务器 CPU 飙到 90%。客户微信轰炸：“怎么数据没更新？是不是你偷懒了？” 我看着监控面板，内心 OS：我哪是偷懒，我是被反爬机制按在地上摩擦啊！
更惨的是，那周正好我在主业公司赶一个紧急需求，产品经理凌晨两点发钉钉：“这个接口为啥超时？是不是你写的慢查询？” 我一边改 SQL，一边调试爬虫，差点原地去世。
痛定思痛：爬虫不是玩具，是工程
那次翻车让我意识到：爬虫一旦上了规模，就不再是脚本，而是一个完整的数据采集系统。光靠单机 Python 脚本，根本扛不住真实世界的复杂性。
于是我开始系统性地重构，核心目标就三个：
- 抗封：绕过 IP 封禁、验证码、JS 混淆
- 高效：提升吞吐量，降低延迟
- 可维护：任务调度、失败重试、监控告警一个不能少
第一步：代理池 + 动态 User-Agent
先解决最基础的封 IP 问题。我搭了一个简单的代理池服务，用免费代理 + 自建代理混合策略。配合 Redis 做代理健康检查，失效自动剔除。
import redis
import random
r = redis.Redis()
def get_random_proxy():
proxies = r.smembers("valid_proxies")
return random.choice(list(proxies)).decode()
同时，User-Agent 也不能写死。我搞了个 UA 池，每次请求随机换一个，模拟真实用户。
小技巧：别用那些烂大街的 UA 列表，容易被识别。我直接从真实浏览器里扒了一堆，再用 ChatGPT 生成几百个变体，效果出奇的好。
第二步：异步 + 分布式任务队列
同步请求太慢了。我改用 aiohttp + asyncio 实现异步并发，单机 QPS 从 5 提升到 200+。
但还不够。当任务量达到百万级时，单机成了瓶颈。这时候就得上分布式了。
我选了 Celery + Redis 的组合（轻量、熟悉、运维成本低），把 URL 解析、请求、解析、入库拆成多个任务链。每个 worker 节点独立运行，动态扩缩容。
@app.task(bind=True, max_retries=3)
def fetch_page(self, url):
try:
async with aiohttp.ClientSession() as session:
async with session.get(url, proxy=get_proxy()) as resp:
return await resp.text()
except Exception as exc:
self.retry(countdown=60, exc=exc)
这里踩了个大坑：一开始没设重试策略，遇到临时网络抖动直接丢数据。后来加上指数退避重试，成功率直线上升。
第三步：应对 JS 渲染和验证码
有些网站用 React/Vue 动态渲染，直接拿 HTML 根本没数据。还有些站点上了 Cloudflare 或者滑块验证码，requests 直接歇菜。
我试过 Selenium，但太重了，资源消耗大，不适合大规模部署。最后转向 Playwright —— 微软出品，支持无头浏览器、自动等待、截图、甚至拦截请求。
from playwright.async_api import async_playwright
async def scrape_with_js(url):
async with async_playwright() as p:
browser = await p.chromium.launch(headless=True)
page = await browser.new_page()
await page.goto(url)
await page.wait_for_selector(".price") # 等待关键元素加载
price = await page.text_content(".price")
await browser.close()
return price
虽然性能比纯 HTTP 请求差不少，但胜在稳定。我把这类“重型”任务单独分到高配机器上跑，和轻量任务隔离，资源分配更合理。
至于验证码？能绕则绕，绕不过就上打码平台（比如超级鹰）。说实话，这部分成本不低，但客户愿意买单，我也就不纠结了。
求职启示：这些经验居然帮我拿了 offer
说到这儿，可能有人觉得：“你一个接外包的，搞这么复杂干嘛？”
但恰恰是这些实战经验，在我最近跳槽时成了加分项。
上个月我去面了一家阿里系的中台部门，面试官问：“你有没有处理过高并发数据采集的场景？” 我直接掏出这套架构图，从代理轮换讲到任务分片，再到失败回溯机制。面试官眼睛都亮了：“你这比我们实习生做得还细。”
最后 offer 拿下了，薪资涨了 30%。HR 后来私下告诉我，他们最近就在搞一个全域商品监控平台，正缺有爬虫 + 分布式经验的人。
所以别小看外包项目。只要用心做，每一个需求都是简历上的亮点。尤其是爬虫这种“脏活累活”，反而能体现你的工程能力和问题解决思维——毕竟，能在线上稳稳跑几个月不崩的爬虫，比十个玩具 demo 都有说服力。
性能对比：优化前后差距惊人
为了直观展示效果，我整理了关键指标的对比：
| 指标 | 初版（单机同步） | 优化后（分布式异步） |
|---|---|---|
| 日均采集量 | 5,000 条 | 1,200,000 条 |
| 平均响应时间 | 1.2s | 0.15s |
| IP 封禁率 | ~40% | <3% |
| 任务失败率 | 18% | 0.7% |
| 服务器成本 | 1 台 4C8G | 3 台 2C4G（Spot 实例） |
看到没？不仅性能提升了两个数量级，成本还降了。靠的就是合理的架构拆分和资源调度。
血泪教训 & 最佳实践
最后分享几点掏心窝子的经验，都是拿加班和 Bug 换来的：
别信“简单爬一下”
客户说“就抓几个页面”，99% 是谎言。一定要问清楚数据规模、更新频率、目标网站类型。提前评估反爬强度，否则上线即崩。日志和监控是救命稻草
我用 Prometheus + Grafana 监控任务队列长度、失败率、代理可用数。有一次半夜收到告警，发现某电商网站突然加了新验证码，立刻切备用策略，避免了数据断流。法律红线不能碰
虽然技术上能抓，但涉及用户隐私、付费内容、高频攻击的，坚决不碰。我有个原则：只抓公开、可索引、非敏感数据。毕竟副业是为了赚钱，不是进局子。善用 AI，但别全信
ChatGPT 帮我写了 70% 的模板代码，但反爬逻辑、异常处理、性能调优这些，还得自己上。AI 是锤子，你是木匠——工具再好，也得你会用。外包也要写文档
别觉得“反正就我一个人看”。后来客户要交接给他们的开发，我甩出一份清晰的架构说明 + 部署手册，对方直呼专业，还介绍了新客户给我。
结语：技术人的副业，本质是能力变现
写这篇文章的时候，我刚搞定一个新需求——用分布式爬虫监控竞品 App 的应用商店评论。又是一个通宵，但看到数据稳稳入库，心里还是有点小得意。
在杭州这片卷王之地，光靠主业很难快速积累财富。但如果你能把每个外包项目当成练兵场，把爬虫、高并发、分布式这些“硬核技能”真正吃透，副业不仅能赚钱，还能为你的职业发展铺路。
所以，别怕接“脏活”。真正的技术深度，往往藏在那些没人愿意碰的坑里。
下次再有人找你写爬虫，别急着拒绝。先问清楚需求，然后微笑着说：“可以做，不过得按我的架构来。”
毕竟，咱们斜杠程序员，既要代码跑得稳，也要钱包鼓得快，对吧？
作者：阿杰，杭州斜杠程序员，主业后端，副业接单，梦想是早日实现“不加班自由”。欢迎同行交流（但别找我写毕业设计爬虫，真的会谢）。
评论 0