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