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 也有待考慮。比如,頁面中的一些靜态内容可能會在其他頁面中重複使用到,複用就成了問題。
作者:lucas_580e331d326b4
來源:51cto