今天帶來一個有意思的東西-分布式B站爬蟲任務(wù)系統(tǒng)

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

老規(guī)矩，還是先看下最終的使用效果，應(yīng)用入口：https://www./LT，（為了防止濫用下載以及記錄下載，所以還麻煩注冊一下啦）

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

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

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

那么下面就把本次的開發(fā)和實施流水賬記錄一下

1、首先是準備工作和可行性調(diào)研

想要對B站進行爬蟲，首先要準備好技術(shù)手段和相關(guān)工具，對B站的網(wǎng)站結(jié)構(gòu)和數(shù)據(jù)流向進行一些分析，進行可行性的調(diào)研

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

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

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

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

然后用Fidder工具，分析一下網(wǎng)頁，可以看到有如下一些資源

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

1、AID是視頻的番號，也就是網(wǎng)址URL后面的那串唯一數(shù)字

2、CID是彈幕的番號，每個視頻AID會對應(yīng)一個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后發(fā)現(xiàn)了最終視頻的地址

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

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

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

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

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

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

到此為止，可以說完成了整個爬蟲部分的調(diào)研，至少是有完整的可行性了。

2、然后進行業(yè)務(wù)功能的設(shè)計

有了可行性后，就可以天馬行空的進行業(yè)務(wù)功能的設(shè)計了，既然上面說到那個雞雞網(wǎng)站特別不好用，那么我們就來重新設(shè)計一下這個爬蟲的功能

一、用戶端功能

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

最終界面如下：

2、用戶可以在提交視頻下載后，可以看到實時的處理進度，并且能夠看到自己以前提交的任務(wù)（注：需要設(shè)計任務(wù)機制，做好狀態(tài)控制，這里采用Azure的存儲隊列）

最終界面如下

3、用戶最終的下載速度特別快（注：使用CDN和網(wǎng)絡(luò)存儲技術(shù)，這里采用阿里云的CDN和OSS）

最終效果如下：

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

最終效果如下：

二、服務(wù)端功能

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

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

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

有了業(yè)務(wù)功能做指導(dǎo)，下面就可以進行完整的系統(tǒng)設(shè)計了

3、系統(tǒng)設(shè)計與技術(shù)細節(jié)

老規(guī)矩，先放出整體設(shè)計圖

其中具體的技術(shù)細節(jié)和代碼如下：

一、分布式架構(gòu)的核心

1、分布式Win32控制臺程序需要有賬號體系，這樣可以進行節(jié)點的實施狀態(tài)管理和記錄

2、任務(wù)的新增、獲取、核銷等，需要精準的控制，不能出現(xiàn)并發(fā)沖突，所以這里使用了消息隊列，也就是上面所說的Azure存儲隊列服務(wù)

任務(wù)的新增和分配主要代碼如下：

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

因為會一直執(zhí)行，分布式節(jié)點的穩(wěn)定性非常重要，Windows Console Application程序本身是非常穩(wěn)定，因此在具體的代碼里面，內(nèi)存控制與對象釋放、死循環(huán)的避免、多線程優(yōu)化、異常的捕捉和處理等都非常重要，這里不一一洗漱，都是開發(fā)的基本功，做類似的應(yīng)用的話，大家也需要多注意。另外因為無頭瀏覽器的執(zhí)行，是放在分布式的客戶端里面進行的，因此也需要對無頭瀏覽器進行精準控制，下面會詳細說到

二、爬蟲任務(wù)的數(shù)據(jù)結(jié)構(gòu)

本案例中由于只對單一URL進行分析和爬蟲，業(yè)務(wù)邏輯并不復(fù)雜，考慮到需要支持進度查詢、狀態(tài)控制等，數(shù)據(jù)結(jié)構(gòu)設(shè)計如下，就2個表

1、爬蟲任務(wù)表（記錄爬蟲任務(wù)，控制狀態(tài)、記錄過程參數(shù)等）

2、視頻存儲表

任務(wù)完成后，就把CDN加速好的視頻信息存儲下來，一方面進行冗余查詢，另一方面也用于其他用戶下載可以秒下

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

1、.NET里面的Process類

上面提到了，無頭瀏覽器畢竟有一個瀏覽器內(nèi)核的執(zhí)行，而在任務(wù)處理的高峰，可能會不斷的調(diào)用、銷毀這個瀏覽器，而Web行為又是非常不穩(wěn)定的，所以想要分布式的穩(wěn)定，就一定要進行無頭瀏覽器的精準控制。這里用到了.NET里面Process來控制無頭瀏覽器的執(zhí)行，主要的技術(shù)點有：

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

• 監(jiān)聽數(shù)據(jù)接收

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

• 差錯處理以及任務(wù)的關(guān)閉和結(jié)束

2、重試的機制

實測中發(fā)現(xiàn)，無頭瀏覽器的失敗率和出錯率還是挺高的，因此在數(shù)據(jù)結(jié)構(gòu)設(shè)計的時候，就預(yù)留了重試機制，當分布式客戶端處理視頻失敗時，服務(wù)端重新提交消息隊列，超過一定的次數(shù)再宣告任務(wù)失敗

三、CDN的加速處理

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

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

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

3、關(guān)于對上傳到OSS的處理

在最初的設(shè)計方案中，分布式客戶端完全下載到視頻文件的內(nèi)容后，是上傳到服務(wù)端，由服務(wù)端統(tǒng)一進行上傳，后來評估這樣的方式，對服務(wù)端的壓力和帶寬占用都明顯提升了，既然是分布式系統(tǒng)，應(yīng)當充分利用分布式客戶端的資源，所以改為分布式客戶端直接上傳文件到阿里云OSS中，這樣做唯一的弊端是分布式客戶端會獲取明文的阿里云管理密鑰，于是又加入了阿里云RAM權(quán)限管理，加入了OSS子權(quán)限的控制，問題就迎刃而解了。

四、郵件推送的處理

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

好啦，整個實施到這里基本上就差不多了，老規(guī)矩，還是要總結(jié)和思考一下：

1、技術(shù)改進。因為整個程序就做了2天不到，很多技術(shù)細節(jié)點并未很到位，還有大量可以改進的地方：

• 比如對于PhantomJS更多細節(jié)參數(shù)的研究，是不是可以提升效率，是不是可以減少出錯率
• 又比如任務(wù)表的設(shè)計，耦合的地方還是很多，應(yīng)該還可以優(yōu)化設(shè)計
• 又比如在用戶界面上，沒有做太多H5的美工，應(yīng)該還可以加強一下
• 又比如分布式客戶端Windows Console Application是不是可以強化為Windows Service，并且加入監(jiān)控和守護進程
• 又比如經(jīng)過研究發(fā)現(xiàn)，B站用了大廠商（藍汛）的CDN服務(wù)，非常智能，在快速的加載30%以后就進行限速，那么對于這樣的瓶頸的處理是不是還可以更細致一些

這些工作在后續(xù)我會慢慢完善

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

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

比如可以綁定微信公眾號，在微信公眾號上也可以視頻番號發(fā)起下載，并通過微信模板消息推送處理結(jié)果

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

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

3、其他思考

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