我一直覺得，爬蟲是許多web開發(fā)人員難以回避的點。我們也應該或多或少的去接觸這方面，因為可以從爬蟲中學習到web開發(fā)中應當掌握的一些基本知識。而且，它還很有趣。

我是一個知乎輕微重度用戶，之前寫了一只爬蟲幫我爬取并分析它的數據，我感覺這個過程還是挺有意思，因為這是一個不斷給自己創(chuàng)造問題又去解決問題的過程。其中遇到了一些點，今天總結一下跟大家分享分享。

它都爬了什么?

先簡單介紹下我的爬蟲。它能夠定時抓取一個問題的關注量、瀏覽量、回答數，以便于我將這些數據繪成圖表展現它的熱點趨勢。為了不讓我錯過一些熱門事件，它還會定時去獲取我關注話題下的熱門問答，并推送到我的郵箱。

作為一個前端開發(fā)人員，我必須為這個爬蟲系統(tǒng)做一個界面，能讓我登陸知乎帳號，添加關注的題目、話題，看到可視化的數據。所以這只爬蟲還有登陸知乎、搜索題目的功能。

然后來看下界面。

下面正兒八經講它的開發(fā)歷程。

技術選型

Python得益于其簡單快捷的語法、以及豐富的爬蟲庫，一直是爬蟲開發(fā)人員的***?？上也皇臁．斎蛔钪匾氖?，作為一名前端開發(fā)人員，node能滿足爬蟲需求的話，自然更是***。而且隨著node的發(fā)展，也有許多好用的爬蟲庫，甚至有 puppeteer 這樣直接能模擬Chrome訪問網頁的工具的推出，node在爬蟲方面應該是妥妥能滿足我所有的爬蟲需求了。

于是我選擇從零搭建一個基于koa2的服務端。為什么不直接選擇egg，express，thinkjs這些更加全面的框架呢?因為我愛折騰嘛。而且這也是一個學習的過程。如果以前不了解node，又對搭建node服務端有興趣，可以看我之前的一篇文章-從零搭建Koa2 Server。

爬蟲方面我選擇了 request + cheerio 。雖然知乎有很多地方用到了react，但得益于它絕大部分頁面還是服務端渲染，所以只要能請求網頁與接口(request)，解析頁面(cherrio)即可滿足我的爬蟲需求。

其他不一一舉例了，我列個技術棧

服務端

1. koajs 做node server框架;
2. request + cheerio 做爬蟲服務;
3. mongodb 做數據存儲;
4. node-schedule 做任務調度;
5. nodemailer 做郵件推送。

客戶端

1. vuejs 前端框架;
2. museui Material Design UI庫;
3. chart.js 圖表庫。

技術選型妥善后，我們就要關心業(yè)務了。首要任務就是真正的爬取到頁面。

如何能爬取網站的數據?

知乎并沒有對外開放接口能讓用戶獲取數據，所以想獲取數據，就得自己去爬取網頁信息。我們知道即使是網頁，它本質上也是個GET請求的接口，我們只要在服務端去請求對應網頁的地址(客戶端請求會跨域)，再把html結構解析下，獲取想要的數據即可。

那為什么我要搞一個登陸呢?因為非登陸帳號獲取信息，知乎只會展現有限的數據，而且也無法得知自己知乎帳戶關注的話題、問題等信息。而且若是想自己的系統(tǒng)也給其他朋友使用，也必須搞一個帳戶系統(tǒng)。

模擬登陸

大家都會用Chrome等現代瀏覽器看請求信息，我們在知乎的登錄頁進行登陸，然后查看捕獲接口信息就能知道，登陸無非就是向一個登陸api發(fā)送賬戶、密碼等信息，如果成功。服務端會向客戶端設置一個cookie，這個cookie即是登陸憑證。

所以我們的思路也是如此，通過爬蟲服務端去請求接口，帶上我們的帳號密碼信息，成功后再將返回的cookie存到我們的系統(tǒng)數據庫，以后再去爬取其他頁面時，帶上此cookie即可。

當然，等我們真正嘗試時，會受到更多挫折，因為會遇到token、驗證碼等問題。不過，由于我們有客戶端了，可以將驗證碼的識別交給真正的 人 ，而不是服務端去解析圖片字符，這降低了我們實現登陸的難度。

一波三折的是，即使你把正確驗證碼提交了，還是會提示驗證碼錯誤。如果我們自己做過驗證碼提交的系統(tǒng)就能夠迅速的定位原因。如果沒做過，我們再次查看登陸時涉及的請求與響應，我們也能猜到：

在客戶端獲取驗證碼時，知乎服務端還會往客戶端設置一個新cookie，提交登陸請求時，必須把驗證碼與此cookie一同提交，來驗證此次提交的驗證碼確實是當時給予用戶的驗證碼。

語言描述有些繞，我以圖的形式來表達一個登陸請求的完整流程。

注：我編寫爬蟲時，知乎還部分采取圖片字符驗證碼，現已全部改為“點擊倒立文字”的形式。這樣會加大提交正確驗證碼的難度，但也并非無計可施。獲取圖片后，由 人工 識別并點擊倒立文字，將點擊的坐標提交到登陸接口即可。當然有興趣有能力的同學也可以自己編寫算法識別驗證碼。

爬取數據

上一步中，我們已經獲取到了登陸后的憑證cookie。用戶登陸成功后，我們把登陸的帳戶信息與其憑證cookie存到mongo中。以后此用戶發(fā)起的爬取需求，包括對其跟蹤問題的數據爬取都根據此cookie爬取。

當然cookie是有時間期限的，所以當我們存cookie時，應該把過期時間也記錄下來，當后面再獲取此cookie時，多加一步過期校驗，若過期了則返回過期提醒。

爬蟲的基礎搞定后，就可以真正去獲取想要的數據了。我的需求是想知道某個知乎問題的熱點趨勢。先用瀏覽器去看看一個問題頁面下都有哪些數據，可以被我爬取分析。舉個例子，比如這個問題： 有哪些令人拍案叫絕的推理橋段 。

打開鏈接后，頁面上最直接展現出來的有 關注者 ， 被瀏覽 ， 1xxxx個回答 ，還要默認展示的幾個高贊回答及其點贊評論數量。右鍵查看網站源代碼，確認這些數據是服務端渲染出來的，我們就可以通過request請求網頁，再通過cherrio，使用css選擇器定位到數據節(jié)點，獲取并存儲下來。代碼示例如下：

 

async getData (cookie, qid) { 
  const options = { 
    url: `${zhihuRoot}/question/${qid}`, 
    method: 'GET', 
    headers: { 
      'Cookie': cookie, 
      'Accept-Encoding': 'deflate, sdch, br' // 不允許gzip,開啟gzip會開啟知乎客戶端渲染，導致無法爬取 
    } 
  } 
  const rs = await this.request(options) 
  if (rs.error) { 
    return this.failRequest(rs) 
  } 
  const $ = cheerio.load(rs) 
  const NumberBoard = $('.NumberBoard-item .NumberBoard-value') 
  const $title = $('.QuestionHeader-title') 
  $title.find('button').remove() 
  return { 
    success: true, 
    title: $title.text(), 
    data: { 
      qid: qid, 
      followers: Number($(NumberBoard[0]).text()), 
      readers: Number($(NumberBoard[1]).text()), 
      answers: Number($('h4.List-headerText span').text().replace(' 個回答', '')) 
    } 
  } 
} 

這樣我們就爬取了一個問題的數據，只要我們能夠按一定時間間隔不斷去執(zhí)行此方法獲取數據，最終我們就能繪制出一個題目的數據曲線，分析起熱點趨勢。

那么問題來了，如何去做這個定時任務呢?

定時任務

我使用了 node-schedule 做任務調度。如果之前做過定時任務的同學，可能對其類似cron的語法比較熟悉，不熟悉也沒關系，它提供了not-cron-like的，更加直觀的設置去配置任務，看下文檔就能大致了解。

當然這個定時任務不是簡單的不斷去執(zhí)行上述的爬取方法 getData 。因為這個爬蟲系統(tǒng)不僅是一個用戶，一個用戶不僅只跟蹤了一個問題。

所以我們此處的完整任務應該是遍歷系統(tǒng)的每個cookie未過期用戶，再遍歷每個用戶的跟蹤問題，再去獲取這些問題的數據。

系統(tǒng)還有另外兩個定時任務，一個是定時爬取用戶關注話題的熱門回答，另一個是推送這個話題熱門回答給相應的用戶。這兩個任務跟上述任務大致流程一樣，就不細講了。

但是在我們做定時任務時會有個細節(jié)問題，就是如何去控制爬取時的并發(fā)問題。具體舉例來說：如果爬蟲請求并發(fā)太高，知乎可能是會限制此IP的訪問的，所以我們需要讓爬蟲請求一個一個的，或者若干個若干個的進行。

簡單思考下，我們會采取循環(huán)await。我不假思索的寫下了如下代碼：

 

// 爬蟲方法 
async function getQuestionData () { 
  // do spider action 
} 
 
// questions為獲取到的關注問答 
questions.forEach(await getQuestionData) 

然而執(zhí)行之后，我們會發(fā)現這樣其實還是并發(fā)執(zhí)行的，為什么呢?其實仔細想下就明白了。forEach只是循環(huán)的語法糖，如果沒有這個方法，讓你來實現它，你會怎么寫呢?你大概也寫的出來：

 

Array.prototype.forEach = function (callback) { 
  for (let i = 0; i < this.length; i++) { 
    callback(this[i], i, this) 
  } 
} 

雖然 forEach 本身會更復雜點，但大致就是這樣吧。這時候我們把一個異步方法作為參數 callback 傳遞進去，然后循環(huán)執(zhí)行它，這個執(zhí)行依舊是并發(fā)執(zhí)行，并非是同步的。

所以我們如果想實現真正的同步請求，還是需要用for循環(huán)去執(zhí)行，如下：

 

async function getQuestionData () { 
  // do spider action 
} 
for (let i = 0; i < questions.length; i++) { 
  await getQuestionData() 
} 

除了for循環(huán)，還可以通過for-of，如果對這方面感興趣，可以去多了解下數組遍歷的幾個方法，順便研究下ES6的迭代器 Iterator 。

其實如果業(yè)務量大，即使這樣做也是不夠的。還需要更加細分任務顆粒度，甚至要加代理IP來分散請求。

合理搭建服務端

下面說的點跟爬蟲本身沒有太大關系了，屬于服務端架構的一些分享，如果只關心爬蟲本身的話，可以不用再往下閱讀了。

我們把爬蟲功能都寫的差不多了，后面只要編寫相應的路由，能讓前端訪問到數據就好了。但是編寫一個沒那么差勁的服務端，還是需要我們深思熟慮的。

合理分層

我看過一些前端同學寫的node服務，經常就會把系統(tǒng)所有的接口(router action)都寫到一個文件中，好一點的會根據模塊分幾個對于文件。

但是如果我們接觸過其他成熟的后端框架、或者大學學過一些J2EE等知識，就會本能意識的進行一些分層：

 

model 
service 
controller 

當然也有些框架或者人會將業(yè)務邏輯 service 實現在 controller 中，亦或者是 model 層中。我個人認為一個稍微復雜的項目，應該是單獨抽離出抽象的業(yè)務邏輯的。

比如在我這個爬蟲系統(tǒng)中，我將數據庫的添刪改查操作按 model 層對應抽離出 service ，另外再將爬取頁面的服務、郵件推送的服務、用戶鑒權的服務抽離到對應的 service 。

最終我們的 api 能夠設計的更加易讀，整個系統(tǒng)也更加易拓展。

分層在koa上的實踐

如果是直接使用一個成熟的后端框架，分層這事我們是不用多想的。node這樣的框架也有，我之前介紹的我廠開源的 api-mocker 采用的 egg.js ，也幫我們做好了合理的分層。

但是如果自己基于koa從零搭建一個服務端，在這方面上就會遇到一些挫折。koa本身邏輯非常簡單，就是調取一系列中間件(就是一個個function)，來處理請求。官方自己提供的 koa-router ，即是幫助我們識別請求路徑，然后加載對應的接口方法。

我們?yōu)榱藚^(qū)分業(yè)務模塊，會把一些接口方法寫在同一個 controller 中，比如我的 questionController 負責處理問題相關的接口; topicController 負責處理話題相關的接口。

那么我們可能會這樣編寫路由文件：

 

const Router = require('koa-router') 
const router = new Router() 
 
const question = require('./controller/question') 
const topic = require('./controller/topic') 
 
router.post('/api/question', question.create) 
router.get('/api/question', question.get) 
 
router.get('/api/topic', topic.get) 
router.post('/api/topic/follow', topic.follow) 
 
module.exports = router 

我的question文件可能是這樣寫的：

 

class Question { 
  async get () { 
    // return data 
  } 
  async create () { 
    // create question and return data 
  } 
} 
 
module.exports = new Question() 

那么問題就來了

單純這樣寫是沒有辦法真正的以面向對象的形式來編寫 controller 的。為什么呢?

因為我們將question對象的屬性方法作為中間件傳遞到了 koa-router 中，然后由 koa 底層來合并這些中間件方法，作為參數傳遞到 http.createServer 方法中，最終由node底層監(jiān)聽請求時調用。那這個 this 到底會是誰，不進行調試，或者查看koa與node源代碼，是無從得知的。但是無論如何方法調用者肯定不是這個對象自身了(實際上它會是 undefined )。

也就是說，我們不能通過 this 來獲取對象自身的屬性或方法。

那怎么辦呢?有的同學可能會選擇將自身一些公共方法，直接寫在 class 外部，或者寫在某個 utils 文件中，然后在接口方法中使用。比如這樣：

 

const error = require('utils/error') 
 
const success = (ctx, data) => { 
  ctx.body = { 
    success: true, 
    data: data 
  } 
} 
 
class Question { 
  async get () { 
    success(data) 
  } 
  async create () { 
    error(result) 
  } 
} 
 
module.exports = new Question() 

這樣確實ok，但是又會有新的問題---這些方法就不是對象自己的屬性，也就沒辦法被子類繼承了。

為什么需要繼承呢?因為有時候我們希望一些不同的 controller 有著公共的方法或屬性，舉個例子：我希望我所有的成功or失敗都是這樣的格式：

 

{ 
  success: false, 
  message: '對應的錯誤消息' 
} 
{ 
  success: true, 
  data: '對應的數據' 
} 

按照 koa 的核心思想，這個通用的格式轉化，應該是專門編寫一個中間件，在路由中間件之后(即執(zhí)行完controller里的方法之后)去做專門處理并response。

然而這樣會導致每有一個公共方法，就必須要加一個中間件。而且 controller 本身已經失去了對這些方法的控制權。這個中間件是執(zhí)行自身還是直接 next() 將會非常難判斷。

如果是抽離成 utils 方法再引用，也不是不可以，就是方法多的話，聲明引用稍微麻煩些，而且沒有抽象類的意義。

更理想的狀態(tài)應該是如剛才所說的，大家都繼承一個抽象的父類，然后去調用父類的公共相應方法即可，如:

 

class AbstractController { 
  success (ctx, data) { 
    ctx.body = { 
      success: true, 
      data: data 
    } 
  } 
  error (ctx, error) { 
    ctx.body = { 
      success: false, 
      msg: error 
    } 
  } 
} 
class Question extends AbstractController { 
  async get (ctx) { 
    const data = await getData(ctx.params.id) 
    return super.success(ctx, data) 
  } 
} 

這樣就方便多了，不過如果寫過koa的人可能會有這樣的煩惱，一個上下文 ctx 總是要作為參數傳遞來傳遞去。比如上述控制器的所有中間件方法都得傳 ctx 參數，調用父類方法時，又要傳它，還會使得方法損失一些可讀性。

所以總結一下，我們有如下問題：

 

controller 
ctx 

解決它

其實解決的辦法很簡單，我們只要想辦法讓 controller 方法中的this指向實例化對象自身，再把 ctx 掛在到這個 this 上即可。

怎么做呢?我們只要再封裝一下 koa-router 就好了，如下所示：

 

const Router = require('koa-router') 
const router = new Router() 
const question = require('./controller/question') 
const topic = require('./controller/topic') 
 
const routerMap = [ 
  ['post', '/api/question', question, 'create'], 
  ['get', '/api/question', question, 'get'], 
  ['get', '/api/topic', topic, 'get'], 
  ['post', '/api/topic/follow', topic, 'follow'] 
] 
 
routerMap.map(route => { 
  const [ method, path, controller, action ] = route 
 
  router[method](path, async (ctx, next) => 
    controller[action].bind(Object.assign(controller, { ctx }))(ctx, next) 
  ) 
}) 
 
module.exports = router 

大意就是在路由傳遞 controller 方法時，將 controller 自身與 ctx 合并，通過 bind 指定該方法的 this 。這樣我們就能通過 this 獲取方法所屬 controller 對象的其他方法。此外子類方法與父類方法也能通過 this.ctx 來獲取上下文對象 ctx 。

但是 bind 之前我們其實應該考慮以下，其他中間件以及koa本身會不會也干了類似的事，修改了this的值。如何判斷呢，兩個辦法：

1. 調試。在我們未 bind 之前，在中間件方法中打印一下 this ，是 undefined 的話自然就沒被綁定。
2. 看koa-router/koa/node的源代碼。

事實是，自然是沒有的。那我們就放心的 bind 吧。

寫在***

上述大概就是編寫這個小工具時，遇到的一些點，感覺可以總結的。也并沒有什么技術難點，不過可以借此學習學習一些相關的知識，包括網站安全、爬與反爬、、koa底層原理等等。

這個工具本身非常的個人色彩，不一定滿足大家的需要。而且它在半年前就寫好了，只不過最近被我挖墳拿出來總結。而且就在我即將寫完文章時，我發(fā)現知乎提示我的賬號不安全了。我估計是以為同一IP同一賬戶發(fā)起過多的網絡請求，我這臺服務器IP已經被認為是不安全的IP了，在這上面登錄的賬戶都會被提示不安全。所以我不建議大家將其直接拿來使用。

當然，如果還是對其感興趣，本地測試下或者學習使用，還是沒什么大問題的?；蛘哌€有更深的興趣的話，可以自己嘗試去繞開知乎的安全策略。