当业务需要大量IP的时候,该如何操作？每天产生IP量：过W,Easy

       当业务需要对外大量爬取数据的时候，往往会碰到被目标网站限流或者直接封堵。这时候就要进行层层应对，代码要被改造成模拟人的行为浏览器访问目标网站，这中操作，当需要获取目标网站数据量不大，时间充裕的情况下，足够了。但当我们需要短时间内大并发爬取内容的时候，这只从代码上进行改造往往达不到效果；这个时候就需要进行大量的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 很轻松。




更多文章请关注微信公众号：轻量运维