如何用最小的代價完成爬蟲需求
一 緣起
在我工作的多家公司，有眾多的領域，如房產，電商，廣告等領域。盡管業務相差很大，但都涉及到爬蟲領域。開發爬蟲項目多了后，自然而然的會面對一個問題——
l 這些開發的爬蟲項目有通用性嗎？
l 有沒有可能花費較小的代價完成一個新的爬蟲需求？
l 在維護運營過程中，是否能夠工具化，構建基于配置化的分布式爬蟲應用？
這就是是我們今天要討論的話題。
二 項目需求
立項之初，我們從使用的腳度試著提幾個需求。
1. 分布式抓取
由于抓取量可能非常龐大，一臺機器不足以處理百萬以上的抓取任務，因此分布式爬蟲應用是首當其沖要面對并解決的問題。
2. 模塊化，輕量
我們將爬蟲應用分成“應用層，服務層，業務處理層，調度層” 四個腳色。
3. 可管理，可監控
管理監控是一個體系，即配置可管理化，運行實時監控化。在系統正常運行時，可以變更爬蟲的配置，一旦實時監控爬蟲出現異常，可實時修正配置進行干預。所有的一切，均可以通過 UI 界面進行操作。
4. 通用性，可擴展。
爬蟲業務往往多變，不同領域的爬取需求不盡相同。舉例說，房源抓取包含圖片抓取，小區信息抓取，房源去重等模塊。新聞抓取包括內容抓取，正文提取，信息摘要等相關。
因此，系統需要能夠支持業務擴展需求，可以支持不同的業務使用同一套框架進行應用開發。
三 模塊分解
針對業務需求，我們將系統分解成多個應用模塊。
應用層
應用層是針對管理員，系統維護人員使用。主要分成兩個模塊，系統配置模塊和運營管理模塊。
l 系統配置模塊：系統配置模塊包含抓取網站管理配置，在線測試等功能。
l 運營管理模塊：運營管理模塊包含實時抓取量統計，分析，正確率等。甚至包括失敗原因，失敗量。
系統運營人員可以根據運營模塊得到實時的反饋，使用系統配置模塊進行配置修正，在線測試正確后將配置生效，再實時監控新的配置產生的效果。
服務層
服務層是整個系統傳輸的中樞，相當于整個分布式集中的系統總線和數據總線。服務層提供一個 http/thrift 接口，讀取數據庫，輸出配置信息。
a. 提供網站爬蟲配置接口。從數據庫中實時讀取配置信息，響應業務層的配置請求。
b. 提供業務層輸出寫入接口。接受業務層實時爬取的信息匯總，包括正確數據量，錯誤數據量，以及錯誤原因。
c. 提供實時報表統計分析。響應應用層的運營管理模塊，查詢數據庫，實時提供數據分析報告。
業務處理層
業務處理層是整個爬蟲系統的核心，可分成多臺應用服務器進行處理。業務處理層主要包含解決兩件事情。
l 如何獲取 url
l 得到 url 后，如何處理
（一） 如何獲取 url
對于爬蟲來說，如何獲取 url 至關重要。我們將這一過程定義為發現系統。對于發現系統而言，目標為如何發現待抓取網站的詳細 url 列表，盡可能的發現更全。
假設場景 A
我們逛一個電商網站：打開首頁-打開分類頁-可能會有多層分類頁-逐層點擊-直至最小的分類頁面。
打開這個分類頁會發現該分類頁下的所有分頁頁面，一頁一頁往下翻，就能夠獲得該分類頁的所有商品。
假設場景 B
我們逛一個汽車網站：打開首頁-找到品牌頁-接著找到車系-最后找到車款頁面。
通過以上場景分析可以得到一個結論，人能非常智能的找到所有待抓取的詳細頁面，即電商的商品，汽車的車款頁面。那么，是否可以通過配置方式來模擬這一過程呢？
請看下圖：
備注如下：
1. root_info：
定義發現模塊的入口頁面，如同人打開汽車站的網頁，后續的發現都是起始于這些入口頁。
這里給出的實例是，某汽車網的品牌列表頁，根據“模板化”套用變量的配置，共有 100 個入口頁。
2. steps:
依次遍歷這 100 個入口頁，分別會執行 steps 中定義的步驟。機器模擬人的方式進行查看瀏覽。
每個 step 中，會使用”link_module”定義的類進行邏輯進行處理。
a. 讀取入口頁的 html，結合”sub_prefix”，”sub_suffix”和”select”定義的內容，獲得頁面子區域 html。
b. 使用”link_match_method”的方法（含前綴包含，匹配等），抽取子區域的鏈接。
c. 每個鏈接和”link_pattern”進行匹配，匹配成功的 url 進入下一步。
d. 每一步得到的 url，自動進和地下一步處理，處理邏輯為遞歸上面a-c，直至”last_step”為 true 為止。
此處，即”last_step”為 true 中發現的 url，即為發現系統最終需要獲取的 url 列表。發現系統總結，通過配置的方式，結合人類的瀏覽習慣，通過若干步迭代，最終獲取網站的詳細頁 url 列表。
由于每一步的抽取鏈接規則，以及步數據都是人為定義，因此，可以適配絕大部分網站的發現系統。當然，越復雜的網站發現配置可能更多一些、更為繁雜，但萬變不離其宗。
（二）得到 url 后，如何處理
前提當然是每個業務的處理各不相同，有抽取頁面屬性功能、有正文提取、有圖片獲取，甚至有和當前系統對接等。
由于業務處理不一致，很自然想到的是通過配置方式，定義職責鏈系統，如同著名框架 Netty 中的 Pipeline 設計。在處理過程中，定義一個 Context 上下文處理類，并且，所有的中間結果都暫緩在這個 Context 中。
描述比較空洞，還是結合實際案例來看。
備注如下：
得到一個 url 后，讀取配置，當 url 和”site”匹配時，適用當前”site”規則。
1. pipeline 定義職責鏈的處理過程
此處的定義為“抓取模塊，Javascript 處理模塊，通用解析模塊”。對應的處理如下：
先執行抓取模塊，得到 html。緊接著執行 Javascript 處理模塊，輸入為 html，解析 html，此處可能是評論，也可能是價格，總之處理的是動態加載項目，緊接著處理“通用解析模塊”
2. ”parser_rules”定義的是解析模塊
最終輸出的是 kv，在 java 中是 map，python 中是 dict。即從上一步的 html 中，找到每一薦的”sizzle”，執行”prefix”，”suffix”即前后綴移除(過濾如同“價格：xxx 元，前綴為“價格:”，后綴為元)。
對了，sizzle 也是一個開源技術，據說以前鼎鼎有名的 Jquery 也是”sizzle”引擎。Java 中可以使用 Jsoup 解析處理。
怎么知道需要取的”sizzle”內容是什么呢？具體可以結合 firebug 插件，選中即可得。選中后，結合應用層的管理工具，即可進行測試。
3. “isrequire”
可以看到，配置項中有“isrequire”，表示這項內容是否必須。如果必須，且在實際處理中獲取不到，那么在抓取的過程中，就會記錄一個錯誤， 錯誤原因自然是“$key is null”。此外，每一個 module 都可能出錯，一旦出錯，就沒有必要往后去執行。
因此，在抓取過程中，業務處理層從服務層獲得一批 url (默認 100 個）后，在處理這一百個 url 結束后，會向服層 report，report 內容為：
當前任務處理機器，于什么時間處理 100 個頁面。不同網站成功多少、失敗多少、什么模塊失敗多少，解析模塊什么字段失敗多少。
所有這些信息，均是實時統計，并在運營監控系統中以圖表形示繪制出來，必要時可以發出報警，交由維護人員實時干預。
Q: 提一個問題，新增一個 anotherauto.com 網站怎么辦？
A: 其實也很簡單，再增加一個配置唄。業務定義 pipeline，如果有解析需求，填寫對應的解析項即可。
以上兩個系統，發現系統和處理系統，在我們實際生產中，是通過以下步驟貫穿。
a. 發現系統累計發現待抓取網站的詳細頁，因為是一個累計持續的過程。因此有把握持續無限接近網站的 100% 頁面。
b. 處理系統通過服務層，每次去取配置信息（可能維護人員在實時修正）及待抓取的列表進行處理。
待抓取的列表根據業務的優先級，分普通隊列及優先級隊列，通過任務調度系統進行統一管理和配置。
調度層
l 調度層主要是業務系統。
l 新增一個網站任務調度
l 網站發現頻率，包括增量發現頻率和全量發現頻率
l 網站抓取優先級推送至隊列
l 斷點續抓管理
l ……
四 系統架構設計
l 從業務模塊上看
應用層，服務層，業務處理層，調度層
l 從功能系統上看
發現系統，抓取系統， 配置系統，監控系統
l 從擴展性上看
自定義職責鏈，自定義屬性提取
l 從實時性上看
實時抓取，實時配置生效，實時監控，實時測試
l 從系統架構上看
分布式架構，服務層主從切換設計，輕量（僅依賴于隊列，數據庫，java)
五 圖例
①
②
③
爬蟲模塊 ui 二 (1.6 任務配置) ：
定義每個爬蟲任務的處理執行職責鏈，不同的爬蟲任務可以有不同的處理鏈。對于系統而言，處理每一個待爬取的 url，都會按照職責鏈的順序執行。后置處理類則是一批任務執行后（如上文的 100 個 url)，批量提交的方式。如文件落地，入庫，推往線上系統等。通過任務處理定義，則可以自定義各類不同場景的爬蟲業務，在不編碼的前提下增加系統的靈活性。
④ ?
屬性配置：
如圖所示，維護人員增加條測試的 url，同時定義需要提取的屬性，則可在線定義該頁面對應的屬性輸出，可見即可得。 在增加便利性，可測試性的基礎上，又能靈活的選取頁面的任意屬性，值得一提的是，可以通過 firefox 插件獲取 sizzle 的配置。
⑤
1. 9 查看明細：
在爬蟲系統的運行過程中，幾乎可以實時的進行任務的監控。由于爬蟲任務實時將爬取的狀態寫入數據庫，因此完全可以通過 ui 界面進行管理及監控。1. 監控：監控爬蟲任務當前時間成功次數，錯誤次數，什么模塊錯誤，甚至某個屬性提取錯誤。2. 管理：維護人員觀測監控效果后，可實時進行編輯及管理（見上一張圖），以應對不同網站的改版需求。所有編輯實時生效，編輯完成后，無需重啟服務，又可實時監控爬蟲任務的最新效果。
踏浪無痕 豈安科技高級架構師
十余年數據研發經驗，擅長數據處理領域工作，如爬蟲、搜索引擎、大數據應用高并發等。擔任過架構師，研發經理等崗位。曾主導開發過大型爬蟲，搜索引擎及大數據廣告 DMP 系統目前負責豈安科技數據平臺開發與搭建。
*本文作者：豈安科技，轉載請注明來自 Freebuf.COM
來自: www.freebuf.com