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

時間 2019-11-11

原文原文鏈接

【初碼文章推薦】

【初碼產品推薦】

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

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

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

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

任務界面能夠看到視頻信息，實時下載信息，和錯誤信息瀏覽器

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

那麼下面就把本次的開發和實施流水帳記錄一下服務器

一、首先是準備工做和可行性調研微信

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

首先打開B站任意一個視頻，能夠看到地址都是這樣的格式數據結構

因而咱們把AV後面的號碼叫作番號（此番號非老司機番號）

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

而若是把Index後面的2換成1，也能夠達到和第一個地址同樣的效果

而後用Fidder工具，分析一下網頁，能夠看到有以下一些資源

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

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

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

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

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

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

太好了，一會兒就給了視頻尺寸和視頻最終的下載地址，那麼咱們用瀏覽器打開一下這個URL看一下，能夠成功下載！

注：以上相關分析其實是通過了1-2個小時的反覆嘗試和模擬得出的，有2個細節補充一下，一、B站的服務器會根據HTTP頭信息的不一樣返回FLV格式或者MP4格式，二、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

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

二、而後進行業務功能的設計

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

1、用戶端功能

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

最終界面以下：

二、用戶能夠在提交視頻下載後，能夠看到實時的處理進度，而且可以看到本身之前提交的任務（注：須要設計任務機制，作好狀態控制，這裏採用Azure的存儲隊列）

最終界面以下

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

最終效果以下：

四、下載進度可以經過郵件進行視頻信息的推送（注：使用郵件模板技術，詳見：《使用阿里雲郵件推送服務架設本身郵件驗證與推送體系》，這裏採用SendCloud雲服務）

最終效果以下：

2、服務端功能

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

二、增長下載效率，使用多線程技術（注：由於使用.NET作爬蟲，多線程控制還算比較穩定和齊全）

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

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

三、系統設計與技術細節

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

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

1、分佈式架構的核心

一、分佈式Win32控制檯程序須要有帳號體系，這樣能夠進行節點的實施狀態管理和記錄

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

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

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

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

2、爬蟲任務的數據結構

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

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

二、視頻存儲表

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

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

一、.NET裏面的Process類

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

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

監聽數據接收

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

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

二、重試的機制

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

3、CDN的加速處理

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

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

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

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

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

4、郵件推送的處理

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

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

一、技術改進。由於整個程序就作了2天不到，不少技術細節點並未很到位，還有大量能夠改進的地方：

好比對於PhantomJS更多細節參數的研究，是否是能夠提高效率，是否是能夠減小出錯率

又好比任務表的設計，耦合的地方仍是不少，應該還能夠優化設計

又好比在用戶界面上，沒有作太多H5的美工，應該還能夠增強一下

又好比分佈式客戶端Windows Console Application是否是能夠強化爲Windows Service，而且加入監控和守護進程

又好比通過研究發現，B站用了大廠商（藍汛）的CDN服務，很是智能，在快速的加載30%之後就進行限速，那麼對於這樣的瓶頸的處理是否是還能夠更細緻一些

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

二、功能改進。今天只是爲了測試存儲隊列的這個服務，因此簡單的進行了B站視頻的爬蟲，事實上還有不少後續功能能夠拓展

好比加入微信掃碼就能夠在微信上下載視頻、觀看視頻

好比能夠綁定微信公衆號，在微信公衆號上也能夠視頻番號發起下載，並經過微信模板消息推送處理結果

好比能夠加入對彈幕的處理

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

三、其餘思考

仍是老生常談的話題，堅定的反對前端向開發人員進行大型系統的架構，作出來除了垃圾就是垃圾

目前我的信息的保護是很是嚴格的，若是下載並存儲電影和綜藝節目，必定是非法的甚至觸犯刑法，而這種我的發佈的視頻的爬蟲下載，不知道上傳時有沒有和B站簽署版權協議或者電子協議，若是是直接下載地址給到用戶還好，但在本案例中，加入了中轉存儲，那麼這樣的行爲，是否是涉嫌違法呢？我認爲暫時法律風險不大，但從長遠看，不太合適！