爬蟲技術(二)－客戶端爬蟲

在上一篇文章《一篇文章瞭解爬蟲技術現狀》中，咱們總結了目先後臺爬蟲所面臨的交互困難、javascript解析麻煩、以及ip限制三大問題。本期，咱們不妨換一種思路來從新思考，說不定會別開生面、柳暗花明。

承上

書接上文，咱們說明了目先後臺爬蟲所面臨的三大問題，此三點對於後臺爬蟲來講基本條條都是硬傷，固然，如今有些網站安全性考慮的不夠，安全策略並不是太過複雜，在有些場景下，對後端爬蟲來講不至於會致命，可是，一旦有個新的需求遇到了這三座大山的其中一個，那將會是很麻煩的一件事。既然如此，在窮途陌路的時候，咱們何不換個思路？

山重水複疑無路，柳暗花明又一村，千呼萬喚始出來，驀然回首，猶抱琵琶半遮面！

障礙，不必定非得正面跨過去，有時候，繞過去會更容易。

再思

遇到交互困難的場景有哪些？

上文中咱們提到，後臺爬蟲說面臨的第一座大山就是交互困難。可是，不是全部的網頁都會有複雜的交互，其實，和爬蟲(會對爬取結果產生重要影響)相關90%的網頁交互都是驗證碼！而這些驗證碼一般都在登陸頁。好比咱們要爬取某人的全部微博評論、qq空間留言、郵件列表等等。對於這些場景，咱們爬蟲必需要進行登陸，不然沒法獲取內容。而對於搜索引擎的爬蟲來講，這些內容是沒有必要的，百度谷歌不可能取爬取用戶這些信息。也就是說，不管是在怎樣的需求場景下，咱們遇到這種交互問題以前，都是都是須要用戶告訴咱們用戶明和密碼，而後咱們再去爬，而後才能遇到驗證碼問題。因此，這種需求場景必然有個用戶受權／登陸的過程，那麼在大家的產品當中，通常的交互會是這樣：產品中會提供一個讓用戶受權／登陸頁面，用戶受權／登陸後，將帳戶信息加密發送到後臺，後臺拿到帳戶信息後，啓動爬蟲去嘗試登陸，若是遇到驗證碼，後臺再返回給端上，由用戶手動完成，而後後臺獲取到用戶輸入的驗證碼（能夠是一組操做值），再繼續進行登陸驗證，這樣才能完成整個流程，你們想一想12306的搶票軟件的流程，正是如此。可見這樣的產品交互是很複雜的。好了，咱們總結一下，遇到這種狀況的本質緣由是爬蟲在執行過程當中須要用戶經過端（app或網頁）進行手動受權，而受權的過程須要端和後臺一次或屢次交互。

如何才能突破ip限制？

其實，這是最容易得出結論的一個問題，咱們稍加思考，就會意識到，只要爬取是在後臺進行，那麼ip就永遠有限，這個問題就不可能完全解決！

行文至此，今天要介紹的主角已經呼之欲出了，想必你也已經猜到了。在揭開它面紗以前咱們先來看看近幾年業務需求發生的變化。

新的需求場景

衆所周知，近年來隨着P2P的快速發展，互聯網金融更是處於風口浪尖，這個萬億級的市場，吸引了一大批公司，像螞蟻金服、陸金所、愛錢進、理財通、百度金融等等。而互聯網金融的本質主要是風險控制、因此一個強大徵信平臺相當重要。從業務角度來看，互聯網金融公司通常都會分爲兩塊：資產端和資金端，也就是貸款方和投資方，而這裏最具風險的就是對貸款方的資質審覈，這和傳統的金融沒什麼區別，而所謂互聯網金融，無非是將認證流程提到了線上，借款時經過相應平臺的的app完成。而認證流程每每須要獲取用戶信息，如信用卡代還的借款須要爬取用戶信用卡帳單郵箱、通話記錄，有的甚至要爬支付寶交易記錄、京東淘寶購買記錄等等，這些都是須要用戶受權／登陸的，而這些網站一般爲了安全期間，對ip請求的次數、頻率都有着嚴格的限制，這致使傳統的後臺爬蟲不能勝任，此時急需一種新的解決方案。

客戶端爬取方案

通過以前的諸多鋪墊，換個思路想一想，若是能在用戶端完成數據獲取，像後臺爬蟲面臨的三座大山還會存在嗎？對於ip限制，因爲數據獲取是在用戶端完成的，咱們每個用戶的ip能夠大體認爲是不一樣的，那麼ip限制則不攻自破；對於動態驗證，須要爬取用戶登陸後的信息時，咱們確定須要用戶受權，因此對於驗證碼，咱們能夠引導用戶本身操做，而無需和後臺進行交互；而對於javascript解析的問題，若是爬取是在客戶端進行，那麼咱們可否引入瀏覽器的javascript虛擬機呢？可不能夠用v8? 若是能夠，那麼咱們的爬取腳本是否是也能用javascript去寫？若是能夠，那麼咱們的爬取腳本中是否是能夠用jQuery解析網頁，直接發起ajax請求？若是能夠，那怎一個爽字了得，不可能有比這更容易的寫的爬蟲了！今後，javascript真的要一統天下了呀，好可怕。。。

換個行！咱們平復一下激動的心情！

好，咱們回過頭來看一下，若是採用客戶端方案，以前後臺遇到到的三大問題是否均可以解決。

1. 交互複雜；客戶端爬取是在端上進行，無需再和後臺交互，用戶登陸成功後再爬取，最終只須要將爬取的數據上報給後臺就行。
2. Javascript解析問題；若是爬取是在端上，因此沒有後臺高併發吞資源的狀況，咱們徹底能夠引入和瀏覽器同樣的javascript運行環境。
3. ip限制問題；完全解決了！

客戶端爬取方案可能遇到的問題

事無鉅細，咱們先關注如下幾點：

1. 腳本放在哪

   傳統後臺爬取的程序是在後臺，若是目標網站發生變化，能夠隨時更新爬取程序。但客戶端爬取將會有問題，爬取腳本保存在客戶端，那麼就麻煩了。看來腳本是不能保存在端上，那麼必須有一套腳本下發、更新的機制。

2. 如何進行錯誤收集

   若是目標網站發生變化致使咱們腳本不能正常工做或拋出異常，若是是在後臺，咱們能夠有服務器打點、報警等及時發現處理，若是在端上咱們應該如何及時應對錯誤？

3. 如何進行版本管理

   版本管理分爲爬取腳本版本和sdk版本，腳本支持的sdk版本範圍如何匹配？

4. 怎麼寫腳本

   用什麼語言？如何控制爬取流程？如何和端通訊？

完整的客戶端爬取平臺

綜上所述，下面，咱們想一想，一個完整、友好的、理想的的客戶端爬取平臺應該是什麼樣子的。

1. 跨平臺；在移動互聯網時代，最起碼支持ios/android.
2. 雲管理平臺；主要用於配置腳本參數、更新腳本、統計腳本爬取狀態、錯誤分析等。若是你是開發者，那麼雲管理平臺同時也是發佈、管理本身腳本的地方。
3. 爬取腳本使用javascript語言；一來前端程序員能夠很快上手，二來，javascript天生和網頁更配。這樣會下降開發難度和成本，學習成本很低。
4. 腳本商店；互聯網上的網頁浩如煙海，開發者能夠有償或無償的把本身的腳本發佈到腳本商店，供其它人使用、共享。

最後

本文本想打算直接介紹客戶端爬取平臺，但我以爲在介紹新的事物以前應該要弄明白緣起，只有瞭解了它的誕生環境，才能更好的理解它的價值。下一篇咱們將隆重介紹全球第一個開放的客戶端爬取平臺。如依然有興趣，敬請關注。

本文章容許免費轉載，但請註明原做者及原文連接。