在上一篇文章《一篇文章了解爬蟲技術現狀》中，我們總結了目前后臺爬蟲所面臨的交互困難、javascript解析麻煩、以及ip限制三大問題。本期，我們不妨換一種思路來重新思考，說不定會別開生面、柳暗花明。
承上
書接上文，我們說明了目前后臺爬蟲所面臨的三大問題，此三點對于后臺爬蟲來說基本條條都是硬傷，當然，現在有些網站安全性考慮的不夠，安全策略并非太過復雜，在有些場景下，對后端爬蟲來說不至于會致命，但是，一旦有個新的需求遇到了這三座大山的其中一個，那將會是很麻煩的一件事。既然如此，在窮途陌路的時候，我們何不換個思路？
山重水復疑無路，柳暗花明又一村，千呼萬喚始出來，驀然回首，猶抱琵琶半遮面！
障礙，不一定非得正面跨過去，有時候，繞過去會更容易。
再思
遇到交互困難的場景有哪些？
上文中我們提到，后臺爬蟲說面臨的第一座大山就是交互困難。但是，不是所有的網頁都會有復雜的交互，其實，和爬蟲(會對爬取結果產生重要影響)相關90%的網頁交互都是驗證碼！而這些驗證碼通常都在登錄頁。比如我們要爬取某人的所有微博評論、qq空間留言、郵件列表等等。對于這些場景，我們爬蟲必須要進行登錄，否則無法獲取內容。而對于搜索引擎的爬蟲來說，這些內容是沒有必要的，百度谷歌不可能取爬取用戶這些信息。也就是說，無論是在怎樣的需求場景下，我們遇到這種交互問題之前，都是都是需要用戶告訴我們用戶明和密碼，然后我們再去爬，然后才能遇到驗證碼問題。所以，這種需求場景必然有個用戶授權／登錄的過程，那么在你們的產品當中，一般的交互會是這樣：產品中會提供一個讓用戶授權／登錄頁面，用戶授權／登錄后，將賬戶信息加密發送到后臺，后臺拿到賬戶信息后，啟動爬蟲去嘗試登錄，如果遇到驗證碼，后臺再返回給端上，由用戶手動完成，然后后臺獲取到用戶輸入的驗證碼（可以是一組操作值），再繼續進行登錄驗證，這樣才能完成整個流程，大家想想12306的搶票軟件的流程，正是如此?？梢娺@樣的產品交互是很復雜的。好了，我們總結一下，遇到這種情況的本質原因是爬蟲在執行過程中需要用戶通過端（app或網頁）進行手動授權，而授權的過程需要端和后臺一次或多次交互。
如何才能突破ip限制？
其實，這是最容易得出結論的一個問題，我們稍加思考，就會意識到，只要爬取是在后臺進行，那么ip就永遠有限，這個問題就不可能徹底解決！
行文至此，今天要介紹的主角已經呼之欲出了，想必你也已經猜到了。在揭開它面紗之前我們先來看看近幾年業務需求發生的變化。
新的需求場景
眾所周知，近年來隨著P2P的快速發展，互聯網金融更是處于風口浪尖，這個萬億級的市場，吸引了一大批公司，像螞蟻金服、陸金所、愛錢進、理財通、百度金融等等。而互聯網金融的本質主要是風險控制、所以一個強大征信平臺至關重要。從業務角度來看，互聯網金融公司一般都會分為兩塊：資產端和資金端，也就是貸款方和投資方，而這里最具風險的就是對貸款方的資質審核，這和傳統的金融沒什么區別，而所謂互聯網金融，無非是將認證流程提到了線上，借款時通過相應平臺的的app完成。而認證流程往往需要獲取用戶信息，如信用卡代還的借款需要爬取用戶信用卡賬單郵箱、通話記錄，有的甚至要爬支付寶交易記錄、京東淘寶購買記錄等等，這些都是需要用戶授權／登錄的，而這些網站通常為了安全期間，對ip請求的次數、頻率都有著嚴格的限制，這導致傳統的后臺爬蟲不能勝任，此時急需一種新的解決方案。
客戶端爬取方案
經過之前的諸多鋪墊，換個思路想想，如果能在用戶端完成數據獲取，像后臺爬蟲面臨的三座大山還會存在嗎？對于ip限制，由于數據獲取是在用戶端完成的，我們每一個用戶的ip可以大致認為是不同的，那么ip限制則不攻自破；對于動態驗證，需要爬取用戶登錄后的信息時，我們肯定需要用戶授權，所以對于驗證碼，我們可以引導用戶自己操作，而無需和后臺進行交互；而對于javascript解析的問題，如果爬取是在客戶端進行，那么我們能否引入瀏覽器的javascript虛擬機呢？可不可以用v8? 如果可以，那么我們的爬取腳本是不是也能用javascript去寫？如果可以，那么我們的爬取腳本中是不是可以用jQuery解析網頁，直接發起ajax請求？如果可以，那怎一個爽字了得，不可能有比這更容易的寫的爬蟲了！從此，javascript真的要一統天下了呀，好可怕。。。
換個行！我們平復一下激動的心情！
好，我們回過頭來看一下，如果采用客戶端方案，之前后臺遇到到的三大問題是否都可以解決。
- 交互復雜；客戶端爬取是在端上進行，無需再和后臺交互，用戶登錄成功后再爬取，最終只需要將爬取的數據上報給后臺就行。
- Javascript解析問題；如果爬取是在端上，所以沒有后臺高并發吞資源的情況，我們完全可以引入和瀏覽器一樣的javascript運行環境。
- ip限制問題；徹底解決了！
客戶端爬取方案可能遇到的問題
事無巨細，我們先關注以下幾點：
-
腳本放在哪
傳統后臺爬取的程序是在后臺，如果目標網站發生變化，可以隨時更新爬取程序。但客戶端爬取將會有問題，爬取腳本保存在客戶端，那么就麻煩了。看來腳本是不能保存在端上，那么必須有一套腳本下發、更新的機制。
-
如何進行錯誤收集
如果目標網站發生變化導致我們腳本不能正常工作或拋出異常，如果是在后臺，我們可以有服務器打點、報警等及時發現處理，如果在端上我們應該如何及時應對錯誤？
-
如何進行版本管理
版本管理分為爬取腳本版本和sdk版本，腳本支持的sdk版本范圍如何匹配？
-
怎么寫腳本
用什么語言？如何控制爬取流程？如何和端通信？
完整的客戶端爬取平臺
綜上所述，下面，我們想想，一個完整、友好的、理想的的客戶端爬取平臺應該是什么樣子的。
- 跨平臺；在移動互聯網時代，最起碼支持ios/android.
- 云管理平臺；主要用于配置腳本參數、更新腳本、統計腳本爬取狀態、錯誤分析等。如果你是開發者，那么云管理平臺同時也是發布、管理自己腳本的地方。
- 爬取腳本使用javascript語言；一來前端程序員可以很快上手，二來，javascript天生和網頁更配。這樣會降低開發難度和成本，學習成本很低。
- 腳本商店；互聯網上的網頁浩如煙海，開發者可以有償或無償的把自己的腳本發布到腳本商店，供其它人使用、共享。
最后
本文本想打算直接介紹客戶端爬取平臺，但我覺得在介紹新的事物之前應該要弄明白緣起，只有了解了它的誕生環境，才能更好的理解它的價值。下一篇我們將隆重介紹全球第一個開放的客戶端爬取平臺。，如依然有興趣，敬請關注。
本文章允許免費轉載，但請注明原作者及原文鏈接。
