教你編寫 Node.js 中介軟體,實現服務端快取(附demo原始碼)

LucasHC發表於2019-03-03

Express 作為 Node.js 的框架,如今發展可謂如日中天。我很喜歡其靈活、易擴充套件的設計理念。尤其是該框架的中介軟體架構設計:使得在應用中加入新特性更加標準化、成本最小化。這篇文章,我會嘗試編寫一個非常簡單、小巧的中介軟體,完成服務端快取功能,進而優化效能。

關於中介軟體

說到中介軟體,Express 官網對它的闡述是這樣的:

“Express 是一個自身功能極簡,完全是路由和中介軟體構成一個web開發框架:從本質上來說,一個 Express 應用就是在呼叫各種中介軟體。”

也許你使用過各種各樣的中介軟體進行開發,但是可能並不理解中介軟體原理,也沒有深入過 Express 原始碼,探究其實現。這裡並不打算長篇大論幫您分析,但是使用層面上大致可以參考下圖:

中介軟體原理
中介軟體原理

建議有興趣、想深入的讀者自己分析,有任何問題歡迎與我討論。即便您不打算深入,也不會影響對下文中介軟體編寫的理解。

關於服務端快取

快取已經被廣泛應用,來提高頁面效能。一說到快取,可能讀者腦海裡馬上冒出來:“客戶端快取,CDN 快取,伺服器端快取……”。另一維度上,也會想到:“200(from cache),expire,eTag……”等概念。

當然作為前端開發者,我們一定要明白這些快取概念,這些快取理念是相對於某個具體使用者訪問來說的,效能優化體現在單個使用者上。比如說,我第一次開啟頁面 A,耗時超長,下一次開啟頁面由於快取的作用,時間縮短了。

但是在伺服器端,還存在另外一個維度,思考一下這樣的場景:

我們有一個靜態頁面 B,這個頁面服務端需要從資料庫獲取部分資料 b1,根據 b1 又要計算得到部分資料 b2,還得做各種高複雜度操作,最終才能“東拼西湊”出需要返回的完整頁面 B,整個過程耗時2s。

那麼面臨的災難就是,user1 開啟頁面耗時2s,user2同樣開啟頁面耗時2s……而這些頁面都是靜態頁面 B,內容是完全一樣的。為了解決這個災難,這時候我們也需要快取,這種快取就叫先做服務端快取(server-side cache)。

總結一下,服務端快取的目的其實就是對於同一個頁面請求,而返回(快取的)同樣的頁面內容。這個過程完全獨立於不同的使用者。

上面的話有些拗口,可以參考英文表達更清晰:

The goal of server side cache is responding to the same content for the same request independently of the client’s request.

因此,下面展示的 demo 在第一次請求到達時,服務端耗費5秒來返回 HTML;而接下來再次請求該頁面,將會命中快取,不過是哪個使用者訪問,只需要幾毫秒便可得到完整頁面。

Show me the code & Demo

其實上文提到的快取概念非常簡單,稍微有些後端經驗的同學都能很好理解。但是這篇文章除去科普基本概念外,更重要的就是介紹 Express 中介軟體思想,並自己來實現一個服務端快取中介軟體。

讓我們開工吧!
最終 Demo 程式碼,歡迎訪問它的Github地址

我將會使用 npm 上 memory-cache 這個包,以方便進行快取的讀寫。最終的中介軟體程式碼很簡單:

`use strict`

var mcache = require(`memory-cache`);

var cache = (duration) => {
  return (req, res, next) => {
    let key = `__express__` + req.originalUrl || req.url
    let cachedBody = mcache.get(key)
    if (cachedBody) {
      res.send(cachedBody)
      return
    } else {
      res.sendResponse = res.send
      res.send = (body) => {
        mcache.put(key, body, duration * 1000);
        res.sendResponse(body)
      }
      next()
    }
  }
}複製程式碼

為了簡單,我使用了請求 URL 作為 cache 的 key:

  • 當它(cache key)及其對應的 value 值存在時,便直接返回其 value 值;
  • 當它(cache key)及其對應的 value 值不存在時,我們將對 Express send 方法做一層攔截:在最終返回前,存入這對 key-value。

快取的有效時間是10秒。

最終在判斷之外,我們的中介軟體把控制權交給下一個中介軟體。

最終使用和測試如下程式碼:

app.get(`/`, cache(10), (req, res) => {
  setTimeout(() => {
    res.render(`index`, { title: `Hey`, message: `Hello there`, date: new Date()})
  }, 5000) //setTimeout was used to simulate a slow processing request
})複製程式碼

我使用了 setTimeout 來模擬一個超長(5s)的操作。

開啟瀏覽器控制皮膚,發現在10秒快取到期以內:

載入資訊
載入資訊

至於為什麼 cache 中介軟體要那樣子寫、next() 為什麼是中介軟體把控制權傳遞,我並不打算展開去講。有興趣的讀者可以看一下 Express 原始碼。

還有幾個小問題

仔細看我們的頁面,再去體會一下實現程式碼。也許細心的讀者能發現一個問題:剛才的實現我們快取了整個頁面,並將 date: new Date() 傳入了 jade 模版 index.jade 裡。那麼,在命中快取的條件下,10秒內,頁面無法動態重新整理來同步,直到10秒快取到期。

同時,我們什麼時候可以使用上述中介軟體,進行服務端快取呢?當然是靜態內容才可以使用。同時,PUT, DELETE 和 POST 操作都不應該進行類似的快取處理。

同樣,我們使用了 npm 模組:memory-cache,它存在優缺點如下:

  • 讀寫迅速而簡單,不需要其他依賴;
  • 當伺服器或者這個程式掛掉的時候,快取中的內容將會全部丟失。
  • memcache 是將快取內容存放在了自己程式的記憶體中,所以這部分內容是無法在多個 Node.js 程式之間共享的。

如果這些弊端 really matter,在實際開發中我們可以選擇分散式的 cache 服務,比如 Redis。同樣你可以在 npm 上找到:express-redis-cache 模組使用。

總結

在真實的開發場景中,服務端快取已經成為 common sense,但是在 Node.js 的世界裡,體會其中介軟體思想,自己手動編寫服務,同樣樂趣無窮。

與實踐相結合,我認為真正快取整個頁面(如同 demo 那樣)並不是一個推薦的做法(當時實際場景實際分析),同樣使用請求 url 作為快取的 key 也有待考慮。比如,頁面中的一些靜態內容可能會在其他頁面中重複使用到,複用就成了問題。

真實場景下,一切設計和邏輯都要為自己業務情況所負責。脫離需求談實現,都是耍流氓。這個 demo 簡易輕巧,有需要的讀者可以訪問它的Github地址,歡迎玩出各種花樣。

Happy Coding!

PS:
作者Github倉庫知乎問答連結
歡迎各種形式交流。

相關文章