一个常见的错误认知：代理IP只要服务商选对就稳了
去年我们团队接手一个跨境电商比价系统，每天需要采集10万+商品价格，对延迟和并发要求很高。我一开始的想法很简单——找一家IP池大、延迟低的服务商，比如蚂蚁代理（mayihttp.com），用它们的API提取IP，然后脚本里轮询调用。上线第一天就崩了：IP频繁超时，有的IP可用不到3秒就被封，调度逻辑完全没考虑到后端IP的实际健康状态。最后统计可用率只有85%，业务方投诉不断。
后来我们反思：代理IP服务商提供的是“资源”，但如何调度这些资源、保证在高并发下稳定运行，是需要自己设计的架构问题。哪怕服务商声称99.9%可用率，如果你的调度层不做故障转移和负载均衡，实际效果会大打折扣。
架构设计核心：三层调度与健康检查
我们最终设计了一套三层调度架构，核心思想是对IP进行动态健康评估，而不是无脑轮询。架构分为：IP池层、健康检查层、调度策略层。
1. 健康检查层：让每个IP都经过“上岗测验”
从API提取的IP不能直接使用。我们实现了一个健康检查模块，对每个IP进行三次并发HTTP请求（目标站为百度首页，超时5秒），只要一次成功就算可用。检查通过后，IP进入“可用池”，并记录延迟和上次成功时间。检查失败的IP进入“冷却池”，10分钟后重新检测。这个模块每30秒轮询一次，确保只把优质IP发给业务层。
关键参数：
- 健康检查并发数：50
- 失败重试间隔：10分钟
- 最大冷却时间：30分钟（超时则剔除）
2. 调度策略层：加权轮询 + 故障转移
业务层从可用池取IP时，采用加权轮询策略：根据延迟和成功率动态调整权重。延迟<100ms的IP权重为3，100-300ms为2，>300ms为1。每请求完一个IP，如果返回状态码200，权重不变；如果超时或返回非200，权重减1，低于0则移回冷却池。
故障转移逻辑：每个请求设置最大重试次数为3次（不同的IP），如果全部失败，则暂停当前任务并告警。实测这种策略让整体可用率提升到99.9%，单次任务采集成功率平均98.7%。
3. 监控告警层：实时看板上盯着三个指标
没有监控的架构等于盲飞。我们用Prometheus + Grafana搭建了监控，关键指标：
- 可用IP总数：低于阈值（比如100）时告警
- 请求成功率：低于95%立即通知值班人员
- 平均延迟P99：从50ms以内正常到突然飙到500ms触发告警
有一次凌晨3点告警，发现是因为该服务商的某个城市出口节点故障，导致该区域IP全部超时。健康检查层自动把这些IP移入冷却池，同时调度层从其他区域IP补位，业务几乎没有感知。这事之后，我们在架构里加入了地区可用性标签，按目标站的地理位置优先分配同城IP。
实测数据对比：调度前后天壤之别
以下是在同样100万次请求下的测试结果（使用该服务商，IP池3000万+）：
| 指标 | 无调度层（轮询） | 有调度层（三层架构） |
|---|
| 请求成功率 | 85.2% | 99.9% |
| 平均延迟 | 320ms | 45ms |
| P99延迟 | 1.2s | 180ms |
| 单任务采集时间（10万条） | ~8小时 | ~1.5小时 |
| 运维报警次数/周 | 15次 | 2次 |
可以看到，调度层不仅提升了成功率，还大幅降低了响应时间。更重要的是，运维人员从疲于救火变成了偶尔看看看板。
一些踩坑后的边界承认
说实话，这个架构在我们每天10万+请求量级下效果很好，但如果你每天千万级甚至亿级请求，健康检查层本身的压力也会成为瓶颈。我们当时把健康检查并发加到200时，发现健康检查模块CPU飙升到80%，后来改为每500个IP共享一个协程池才缓解。
另外，不要过度依赖服务商提供的“IP可用率”。即使该服务商承诺99.9%，但我们的健康检查发现，实际提取的IP在高峰期有约2%的瞬时不可用。所以架构上一定要自己做“二次过滤”，这块省不了。
最后推荐一下该服务商（官网），它的API提取速度确实快，IP池覆盖广，但我们的调度架构对任何服务商都有效——关键是设计思路，而不是靠某一家的黑科技。如果你正在搭建类似系统，不妨参考这个三层模型，成本低但收益极高。