Koa2 還有多久取代 Express

前言

Koa 是執行在 Node.js 中的 web 服務框架，小而美。

Koa2 是 Koa 框架的最新版本，Koa3 還沒有正式推出，Koa1 正走在被替換的路上。

Koa2 與 Koa1 的最大不同，在於 Koa1 基於 co 管理 Promise/Generator 中介軟體，而 Koa2 緊跟最新的 ES 規範，支援到了 Async Function（Koa1 不支援），兩者中介軟體模型表現一致，只是語法底層不同。

Koa2 正在蠶食 Express 的市場份額，最大的原因是 Javascript 的語言特性進化，以及 Chrome V8 引擎的升級，賦予了 Node.js 更大的能力，提升開發者的程式設計體驗，滿足開發者靈活定製的場景以及對於效能提升的需求，蠶食也就水到渠成，2018 年開始，Koa2 會超越 Express 成為本年最大普及量的 Node.js 框架。

以上就是 Koa2 的現狀，以及它的趨勢，站在 2018 年的節點來看，Koa2 的學習大潮已經到來，那麼如果要掌握 Koa2，需要去學習它的哪些知識呢，這些知識跟 Node.js 以及語言規範有什麼關係，它的內部組成是如何的，執行機制怎樣，定製擴充是否困難，以及它的三方庫生態如何，應用場景有哪些，跟前端有如何結合等等，這些問題本文將做簡要的探討，Koa2 詳細的程式碼案例和深度剖析見這裡 。

備註：如下提到的 Koa 均指代 Koa 2.x 版本

關於作者 TJ

瞭解過 TJ 的童鞋都知道，他以驚為天人的程式碼貢獻速度、源源不斷的開發熱情和巧奪天工的程式設計模型而推動整個 Node.js/NPM 社群大步邁進，稱為大神毫不過分，而大神的腦回路，向來與凡人不同。

關於大神的傳說有很多，最有意思的是在國外著名程式設計師論壇 reddit 上，有人說，TJ 從來就不是一個人，一個人能有這麼高效而瘋狂的程式碼產出實在是太讓人震驚了，他背後一定是一個團隊，因為他從來都不參加技術會議，也不見任何人，而最後 TJ 離開 Node 社群去轉向 Go，這種做事方式非常谷歌，所以 TJ 是谷歌的一個招牌，大家眾說紛紜，吵的不可開交，不過有一點大家都是達成共識的，那就是非常肯定和感謝他對於 Nodejs 社群的貢獻和付出。

Express 的架構和中介軟體模型

聊 Koa 之前，先對比下 Express，在 Express 裡面，不同時期的程式碼組織方式雖然大為不同，比如早期是全家桶各種路由、表單解析都囊括到一個專案中，中後期做了大量的拆分，將大部分模組都獨立出來官方自行維護，或者是採用社群其他開發者提供的中介軟體模組，但縱觀 Express 多年的歷程，他依然是相對大而全，API 較為豐富的框架，並且它的整個中介軟體模型是基於 callback 回撥，而 callback 常年被人詬病。

對於一個 web 服務框架來說，它的核心流程，就是在整個 HTTP 進入到流出的過程中，從它的流入資料上採集所需要的引數素材，再向流出的資料結構上附加期望素材，無論是一個靜態檔案還是 JSON 資料，而在採集和附加的過程中，需要各個中介軟體大佬的參與，有的乾的是記錄日誌的活兒，有的乾的是解析表單的活兒，有的則是管理會話，既然是大佬，一般都脾氣大，你不安排好他們的註冊順序，不通過一種機制管理他們的入場退場順序，他們不僅不好好配合，還可能砸了你的場子。

那麼 Express 裡面，首先就是對於 HTTP 這個大傢伙的管理（其他協議先不涉及），管理這個大傢伙，Express 祭出了三件，哦不，其實是四件法寶。 首先是通過 express() 拿到的整個伺服器執行例項，這個例項相當於是一個酒店，而你就是來訪的客人 - HTTP 請求，酒店負責你一切需求，做到你滿意。 在酒店裡面，還有兩個工作人員，一個是 req(request) 負責接待你的叫阿來吧，還有一個送你離開的狠角色 - res(response)，叫阿去吧，阿來接待到你進酒店，門口的攝像頭會你拍照（Log 記錄來去時間，你的特徵），收集你的指紋（老會員識別），引領你去前臺簽到（獲取你的需求，比如你要拿走屬於你的一套西服），然後酒店安排你到房間休息（等待響應），裡面各種後勤人員忙忙碌碌接待不同的客人，其中有一個是幫你取西服的，取了後，交給阿來，阿來再把西服穿你身上，同時還可能幫你裝飾一番，比如給你帶個帽子（加個自定義頭），然後送你出門，門口的攝像頭還會拍你一下，就知道了酒店服務你的時間......實在編不下去了，想用物理世界的案例來對應到程式世界是蠻難的，嚴謹度不夠，不過幫新手同學留下一個深刻印象倒是可取的。

Express 原始碼簡要分析

上面酒店的 4 件法寶，其實就是伺服器執行例項，req 請求物件，res 響應物件和中介軟體 middlewares，剛才負責照相的，簽到的，分析需求的其實都是中介軟體，一個一個濾過去，他們根據自己的規則進行採集、分析、轉化和附加，把這個 HTTP 客人，從頭到腳捏一遍，客人就舒舒服服的離開了。

中介軟體是眾多 web 框架中比較核心的概念，它們可以根據不同的場景，來整合到框架中，增強框架的服務能力，而框架則需要提供一套機制來保證中介軟體是有序執行，這個機制在不同的框架中則大為不同，在 Express 裡面，我們通過 use(middlewares()) 逐個 use 下去，use 的順序和規則都由 express 自身控制。 在 express/express.js 中，伺服器執行例項 app 通過 handle 來把 Nodejs 的 req 和 res 傳遞給 handle 函式，賦予 handle 對於內部物件的控制權:

app = function(req, res, next) {
  app.handle(req, res, next)
}
複製程式碼

而在 express/application.js 中，拿到控制權的 handle 又把請求響應和回撥，繼續分派給了 express 的核心路由模組，也就是 router:

app.handle = function handle (req, res, callback) {
  var router = this._router
  var done = callback || finalhandler(req, res, {
    env: this.get('env'),
    onerror: logerror.bind(this)
  })
  router.handle(req, res, done)
}
複製程式碼

這裡的 router.handle 就持有到了 req, res 物件，可以理解為，express 把 Nodejs 監聽到的請求三要素（req, res, cb） 下放給了內部的路由模組 router。 然後繼續回到剛才 use(middlewares()，Express 每一次 use 中介軟體，都會把這個中介軟體也交給 router：

app.use = function use(fn) {
  router.use('/', fn)
}
複製程式碼

而 router 裡面，有很重要一個概念，就是 layer 層，可以理解為中介軟體堆疊的層，一層層堆疊起來：

var layer = new Layer(path, {
  sensitive: this.caseSensitive,
  strict: false,
  end: false
}, fn)
this.stack.push(layer)
複製程式碼

以上是虛擬碼（刪減了大部分），可以看做是 express 在啟動執行的時候，註冊好了一箇中介軟體函式棧，裡面堆疊好了待被呼叫的中介軟體，一旦請求進來，就會被 router handle 來處理：

proto.handle = function handle(req, res, out) {
  next()
  function next(err) {
    var layer
    var route
    self.process_params(layer, paramcalled, req, res, function (err) {
      if (route) {
        return layer.handle_request(req, res, next)
      }
      trim_prefix(layer, layerError, layerPath, path)
    })
  }
  function trim_prefix(layer, layerError, layerPath, path) {
    if (layerError) {
      layer.handle_error(layerError, req, res, next)
    } else {
      layer.handle_request(req, res, next)
    }
  }
}
複製程式碼

handle 裡面的 next 是整個中介軟體棧能夠轉起來的關鍵，在所有的中介軟體裡面，都要執行這個 next，從而把當前的控制權以回撥的方式往下面傳遞。 但是問題就是這種機制在最初的時候，如果沒有事件的配合，是很難做到原路進去，再順著原路回去，相當於是每個中介軟體都被來回濾了 2 遍，賦予中介軟體更靈活的控制權，這就是掣肘 Express 的地方，也是 Express 市場一定會被 Koa 蠶食的重要原因。

具體 Express 的程式碼比這裡描述的要複雜好幾倍，大家有興趣可以去看原始碼，應該會有更多的收穫，如果沒有 Koa 這種框架存在的話，Express 的內部實現用精妙形容絕對不為過，只是這種相對複雜一些的內部中介軟體機制，未必符合所有人的口味，也說明了早些年限於 JS 的能力，想要做一些流程雙向控制多麼困難。 關於 Express 就分析到這裡，這不是本文的重點，瞭解它內部的複雜度以及精妙而複雜都實現就可以了，因為這是特定歷史階段的歷史產物，有它特定的歷史使命。

早期的 Koa 模型 - 我們不一樣

得益於大神非同尋常的腦回路，Koa 從一開始就選擇了跟 Express 完全不同的架構方向，上面 Express 的部分大家沒看懂也沒關係，因為 Koa 這裡的處理，會讓你瞬間腦回路清晰。

首先要明白，Koa 與 Express 是在做同樣事情上的不同實現，所以意味著他倆對外提供的能力大部分是相同的，這部分不贅述，我們看不同的地方：

Koa 內部也有幾個神行太保，能力較大，首先 new Koa() 出來的伺服器執行例項，它像青蛙一樣，張大嘴吞食所有的請求，通過它可以把服務真正跑起來，跟 Express 一樣，這個就跳過不提了，重點是它的 context，也就是 ctx，這貨上面有很多引用，最核心的是 request 和 response，這倆可以對應到 Express 兩個對立的 req 和 res，在 Koa 裡面，把它倆都集中到 ctx 裡面進行管理，分別通過 ctx.request 和 ctx.reponse 進行直接訪問，原來 Express 兩個獨立物件做的事情，現在一個 ctx 就夠了，上下文物件都在他手中，想要聯絡誰就能聯絡誰。 其次是它的中介軟體機制，Koa 真正的魅力所在，先看段程式碼：

const Koa = require('koa')
const app = new Koa()
const indent = (n) => new Array(n).join(' ')
const mid1 = () => async (ctx, next) => {
  ctx.body = `<h3>請求 => 第一層中介軟體</h3>`
  await next()
  ctx.body += `<h3>響應 <= 第一層中介軟體</h3>`
}
const mid2 = () => async (ctx, next) => {
  ctx.body += `<h3>${indent(4)}請求 => 第二層中介軟體</h3>`
  await next()
  ctx.body += `<h3>${indent(4)}響應 <= 第二層中介軟體</h3>`
}
app.use(mid1())
app.use(mid2())
app.use(async (ctx, next) => {
  ctx.body += `<p style="color: #f60">${indent(12)}=> Koa 核心 處理業務 <=</p>`
})
app.listen(2333)
複製程式碼

大家可以把這 22 行程式碼跑起來，瀏覽器裡訪問 localhost:2333 就能看到程式碼的執行路徑，一個 HTTP 請求，從進入到流出，是兩次穿透，每一箇中介軟體都被穿透兩次，這個按照次序的正向進入和反向穿透並不是必選項，而是 Koa 輕鬆具備的能力，同樣的能力，在 Express 裡面實現反而很費勁。

Koa2 原始碼簡要分析

想要了解上面提到的能力，就要看下 Koa 核心的程式碼： 同樣是 app.use(middlewares())，在 koa/application.js 裡面，每一箇中介軟體同樣被壓入到一個陣列中：

use(fn) {
  this.middleware.push(fn)
}
複製程式碼

在伺服器啟動的時候，建立監聽，同時註冊回撥函式：

listen(...args) {
  server = http.createServer(this.callback()).listen(...args)
}
複製程式碼

回撥函式裡面，返回了 (req, res) 給 Node.js 用來接收請求，在它內部，首先基於 req, res 建立出來 ctx，就是那個同時能管理 request 和 response 的傢伙，重點是上面壓到陣列裡面的 middlewares 被 compose 處理後，就扔給了 handleRequest：

callback() {
  const fn = compose(this.middleware)
  return handleRequest = (req, res) => {
    const ctx = this.createContext(req, res)
  
    return this.handleRequest(ctx, fn)
  }
}
複製程式碼

compose 就是 koa-compose，簡單理解為通過它，以遞迴的方式實現了 Promise 的鏈式執行，因為我們都知道， async function 本質上會返回一個 Promise，這裡 compose 跳過不說了，繼續去看 handleRequest:

handleRequest(ctx, fnMiddleware) {
  return fnMiddleware(ctx).then(respond(ctx))
}
複製程式碼

實在是簡潔的不像實力派，請求進來後，會把可以遞迴呼叫的中介軟體陣列都執行一遍，每個中介軟體都能拿到 ctx，同時，因為 async function 的語法特性，可以中介軟體中，把執行權交給後面的中介軟體，這樣逐層逐層交出去，最後再逐層逐層執行回來，就達到了請求沿著一條路進入，響應沿著同樣的一條路反向返回的效果。 借用官方文件的一張圖來表達這個過程：

我知道這張圖還不夠，再祭出官方的第二張圖，著名的洋蔥模型：

Koa2 要學習什麼

從上面的對比，我們其實就發現了 Koa2 獨具魅力的地方，這些魅力一方面跟框架設計理念有關，一方面跟語言特性有關，語言特性，無外乎下面幾個：

• 箭頭函式
• Promise 規範
• 迭代器生成器函式執行原理
• 非同步函式 Async Function
• 以及 Koa2 的應用上下文 ctx 的常用 API（也即它的能力）
• koa-compose 工具函式的遞迴特徵
• 中介軟體執行的進出順序和用法

這些都是基礎性的值得學習的，這些知識跟著語言規範有著非常親近的關係，所以意味著學會這些以後，也需要去到 ES6/7/8 裡面挑選更多的語法特性，早早入坑學習，限於篇幅本文均不再探討，上面的基礎知識學習如果有興趣，可以跟著 Koa2解讀+資料抓取+實戰電影網站 瞭解更多實戰姿勢。

Koa2 和 Express 到底如何選擇

能不能來個痛快話？其實可以的，選 Koa2 吧，2018 年了，不用等了。 同時一定非它不可麼，其實也不是，我們可以更加客觀的看待選擇問題，再梳理下思緒：

Koa 是基於新的語法特性，實現了 Promise 鏈傳遞，錯誤處理更友好，Koa 不繫結任何中介軟體，是乾乾淨淨的裸框架，需要什麼就加什麼，Koa 對流支援度很好，通過上下文物件的交叉引用讓內部流程與請求和響應串聯的更緊湊，如果 Express 是大而全，那麼 Koa 就是小而精，二者定位不同，只不過 Koa 擴充套件性非常好，稍微組裝幾個中介軟體馬上就能跟 Express 匹敵，程式碼質量也更高，設計理念更先進，語法特性也更超前。

這是站在使用者的角度比較的結果，如果站在內部實現的角度，Koa 的中介軟體載入和執行機制跟 Express 是截然不同的，他倆在這一點上的巨大差別也導致了一個專案可以完全走向兩種不同的中介軟體設計和實現方式，不過往往我們是作為框架的使用者，業務的開發者來使用的，那麼對於 Nodejs 的使用者來說，Express 能滿足你的，Koa 都可以滿足你，Express 讓你爽的，Koa 可以讓你更爽。

這也是為什麼，阿里的企業級框架 Eggjs 底層是 Koa 而不是 Express，360 公司的大而全的 thinkjs 底層也是 Koa，包括沃爾瑪的 hapi 雖然沒有用 Koa，但是他的核心開發者寫部落格說，受到 Koa 的衝擊和影響， 也要升級到 async function，保持對語法的跟進，而這些都是 Koa 已經做好了整個底子，任何上層架構變得更簡單了。

大家在選用 Express 的時候，或者從 Express 升級到 Koa 的時候，其實不用太糾結，只要成本允許，都可以使用，如果實現成本過高，那麼用 Express 也沒問題的，遇到其他新專案的時候，沒有了歷史包袱，在用 Koa 也不遲。

Koa 執行機制和 Nodejs 事件迴圈

其實通過上面的篇幅，我們對於內部組成基本瞭解了，執行機制其實就是中介軟體執行機制，而定製擴充性，我們上面提到了 Eggjs 和 Thinkjs 已經充分證明了它可定製的強大潛力，這裡我們主要聊下跟執行機制相關的，一個是 Koajs 自身，另外的一個是通過它向下到 Node.js 底層，它的執行機制是怎樣的，這塊涉及到 Libuv 的事件迴圈，如果不瞭解的話，很難在 Node.js 這顆技能樹上再進一臺階，所以它也非常重要。

而 Libuv 的事件迴圈，本質上決定了 Node.js 的非同步屬性和非同步能力，提到非同步，我們都知道 Node.js 的非同步非阻塞 IO，但是大家對於 同步非同步以及阻塞非阻塞，都有了自己的理解，說到非同步 IO，其實往往我們說的是作業系統所提供的非同步 IO 能力，那首先什麼是 IO，說白了，就是資料進出，人機互動的時候，我們會把鍵盤滑鼠這些外設看做是 Input，也就是輸入，對應到主機上，會有專門流入資料或者訊號的物理介面，顯示器作為一個視覺化的外設，對應到主機上，會有專門的輸出資料的介面，這就是生活中我們可見的 IO 能力，這個介面再向下，會進入到作業系統這個層面，在作業系統層面，會提供諸多的能力，比如磁碟讀寫，DNS 查詢，資料庫連線，網路請求接收與返回等等，在不同的作業系統中，他們表現出來的特徵也不一致，有的是純非同步的，非阻塞的，有的是同步的阻塞的，無論怎麼樣，我們都可以把這些 IO 看做是上層應用和下層系統之間的資料互動，上層依賴於下層，上層也可以進一步對這些能力進行定製改造，如果這個互動是非同步的非阻塞的，那麼這種就是 非同步 IO 模型，如果是同步的阻塞的，那麼就是同步 IO 模型。

在 Nodejs 裡面，我們可以拿檔案讀寫為例，Koa 只是一個上層的 web 應用服務框架而已，它所有與作業系統之家的溝通能力，都建立在 Node.js 整個的通訊服務模型的基礎之上，Nodejs 提供了 filesystem 也就是 fs 這個模組，模組中提供了檔案讀寫的介面，比如 readFile 這個非同步的介面，它就是一個典型的非同步 IO 介面，反之 readFileSync 就是一個阻塞的同步 IO 介面，以這個來類推，我們站在上層的 web 服務這個層面，就很容易理解 Node.js 的非同步非阻塞模型，非同步 IO 能力。

那麼 Node.js 的非同步能力又是建立在 Libuv 這一層的幾個階段上的，什麼？還有階段？

是的，Node.js 的底層除了解釋和執行 JS 程式碼的 Chrome V8 虛擬機器，還有一大趴兒就是 Libuv，它跟作業系統互動，封裝了不同平臺的諸多介面，相當於抹平了作業系統的非同步差異帶來的相容性，讓 Node.js 對外提供一致的同非同步 API，而 Libuv 的幾個階段，便是對於單執行緒的 JS 最有利的輔助實現，所有的非同步都可以看做是任務，任務是耗時的，libuv 把這些任務分成不同型別，分到不同階段，有他們各自的執行規律和執行優先順序。

大家可以先預測下下面這段程式碼的執行結果：

const EventEmitter = require('events')
class EE extends EventEmitter {}
const yy = new EE()
yy.on('event', () => console.log('粗大事啦'))
setTimeout(() => console.log('0 毫秒後到期的定時器回撥'), 0)
setTimeout(() => console.log('100 毫秒後到期的定時器回撥'), 100)
setImmediate(() => console.log('immediate 立即回撥'))
process.nextTick(() => console.log('process.nextTick 的回撥'))
Promise.resolve().then(() => {
  yy.emit('event')
  process.nextTick(() => console.log('process.nextTick 的回撥'))
  console.log('promise 第一次回撥')
})
.then(() => console.log('promise 第二次回撥'))
複製程式碼

你會發現你踏入了一個 【美好】 的世界，這就是我們通過了解 Koa 以後，如果想要繼續往下學習，需要掌握的知識，這塊知識才是真正的乾貨，一言半語的確說不清楚，我們保留思路往下走。

Koa2 的三方庫生態如何

在 Koa1 時代和 Koa2 剛出的時候，的確它的三方庫不多，需要自己動手包裝，甚至還有 koa-convert 專門幹這個活兒，把 1 代 koa 中介軟體轉成可以相容 2 代 koa 可以相容的形式。

但是時至今日，Koa2 的生態已經相當完善了，尤其在 2018 年隨著更多開發者切入到 Koa2 中，將會有大批量的業界優秀模組庫進入到 Koa2 的大池子中，大家會發現可選擇的越來越多，所以他的生態沒問題。

跟前端如何結合

到這裡，本文接近尾聲了，我也感覺意猶未盡，但是再寫下去怕是成飛流直下三千尺了，我想用一句話回答這個問題： 小而美是每一個工程師最終會選擇自我修養，Koa2 是小而美的，能與它結合的必然也是小而美的，那麼在 2018 年，就非 Parcel 莫屬，小而美絕配，關於 Parcel 如何 AntDesign/React/Bootstrap 等這些前端框架庫組合使用，可以關注 Koa2解讀+資料抓取+實戰電影網站 瞭解更多姿勢。

回到本文的標題：Koa2 還有多久取代 Express？我想完全替代是不可能的，但是新專案使用 Koa2（以及基於它封裝的框架）將會在數量上碾壓 Express，時間呢，2018 - 2019 兩年足矣，那麼 2018 年起，但求不落後，加油！

封面圖來自 codetrick