[[186419]]

一、緣起

在我工作的多家公司，有眾多的領(lǐng)域，如房產(chǎn)，電商，廣告等領(lǐng)域。盡管業(yè)務(wù)相差很大，但都涉及到爬蟲領(lǐng)域。開發(fā)爬蟲項目多了后，自然而然的會面對一個問題——

• 這些開發(fā)的爬蟲項目有通用性嗎?
• 有沒有可能花費較小的代價完成一個新的爬蟲需求?
• 在維護(hù)運營過程中，是否能夠工具化，構(gòu)建基于配置化的分布式爬蟲應(yīng)用?

這就是是我們今天要討論的話題。

二、項目需求

立項之初，我們從使用的腳度試著提幾個需求。

1. 分布式抓取

由于抓取量可能非常龐大，一臺機器不足以處理百萬以上的抓取任務(wù)，因此分布式爬蟲應(yīng)用是首當(dāng)其沖要面對并解決的問題。

2. 模塊化，輕量

我們將爬蟲應(yīng)用分成“應(yīng)用層，服務(wù)層，業(yè)務(wù)處理層，調(diào)度層” 四個腳色。

3. 可管理，可監(jiān)控

管理監(jiān)控是一個體系，即配置可管理化，運行實時監(jiān)控化。在系統(tǒng)正常運行時，可以變更爬蟲的配置，一旦實時監(jiān)控爬蟲出現(xiàn)異常，可實時修正配置進(jìn)行干預(yù)。所有的一切，均可以通過UI界面進(jìn)行操作。

4. 通用性，可擴展。

爬蟲業(yè)務(wù)往往多變，不同領(lǐng)域的爬取需求不盡相同。舉例說，房源抓取包含圖片抓取，小區(qū)信息抓取，房源去重等模塊。新聞抓取包括內(nèi)容抓取，正文提取，信息摘要等相關(guān)。

因此，系統(tǒng)需要能夠支持業(yè)務(wù)擴展需求，可以支持不同的業(yè)務(wù)使用同一套框架進(jìn)行應(yīng)用開發(fā)。

三 模塊分解

針對業(yè)務(wù)需求，我們將系統(tǒng)分解成多個應(yīng)用模塊。

1. 應(yīng)用層

應(yīng)用層是針對管理員，系統(tǒng)維護(hù)人員使用。主要分成兩個模塊，系統(tǒng)配置模塊和運營管理模塊。

• 系統(tǒng)配置模塊：系統(tǒng)配置模塊包含抓取網(wǎng)站管理配置，在線測試等功能。
• 運營管理模塊：運營管理模塊包含實時抓取量統(tǒng)計，分析，正確率等。甚至包括失敗原因，失敗量。

系統(tǒng)運營人員可以根據(jù)運營模塊得到實時的反饋，使用系統(tǒng)配置模塊進(jìn)行配置修正，在線測試正確后將配置生效，再實時監(jiān)控新的配置產(chǎn)生的效果。

2. 服務(wù)層

服務(wù)層是整個系統(tǒng)傳輸?shù)闹袠校喈?dāng)于整個分布式集中的系統(tǒng)總線和數(shù)據(jù)總線。服務(wù)層提供一個http/thrift接口，讀取數(shù)據(jù)庫，輸出配置信息。

• 提供網(wǎng)站爬蟲配置接口。從數(shù)據(jù)庫中實時讀取配置信息，響應(yīng)業(yè)務(wù)層的配置請求。
• 提供業(yè)務(wù)層輸出寫入接口。接受業(yè)務(wù)層實時爬取的信息匯總，包括正確數(shù)據(jù)量，錯誤數(shù)據(jù)量，以及錯誤原因。
• 提供實時報表統(tǒng)計分析。響應(yīng)應(yīng)用層的運營管理模塊，查詢數(shù)據(jù)庫，實時提供數(shù)據(jù)分析報告。

3. 業(yè)務(wù)處理層

業(yè)務(wù)處理層是整個爬蟲系統(tǒng)的核心，可分成多臺應(yīng)用服務(wù)器進(jìn)行處理。業(yè)務(wù)處理層主要包含解決兩件事情。

• 如何獲取url
• 得到url后，如何處理

（1） 如何獲取url

對于爬蟲來說，如何獲取url至關(guān)重要。我們將這一過程定義為發(fā)現(xiàn)系統(tǒng)。對于發(fā)現(xiàn)系統(tǒng)而言，目標(biāo)為如何發(fā)現(xiàn)待抓取網(wǎng)站的詳細(xì)url列表，盡可能的發(fā)現(xiàn)更全。

a 假設(shè)場景 A

我們逛一個電商網(wǎng)站：打開首頁-打開分類頁-可能會有多層分類頁-逐層點擊-直至最小的分類頁面。

打開這個分類頁會發(fā)現(xiàn)該分類頁下的所有分頁頁面，一頁一頁往下翻，就能夠獲得該分類頁的所有商品。

b 假設(shè)場景 B

我們逛一個汽車網(wǎng)站：打開首頁-找到品牌頁-接著找到車系-最后找到車款頁面。

通過以上場景分析可以得到一個結(jié)論，人能非常智能的找到所有待抓取的詳細(xì)頁面，即電商的商品，汽車的車款頁面。那么，是否可以通過配置方式來模擬這一過程呢?

請看下圖：

備注如下：

*root_info：

定義發(fā)現(xiàn)模塊的入口頁面，如同人打開汽車站的網(wǎng)頁，后續(xù)的發(fā)現(xiàn)都是起始于這些入口頁。

這里給出的實例是，某汽車網(wǎng)的品牌列表頁，根據(jù)“模板化”套用變量的配置，共有100個入口頁。

* steps:

依次遍歷這100個入口頁，分別會執(zhí)行steps中定義的步驟。機器模擬人的方式進(jìn)行查看瀏覽。

每個step中，會使用"link_module"定義的類進(jìn)行邏輯進(jìn)行處理。

• 讀取入口頁的html，結(jié)合"sub_prefix","sub_suffix"和"select"定義的內(nèi)容，獲得頁面子區(qū)域html。
• 使用"link_match_method"的方法(含前綴包含，匹配等),抽取子區(qū)域的鏈接。
• 每個鏈接 和"link_pattern"進(jìn)行匹配，匹配成功的url進(jìn)入下一步。
• 每一步得到的url，自動進(jìn)和地下一步處理，處理邏輯為遞歸上面a-c，直至"last_step"為true為止。

此處，即"last_step"為true中發(fā)現(xiàn)的url，即為發(fā)現(xiàn)系統(tǒng)最終需要獲取的url列表。發(fā)現(xiàn)系統(tǒng)總結(jié)，通過配置的方式，結(jié)合人類的瀏覽習(xí)慣，通過若干步迭代，最終獲取網(wǎng)站的詳細(xì)頁url列表。

由于每一步的抽取鏈接規(guī)則，以及步數(shù)據(jù)都是人為定義，因此，可以適配絕大部分網(wǎng)站的發(fā)現(xiàn)系統(tǒng)。當(dāng)然，越復(fù)雜的網(wǎng)站發(fā)現(xiàn)配置可能更多一些、更為繁雜，但萬變不離其宗。

2. 得到url后，如何處理

前提當(dāng)然是每個業(yè)務(wù)的處理各不相同，有抽取頁面屬性功能、有正文提取、有圖片獲取，甚至有和當(dāng)前系統(tǒng)對接等。

由于業(yè)務(wù)處理不一致，很自然想到的是通過配置方式，定義職責(zé)鏈系統(tǒng)，如同著名框架Netty中的Pipeline設(shè)計。在處理過程中，定義一個Context上下文處理類，并且，所有的中間結(jié)果都暫緩在這個Context中。

描述比較空洞，還是結(jié)合實際案例來看。

備注如下：

得到一個url后，讀取配置，當(dāng)url和"site"匹配時，適用當(dāng)前"site"規(guī)則。

*  pipeline定義職責(zé)鏈的處理過程

此處的定義為“抓取模塊，Javascript處理模塊，通用解析模塊”。對應(yīng)的處理如下：

先執(zhí)行抓取模塊，得到html。緊接著執(zhí)行Javascript處理模塊，輸入為html，解析html，此處可能是評論，也可能是價格，總之處理的是動態(tài)加載項目，緊接著處理“通用解析模塊”

*  "parser_rules"定義的是解析模塊

最終輸出的是kv，在java中是map，python中是dict。即從上一步的html中，找到每一薦的"sizzle"，執(zhí)行"prefix","suffix"即前后綴移除(過濾如同“價格：xxx元，前綴為“價格:"，后綴為元)。

對了，sizzle也是一個開源技術(shù)，據(jù)說以前鼎鼎有名的Jquery也是"sizzle"引擎。Java中可以使用Jsoup解析處理。

怎么知道需要取的"sizzle"內(nèi)容是什么呢?具體可以結(jié)合firebug插件，選中即可得。選中后，結(jié)合應(yīng)用層的管理工具，即可進(jìn)行測試。

*  “isrequire"

可以看到，配置項中有“isrequire"，表示這項內(nèi)容是否必須。如果必須，且在實際處理中獲取不到，那么在抓取的過程中，就會記錄一個錯誤， 錯誤原因自然是“$key is null"。此外，每一個module都可能出錯，一旦出錯，就沒有必要往后去執(zhí)行。

因此，在抓取過程中，業(yè)務(wù)處理層從服務(wù)層獲得一批url(默認(rèn)100個)后，在處理這一百個url結(jié)束后，會向服層report，report內(nèi)容為：

所有這些信息，均是實時統(tǒng)計，并在運營監(jiān)控系統(tǒng)中以圖表形示繪制出來，必要時可以發(fā)出報警，交由維護(hù)人員實時干預(yù)。

Q: 提一個問題，新增一個anotherauto.com網(wǎng)站怎么辦?

A: 其實也很簡單，再增加一個配置唄。業(yè)務(wù)定義pipeline，如果有解析需求，填寫對應(yīng)的解析項即可。

以上兩個系統(tǒng)，發(fā)現(xiàn)系統(tǒng)和處理系統(tǒng)，在我們實際生產(chǎn)中，是通過以下步驟貫穿。

• 發(fā)現(xiàn)系統(tǒng)累計發(fā)現(xiàn)待抓取網(wǎng)站的詳細(xì)頁，因為是一個累計持續(xù)的過程。因此有把握持續(xù)無限接近網(wǎng)站的100%頁面。
• 處理系統(tǒng)通過服務(wù)層，每次去取配置信息(可能維護(hù)人員在實時修正)及待抓取的列表進(jìn)行處理。

待抓取的列表根據(jù)業(yè)務(wù)的優(yōu)先級，分普通隊列及優(yōu)先級隊列，通過任務(wù)調(diào)度系統(tǒng)進(jìn)行統(tǒng)一管理和配置。

4. 調(diào)度層

• 調(diào)度層主要是業(yè)務(wù)系統(tǒng)。
• 新增一個網(wǎng)站任務(wù)調(diào)度
• 網(wǎng)站發(fā)現(xiàn)頻率，包括增量發(fā)現(xiàn)頻率和全量發(fā)現(xiàn)頻率
• 網(wǎng)站抓取優(yōu)先級推送至隊列
• 斷點續(xù)抓管理
• ......

四、系統(tǒng)架構(gòu)設(shè)計

• 從業(yè)務(wù)模塊上看：應(yīng)用層，服務(wù)層，業(yè)務(wù)處理層，調(diào)度層
• 從功能系統(tǒng)上看：發(fā)現(xiàn)系統(tǒng)，抓取系統(tǒng)， 配置系統(tǒng)，監(jiān)控系統(tǒng)
• 從擴展性上看：自定義職責(zé)鏈，自定義屬性提取
• 從實時性上看：實時抓取，實時配置生效，實時監(jiān)控，實時測試
• 從系統(tǒng)架構(gòu)上看：分布式架構(gòu)，服務(wù)層主從切換設(shè)計，輕量(僅依賴于隊列，數(shù)據(jù)庫，java)

五、圖例

【本文是51CTO專欄機構(gòu)“豈安科技”的原創(chuàng)文章，轉(zhuǎn)載請通過微信公眾號(bigsec)聯(lián)系原作者】

戳這里，看該作者更多好文