摘要：在系統(tǒng)正常運(yùn)行時(shí)，可以變更爬蟲的配置，一旦實(shí)時(shí)監(jiān)控爬蟲出現(xiàn)異常，可實(shí)時(shí)修正配置進(jìn)行干預(yù)。從數(shù)據(jù)庫(kù)中實(shí)時(shí)讀取配置信息，響應(yīng)業(yè)務(wù)層的配置請(qǐng)求。處理系統(tǒng)通過(guò)服務(wù)層，每次去取配置信息可能維護(hù)人員在實(shí)時(shí)修正及待抓取的列表進(jìn)行處理。

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

這些開發(fā)的爬蟲項(xiàng)目有通用性嗎？

有沒(méi)有可能花費(fèi)較小的代價(jià)完成一個(gè)新的爬蟲需求？

在維護(hù)運(yùn)營(yíng)過(guò)程中，是否能夠工具化，構(gòu)建基于配置化的分布式爬蟲應(yīng)用？

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

立項(xiàng)之初，我們從使用的腳度試著提幾個(gè)需求。

1. 分布式抓取
由于抓取量可能非常龐大，一臺(tái)機(jī)器不足以處理百萬(wàn)以上的抓取任務(wù)，因此分布式爬蟲應(yīng)用是首當(dāng)其沖要面對(duì)并解決的問(wèn)題。
? ? ?
2. 模塊化，輕量
我們將爬蟲應(yīng)用分成“應(yīng)用層，服務(wù)層，業(yè)務(wù)處理層，調(diào)度層” 四個(gè)腳色。

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

4. 通用性，可擴(kuò)展。
爬蟲業(yè)務(wù)往往多變，不同領(lǐng)域的爬取需求不盡相同。舉例說(shuō)，房源抓取包含圖片抓取，小區(qū)信息抓取，房源去重等模塊。新聞抓取包括內(nèi)容抓取，正文提取，信息摘要等相關(guān)。
因此，系統(tǒng)需要能夠支持業(yè)務(wù)擴(kuò)展需求，可以支持不同的業(yè)務(wù)使用同一套框架進(jìn)行應(yīng)用開發(fā)。?

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

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

系統(tǒng)配置模塊：系統(tǒng)配置模塊包含抓取網(wǎng)站管理配置，在線測(cè)試等功能。

運(yùn)營(yíng)管理模塊：運(yùn)營(yíng)管理模塊包含實(shí)時(shí)抓取量統(tǒng)計(jì)，分析，正確率等。甚至包括失敗原因，失敗量。
?

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

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

提供網(wǎng)站爬蟲配置接口。從數(shù)據(jù)庫(kù)中實(shí)時(shí)讀取配置信息，響應(yīng)業(yè)務(wù)層的配置請(qǐng)求。

提供業(yè)務(wù)層輸出寫入接口。接受業(yè)務(wù)層實(shí)時(shí)爬取的信息匯總，包括正確數(shù)據(jù)量，錯(cuò)誤數(shù)據(jù)量，以及錯(cuò)誤原因。

提供實(shí)時(shí)報(bào)表統(tǒng)計(jì)分析。響應(yīng)應(yīng)用層的運(yùn)營(yíng)管理模塊，查詢數(shù)據(jù)庫(kù)，實(shí)時(shí)提供數(shù)據(jù)分析報(bào)告。

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

如何獲取url

得到url后，如何處理

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

假設(shè)場(chǎng)景 A
我們逛一個(gè)電商網(wǎng)站：打開首頁(yè)-打開分類頁(yè)-可能會(huì)有多層分類頁(yè)-逐層點(diǎn)擊-直至最小的分類頁(yè)面。
打開這個(gè)分類頁(yè)會(huì)發(fā)現(xiàn)該分類頁(yè)下的所有分頁(yè)頁(yè)面，一頁(yè)一頁(yè)往下翻，就能夠獲得該分類頁(yè)的所有商品。

假設(shè)場(chǎng)景 B
我們逛一個(gè)汽車網(wǎng)站：打開首頁(yè)-找到品牌頁(yè)-接著找到車系-最后找到車款頁(yè)面。

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

請(qǐng)看下圖：

備注如下：

1.?root_info：
定義發(fā)現(xiàn)模塊的入口頁(yè)面，如同人打開汽車站的網(wǎng)頁(yè)，后續(xù)的發(fā)現(xiàn)都是起始于這些入口頁(yè)。
這里給出的實(shí)例是，某汽車網(wǎng)的品牌列表頁(yè)，根據(jù)“模板化”套用變量的配置，共有100個(gè)入口頁(yè)。

2.?steps:?
依次遍歷這100個(gè)入口頁(yè)，分別會(huì)執(zhí)行steps中定義的步驟。機(jī)器模擬人的方式進(jìn)行查看瀏覽。
每個(gè)step中，會(huì)使用"link_module"定義的類進(jìn)行邏輯進(jìn)行處理。

讀取入口頁(yè)的html，結(jié)合"sub_prefix","sub_suffix"和"select"定義的內(nèi)容，獲得頁(yè)面子區(qū)域html。

使用"link_match_method"的方法（含前綴包含，匹配等）,抽取子區(qū)域的鏈接。

每個(gè)鏈接?和"link_pattern"進(jìn)行匹配，匹配成功的url進(jìn)入下一步。

每一步得到的url，自動(dòng)進(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é)，通過(guò)配置的方式，結(jié)合人類的瀏覽習(xí)慣，通過(guò)若干步迭代，最終獲取網(wǎng)站的詳細(xì)頁(yè)url列表。

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

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

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

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

備注如下：

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

1?pipeline定義職責(zé)鏈的處理過(guò)程
此處的定義為“抓取模塊，Javascript處理模塊，通用解析模塊”。對(duì)應(yīng)的處理如下：
先執(zhí)行抓取模塊，得到html。緊接著執(zhí)行Javascript處理模塊，輸入為html，解析html，此處可能是評(píng)論，也可能是價(jià)格，總之處理的是動(dòng)態(tài)加載項(xiàng)目，緊接著處理“通用解析模塊”

2 ?"parser_rules"定義的是解析模塊
最終輸出的是kv，在java中是map，python中是dict。即從上一步的html中，找到每一薦的"sizzle"，執(zhí)行"prefix","suffix"即前后綴移除(過(guò)濾如同“價(jià)格：xxx元，前綴為“價(jià)格:"，后綴為元)。
對(duì)了，sizzle也是一個(gè)開源技術(shù)，據(jù)說(shuō)以前鼎鼎有名的Jquery也是"sizzle"引擎。Java中可以使用Jsoup解析處理。
怎么知道需要取的"sizzle"內(nèi)容是什么呢？具體可以結(jié)合firebug插件，選中即可得。選中后，結(jié)合應(yīng)用層的管理工具，即可進(jìn)行測(cè)試。

3 ?“isrequire"
可以看到，配置項(xiàng)中有“isrequire"，表示這項(xiàng)內(nèi)容是否必須。如果必須，且在實(shí)際處理中獲取不到，那么在抓取的過(guò)程中，就會(huì)記錄一個(gè)錯(cuò)誤，?錯(cuò)誤原因自然是“$key is null"。此外，每一個(gè)module都可能出錯(cuò)，一旦出錯(cuò)，就沒(méi)有必要往后去執(zhí)行。
因此，在抓取過(guò)程中，業(yè)務(wù)處理層從服務(wù)層獲得一批url(默認(rèn)100個(gè)）后，在處理這一百個(gè)url結(jié)束后，會(huì)向服層report，report內(nèi)容為：
當(dāng)前任務(wù)處理機(jī)器，于什么時(shí)間處理100個(gè)頁(yè)面。不同網(wǎng)站成功多少、失敗多少、什么模塊失敗多少，解析模塊什么字段失敗多少。
所有這些信息，均是實(shí)時(shí)統(tǒng)計(jì)，并在運(yùn)營(yíng)監(jiān)控系統(tǒng)中以圖表形示繪制出來(lái)，必要時(shí)可以發(fā)出報(bào)警，交由維護(hù)人員實(shí)時(shí)干預(yù)。

Q:?提一個(gè)問(wèn)題，新增一個(gè)anotherauto.com網(wǎng)站怎么辦？
A:?其實(shí)也很簡(jiǎn)單，再增加一個(gè)配置唄。業(yè)務(wù)定義pipeline，如果有解析需求，填寫對(duì)應(yīng)的解析項(xiàng)即可。

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

發(fā)現(xiàn)系統(tǒng)累計(jì)發(fā)現(xiàn)待抓取網(wǎng)站的詳細(xì)頁(yè)，因?yàn)槭且粋€(gè)累計(jì)持續(xù)的過(guò)程。因此有把握持續(xù)無(wú)限接近網(wǎng)站的100%頁(yè)面。

處理系統(tǒng)通過(guò)服務(wù)層，每次去取配置信息（可能維護(hù)人員在實(shí)時(shí)修正）及待抓取的列表進(jìn)行處理。

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

調(diào)度層

調(diào)度層主要是業(yè)務(wù)系統(tǒng)。

新增一個(gè)網(wǎng)站任務(wù)調(diào)度

網(wǎng)站發(fā)現(xiàn)頻率，包括增量發(fā)現(xiàn)頻率和全量發(fā)現(xiàn)頻率

網(wǎng)站抓取優(yōu)先級(jí)推送至隊(duì)列

斷點(diǎn)續(xù)抓管理

......

從業(yè)務(wù)模塊上看

應(yīng)用層，服務(wù)層，業(yè)務(wù)處理層，調(diào)度層

從功能系統(tǒng)上看

發(fā)現(xiàn)系統(tǒng)，抓取系統(tǒng)，?配置系統(tǒng)，監(jiān)控系統(tǒng)

從擴(kuò)展性上看

自定義職責(zé)鏈，自定義屬性提取

從實(shí)時(shí)性上看

實(shí)時(shí)抓取，實(shí)時(shí)配置生效，實(shí)時(shí)監(jiān)控，實(shí)時(shí)測(cè)試

從系統(tǒng)架構(gòu)上看

分布式架構(gòu)，服務(wù)層主從切換設(shè)計(jì)，輕量（僅依賴于隊(duì)列，數(shù)據(jù)庫(kù)，java)

①　

②　

③　

*爬蟲模塊 ui二 (1.6 ?任務(wù)配置) ：
定義每個(gè)爬蟲任務(wù)的處理執(zhí)行職責(zé)鏈，不同的爬蟲任務(wù)可以有不同的處理鏈。對(duì)于系統(tǒng)而言，處理每一個(gè)待爬取的url，都會(huì)按照職責(zé)鏈的順序執(zhí)行。后置處理類則是一批任務(wù)執(zhí)行后（如上文的100個(gè)url)，批量提交的方式。如文件落地，入庫(kù)，推往線上系統(tǒng)等。通過(guò)任務(wù)處理定義，則可以自定義各類不同場(chǎng)景的爬蟲業(yè)務(wù)，在不編碼的前提下增加系統(tǒng)的靈活性。*

④　?

*屬性配置：
如圖所示，維護(hù)人員增加條測(cè)試的url，同時(shí)定義需要提取的屬性，則可在線定義該頁(yè)面對(duì)應(yīng)的屬性輸出，可見即可得。?在增加便利性，可測(cè)試性的基礎(chǔ)上，又能靈活的選取頁(yè)面的任意屬性，值得一提的是，可以通過(guò)firefox插件獲取sizzle的配置。*

⑤　

*1.9查看明細(xì)：?
在爬蟲系統(tǒng)的運(yùn)行過(guò)程中，幾乎可以實(shí)時(shí)的進(jìn)行任務(wù)的監(jiān)控。由于爬蟲任務(wù)實(shí)時(shí)將爬取的狀態(tài)寫入數(shù)據(jù)庫(kù)，因此完全可以通過(guò)ui界面進(jìn)行管理及監(jiān)控。1. 監(jiān)控：監(jiān)控爬蟲任務(wù)當(dāng)前時(shí)間成功次數(shù)，錯(cuò)誤次數(shù)，什么模塊錯(cuò)誤，甚至某個(gè)屬性提取錯(cuò)誤。2. 管理：維護(hù)人員觀測(cè)監(jiān)控效果后，可實(shí)時(shí)進(jìn)行編輯及管理（見上一張圖），以應(yīng)對(duì)不同網(wǎng)站的改版需求。所有編輯實(shí)時(shí)生效，編輯完成后，無(wú)需重啟服務(wù)，又可實(shí)時(shí)監(jiān)控爬蟲任務(wù)的最新效果。*

反爬蟲
文章來(lái)源：http://bigsec.com/

踏浪無(wú)痕 ?豈安科技高級(jí)架構(gòu)師? 
十余年數(shù)據(jù)研發(fā)經(jīng)驗(yàn)，擅長(zhǎng)數(shù)據(jù)處理領(lǐng)域工作，如爬蟲、搜索引擎、大數(shù)據(jù)應(yīng)用高并發(fā)等。擔(dān)任過(guò)架構(gòu)師，研發(fā)經(jīng)理等崗位。曾主導(dǎo)開發(fā)過(guò)大型爬蟲，搜索引擎及大數(shù)據(jù)廣告DMP系統(tǒng)目前負(fù)責(zé)豈安科技數(shù)據(jù)平臺(tái)開發(fā)與搭建。