还记得我第一次做大规模爬虫项目的时候，用的是一台“肌肉型”的服务器。配置不低，爬个小站点也挺顺溜。但只要遇上流量高峰，几百万的任务排队，机器就跟塞车一样卡死。那时候我才意识到：单机再强，也有极限。

后来我想过加几台机器固定跑，但很快发现——大多数时间根本用不到，CPU 一直 20%-30%，钱花了，机器却在发呆。高峰顶不住，低谷浪费钱，这就是第一个大坑。

瓶颈越来越明显

那段时间，我们的采集项目有几个大问题：

• 任务堆积：高峰时延迟长得离谱，平均一个请求要等 120 秒。
• 失败率高：代理资源堆在一起用，命中率低，经常被封，失败率能到 20%+。
• 成本失控：为了应付高峰，只能加机器，结果每月账单涨得飞快。

说白了，我是在用“笨办法”堆钱解决问题。

转折点：搬上 Kubernetes

有一次，业务又要搞一次“临时大促采集”，流量高得离谱。我盯着服务器的监控图，CPU 飙满，内存溢出，爬虫进程死掉。那一刻我想：不行，必须换个思路。

于是我把爬虫搬上了 Kubernetes，思路就是：

• 用 HPA（Horizontal Pod Autoscaler） 自动伸缩，流量来了就加 Pod，流量走了就缩回去。
• 每个 Pod 配自己的一份 代理池（我用的是 爬虫代理），避免所有实例抢一个代理资源。
• 任务丢进 Redis 队列，Pod 来消费，扩缩容的时候不会丢任务。

这算是我的“第二阶段重构”。

代码片段分享

当时改造后的爬虫核心逻辑很简单：

Python 爬虫（接入代理）

import requests
from lxml import etree

# ====== 亿牛云爬虫代理配置 ======
proxy_host = "proxy.16yun.cn"
proxy_port = "3100"
proxy_user = "16YUN"
proxy_pass = "16IP"

proxy_meta = f"http://{proxy_user}:{proxy_pass}@{proxy_host}:{proxy_port}"

proxies = {
   
    "http": proxy_meta,
    "https": proxy_meta,
}

def fetch_page(url):
    headers = {
   "User-Agent": "Mozilla/5.0 (K8s-Crawler/1.0)"}
    resp = requests.get(url, headers=headers, proxies=proxies, timeout=10)
    html = etree.HTML(resp.text)
    title = html.xpath("//title/text()")
    return title[0] if title else "N/A"

if __name__ == "__main__":
    print("抓取结果：", fetch_page("https://example.com"))

Kubernetes 部署 + HPA

apiVersion: apps/v1
kind: Deployment
metadata:
  name: crawler-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: crawler
  template:
    metadata:
      labels:
        app: crawler
    spec:
      containers:
      - name: crawler
        image: myregistry/crawler:latest   # 打包好的爬虫镜像
        resources:
          requests:
            cpu: "200m"
            memory: "256Mi"
          limits:
            cpu: "500m"
            memory: "512Mi"
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: crawler-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: crawler-deployment
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60

这个配置让爬虫变得“聪明”了：CPU 高到 60% 时，K8s 自动拉 Pod；任务量下去，Pod 会缩回去。

压测的惊喜

我跑了一次 1000 并发 URL 压测，结果让我很惊讶：

那种感觉就像：以前开的是一辆小货车，载重一超就趴窝；现在换成自动调度的货运车队，来了多少货就派多少车。

最终的收获

经过这次改造，我学到了三点：

1. 性能不只是多加机器，关键在于弹性和调度。
2. 代理隔离很重要，不然再好的集群也会被封杀拖垮。
3. 成本可控才是关键，K8s 让我月账单省了 30% 以上。

对比一开始那台“肌肉单机”，现在的架构更像是一个会自动呼吸的系统，高峰不慌，低谷不浪费。

回头看，这就是爬虫项目的进化史：
单机 → 固定集群 → Kubernetes 弹性集群。

每一步都有坑，但每一步也让系统更稳、更快、更省钱。