当业务需要对外大量爬取数据的时候,往往会碰到被目标网站限流或者直接封堵。这时候就要进行层层应对,代码要被改造成模拟人的行为浏览器访问目标网站,这中操作,当需要获取目标网站数据量不大,时间充裕的情况下,足够了。但当我们需要短时间内大并发爬取内容的时候,这只从代码上进行改造往往达不到效果;这个时候就需要进行大量的IP配合。
大量IP架构V1
在各地机房部署ADSL线路,利用定时任务不停调用ADSL重拨,从而刷新IP。
程序任务下载中心把任务程序包下发到各个节点,节点上任务运行爬取数据的工作。
缺点:
由于投入各地的机房,有些甚至私人机房,不太稳定,机器出问题的时候,投入太多人力处理。
ADSL申请监管加大,不好申请。
成本高。
爬取内容增大,这种布线方式不利于扩容。
大量IP架构V2
本版因为考虑到快速扩容引入容器,并搭配K8S进行集群管理。
本版本丢弃ADSL,选用×××进行IP变化,可以是收费×××、免费×××等。
SQUID:用于为服务提供请求代理。
队列:用于接受重连×××指令,重连一次×××则IP会重新更换。
监控程序:1.接受指令,重连×××;2.监控×××网络的连通性,如果掉线则重连。
×××-Client:×××客户端。
任务集群:上面跑着各需求的程序,当需要进行爬取数据时候通过链接squid代理进行对外访问。
实施遇到的一些问题:
容器权限问题
在yaml部署文件中需要为容器提供管理员权限:securityContext: {privileged: true}
内核问题
×××需要一些系统内核支持,所以,需要进行相应挂载。
volumeMounts:
- {mountPath: /lib/modules, name: modules}
通过该命令进行判断:cat /dev/net/tun
返回结果为cat: /dev/net/tun: File descriptor in bad state:就表示该系统支持。
现已跑一段时间,情况稳定。
现情况如下:
并发在线容器:几百+。年内预计会增长到k+
现每天产生IP量:10几w 很轻松。
更多文章,请关注×××公众号:轻量运维。
原文地址:http://blog.51cto.com/qdywsky/2175376