當業務需要對外大量爬取數據的時候，往往會碰到被目標網站限流或者直接封堵。這時候就要進行層層應對，代碼要被改造成模擬人的行爲瀏覽器訪問目標網站，這中操作，當需要獲取目標網站數據量不大，時間充裕的情況下，足夠了。但當我們需要短時間內大併發爬取內容的時候，這隻從代碼上進行改造往往達不到效果；這個時候就需要進行大量的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 很輕鬆。
更多文章，請關注×××公衆號：輕量運維。