【初碼乾貨】記一次分佈式B站爬蟲任務系統的完整設計和實施

【初碼文章推薦】

程序員的自我修養 Azure系列文章 阿里雲系列文章 爬蟲系列文章

【初碼產品推薦】

AlphaMS開發模式 閃送達城市中央廚房

---

今天帶來一個有意思的東西-分佈式B站爬蟲任務系統

這個小玩意源於上週在研究Azure的時候，發現雲服務廠商都在推薦輕量級的存儲隊列服務，用來取代原有的比較重的消息隊列服務，具體來說，比如阿里雲就推薦使用消息服務替代消息隊列，在Azure中，就有一個輕量級的存儲隊列（Storage Queue）可以替代服務總線（Service Bus），簡單試用了一下Azure的Storage Queue後，發現這玩意很好用，於是決定全面的深入研究一下，再將公司電商系統內的相關任務處理均重構成使用存儲隊列服務，而深入研究得找個案例呀，於是就想到了做個分佈式爬蟲，此類應用會出現大量的任務場景，而正好前段時間下載B站視頻時，找到一個網站，叫唧唧下載（搞二次元的都是色情狂嗎？），但又不太好用，於是決定就做個比較全面的B站視頻爬蟲。一方面可以方便的下載視頻，另一方面還可以當做公司開發人員的教學案例

老規矩，還是先看下最終的使用效果，應用入口：https://www.alphams.cn/LT，（爲了防止濫用下載以及記錄下載，所以還麻煩註冊一下啦）

輸入視頻番號，點擊下載，就進入任務界面

任務界面可以看到視頻信息，實時下載信息，和錯誤信息

任務處理完成後，點擊立即下載，從一個CDN加速的地址得到了視頻

---

那麼下面就把本次的開發和實施流水賬記錄一下

1、首先是準備工作和可行性調研

想要對B站進行爬蟲，首先要準備好技術手段和相關工具，對B站的網站結構和數據流向進行一些分析，進行可行性的調研

首先打開B站任意一個視頻，可以看到地址都是這樣的格式

於是我們把AV後面的號碼叫做番號（此番號非老司機番號）

而有些視頻不止一段，如果是第二段視頻，則是這個地址：

而如果把Index後面的2換成1，也可以達到和第一個地址一樣的效果

然後用Fidder工具，分析一下網頁，可以看到有如下一些資源

剔除基本的JS文件、CSS文件、圖像文件後，剩下來的就是一些有用的信息了，而在有用的信息中最終篩選出如下幾個信息

1、AID是視頻的番號，也就是網址URL後面的那串唯一數字

2、CID是彈幕的番號，每個視頻AID會對應一個CID

3、彈幕的信息存儲在了這樣的URL中：http://comment.bilibili.com/15075110.xml

4、視頻的信息存儲在了這樣的URL中：https://interface.bilibili.com/playurl?cid=15075110&appkey=84956560bc028eb7&otype=json&type=&quality=3&sign=c070bfd93a84cab542e7c874add6839e

因爲本次主要是下載視頻，所以就着重看一下視頻存儲的信息，打開上面的URL後發現了最終視頻的地址

太好了，一下子就給了視頻尺寸和視頻最終的下載地址，那麼我們用瀏覽器打開一下這個URL看一下，可以成功下載！

注：以上相關分析實際上是經過了1-2個小時的反覆嘗試和模擬得出的，有2個細節補充一下，1、B站的服務器會根據HTTP頭信息的不同返回FLV格式或者MP4格式，2、B站的視頻可能用了不同廠商的CDN服務，有些視頻地址無法直接下載，會判斷refer信息和瀏覽器信息）

接下來繼續分析，注意看這個URL可以發現，尾部有一個sign，說明做了客戶端和服務端的簽名驗證，並不是很傻瓜的有直接通過AID或者CID關聯的下載地址，分析進入到這一步後，我很快的就打了自己的臉，我曾在文章《關於.NET玩爬蟲這些事》中說過，一切網站行爲都可以分析出HTTP+Javascript來，只要分析得當，根本不需要用瀏覽器來進行爬蟲模擬，但這尼瑪B站鬼的Web結構（忍不住想罵人，典型的垃圾Python、PHP向的開發人員做出來的鬼東西，代碼邏輯混亂、隨便一看就是到處修補修改的痕跡，生成出來的HTML、JS的邏輯和層次毫無美感），看了2個小時，眼睛都看疼了，楞是沒分析出簽名方法，也許再看看會有結果，但是我等不及了，所以這時候祭出爬蟲神器-無頭瀏覽器

這裏我選擇了PhantomJS這個無頭瀏覽器，具體的使用過程就不詳述了，有興趣可以到官網瞭解一下，寫了如下分析代碼

通過代碼我們可以很清楚的看到，主要是兩個目的，輸出包含interface.bilibili.com的URL以及本次視頻的標題

測試一下，確實可以得到URL和標題，這裏有個要注意的是，B站默認是GB2312編碼，所以PhantomJS要加一個參數，就是輸出編碼改爲GB2312

到此爲止，可以說完成了整個爬蟲部分的調研，至少是有完整的可行性了。

 

2、然後進行業務功能的設計

有了可行性後，就可以天馬行空的進行業務功能的設計了，既然上面說到那個雞雞網站特別不好用，那麼我們就來重新設計一下這個爬蟲的功能

一、用戶端功能

1、用戶可以輸入視頻番號和序號提交視頻下載（注：乾淨清爽的提交界面）

最終界面如下：

2、用戶可以在提交視頻下載後，可以看到實時的處理進度，並且能夠看到自己以前提交的任務（注：需要設計任務機制，做好狀態控制，這裏採用Azure的存儲隊列）

最終界面如下

3、用戶最終的下載速度特別快（注：使用CDN和網絡存儲技術，這裏採用阿里雲的CDN和OSS）

最終效果如下：

4、下載進度能夠通過郵件進行視頻信息的推送（注：使用郵件模板技術，詳見：《使用阿里雲郵件推送服務架設自己郵件驗證與推送體系》，這裏採用SendCloud雲服務）

最終效果如下：

二、服務端功能

1、考慮到B站CDN可能會限制IP地址使用，需要使用分佈式的爬蟲設計（注：這裏使用Windows Console Application程序）

2、增加下載效率，使用多線程技術（注：因爲使用.NET做爬蟲，多線程控制還算比較穩定和齊全）

3、對無頭瀏覽器進行精準的控制（注：這裏是Windows環境，考慮使用.NET裏面的Process類進行控制）

有了業務功能做指導，下面就可以進行完整的系統設計了

 

3、系統設計與技術細節

老規矩，先放出整體設計圖

其中具體的技術細節和代碼如下：

一、分佈式架構的核心

1、分佈式Win32控制檯程序需要有賬號體系，這樣可以進行節點的實施狀態管理和記錄

 

2、任務的新增、獲取、覈銷等，需要精準的控制，不能出現併發衝突，所以這裏使用了消息隊列，也就是上面所說的Azure存儲隊列服務

任務的新增和分配主要代碼如下：

 

3、豐富的日誌和錯誤處理機制

因爲會一直執行，分佈式節點的穩定性非常重要，Windows Console Application程序本身是非常穩定，因此在具體的代碼裏面，內存控制與對象釋放、死循環的避免、多線程優化、異常的捕捉和處理等都非常重要，這裏不一一洗漱，都是開發的基本功，做類似的應用的話，大家也需要多注意。另外因爲無頭瀏覽器的執行，是放在分佈式的客戶端裏面進行的，因此也需要對無頭瀏覽器進行精準控制，下面會詳細說到

 

二、爬蟲任務的數據結構

本案例中由於只對單一URL進行分析和爬蟲，業務邏輯並不複雜，考慮到需要支持進度查詢、狀態控制等，數據結構設計如下，就2個表

1、爬蟲任務表（記錄爬蟲任務，控制狀態、記錄過程參數等）

2、視頻存儲表

任務完成後，就把CDN加速好的視頻信息存儲下來，一方面進行冗餘查詢，另一方面也用於其他用戶下載可以秒下

三、無頭瀏覽器的精準控制

1、.NET裏面的Process類

上面提到了，無頭瀏覽器畢竟有一個瀏覽器內核的執行，而在任務處理的高峯，可能會不斷的調用、銷燬這個瀏覽器，而Web行爲又是非常不穩定的，所以想要分佈式的穩定，就一定要進行無頭瀏覽器的精準控制。這裏用到了.NET裏面Process來控制無頭瀏覽器的執行，主要的技術點有：

• 不顯示命令窗口，重定向輸入輸出

• 監聽數據接收

這裏可以看到，我們之前在PhantomJS裏面寫的JS代碼，主要就輸出了兩點，一個是包含下載地址JSON數據的URL地址，另一個是視頻的標題，這裏都做了記錄

• 差錯處理以及任務的關閉和結束

 

2、重試的機制

實測中發現，無頭瀏覽器的失敗率和出錯率還是挺高的，因此在數據結構設計的時候，就預留了重試機制，當分佈式客戶端處理視頻失敗時，服務端重新提交消息隊列，超過一定的次數再宣告任務失敗

 

三、CDN的加速處理

1、之前在這篇文章《使用阿里雲對Web開發中的資源文件進行CDN加速的深入研究和實踐》中，提出了一種非常好的資源管理和加速方式，核心思路包括三點

• 文件資源的信息管理和目錄結構在本地數據表中，GUID化
• 文件的數據存儲在阿里雲OSS中，無目錄結構的扁平化記錄
• 對OSS綁定域名，對CDN服務也綁定域名
• 反饋給客戶端的文件信息，直接使用CDN地址，從而回源到OSS中或者直接命中緩存

2、同樣的，在本次案例中，也使用了這樣的處理方式，最終給用戶的下載地址是CDN下載地址，具體的處理流程可以看上面的設計圖，應該能一目瞭然

3、關於對上傳到OSS的處理

在最初的設計方案中，分佈式客戶端完全下載到視頻文件的內容後，是上傳到服務端，由服務端統一進行上傳，後來評估這樣的方式，對服務端的壓力和帶寬佔用都明顯提升了，既然是分佈式系統，應當充分利用分佈式客戶端的資源，所以改爲分佈式客戶端直接上傳文件到阿里雲OSS中，這樣做唯一的弊端是分佈式客戶端會獲取明文的阿里雲管理密鑰，於是又加入了阿里雲RAM權限管理，加入了OSS子權限的控制，問題就迎刃而解了。

 

四、郵件推送的處理

在上面的功能設計中，加入了郵件推送的功能，詳細的設計思路參見這篇文章《使用阿里雲郵件推送服務架設自己郵件驗證與推送體系》，郵件模板就是HTML代碼，這裏就不多說了，但有一個小插曲，就是阿里雲的郵件推送服務，實在是太爛了，特別是QQ郵箱的到達率奇差無比，因此最終的實施部分換成了搜狐的SendCloud解決方案。

 

好啦，整個實施到這裏基本上就差不多了，老規矩，還是要總結和思考一下：

1、技術改進。因爲整個程序就做了2天不到，很多技術細節點並未很到位，還有大量可以改進的地方：

• 比如對於PhantomJS更多細節參數的研究，是不是可以提升效率，是不是可以減少出錯率
• 又比如任務表的設計，耦合的地方還是很多，應該還可以優化設計
• 又比如在用戶界面上，沒有做太多H5的美工，應該還可以加強一下
• 又比如分佈式客戶端Windows Console Application是不是可以強化爲Windows Service，並且加入監控和守護進程
• 又比如經過研究發現，B站用了大廠商（藍汛）的CDN服務，非常智能，在快速的加載30%以後就進行限速，那麼對於這樣的瓶頸的處理是不是還可以更細緻一些

這些工作在後續我會慢慢完善

2、功能改進。今天只是爲了測試存儲隊列的這個服務，所以簡單的進行了B站視頻的爬蟲，事實上還有很多後續功能可以拓展

比如加入微信掃碼就可以在微信上下載視頻、觀看視頻

比如可以綁定微信公衆號，在微信公衆號上也可以視頻番號發起下載，並通過微信模板消息推送處理結果

比如可以加入對彈幕的處理

比如可以加入一些經營性的功能，例如廣告、收費高速下載、加入存儲廣告站的下載地址等等

3、其他思考

• 還是老生常談的話題，堅決的反對前端向開發人員進行大型系統的架構，做出來除了垃圾就是垃圾
• 目前個人信息的保護是非常嚴格的，如果下載並存儲電影和綜藝節目，一定是非法的甚至觸犯刑法，而這種個人發佈的視頻的爬蟲下載，不知道上傳時有沒有和B站簽署版權協議或者電子協議，如果是直接下載地址給到用戶還好，但在本案例中，加入了中轉存儲，那麼這樣的行爲，是不是涉嫌違法呢？我認爲暫時法律風險不大，但從長遠看，不太合適！

---

作者：張柔，發佈於  博客園  與  張柔的博客

轉載請註明出處，歡迎郵件交流：[email protected]，或者加QQ羣：11444444