摘要：前言目前最新版本是所以本文分析也基于這個版本。源碼分析直接切入主題由于目前是一個獨立的路由和中間件框架。所以分析的方向也以這兩個為主。源碼去年的時候有分析過現在對比分析思考下。

目前express最新版本是4.16.2,所以本文分析也基于這個版本。目前從npm倉庫上來看express使用量挺高的,express月下載量約為koa的40倍。所以目前研究下express還是有一定意義的。

直接切入主題,由于目前express是一個獨立的路由和中間件web框架。所以分析的方向也以這兩個為主。源碼的研究只注重關鍵步驟和流程思想, 具體的hack,異常,邊界處理不做過多精力關注。

/**
 * //負責具體請求的邏輯處理,當一維layer中所對應的stack執行完后執行done(目的是為了一維路由列表中進行下一個路由的匹配執行)。
 * @param done(路由中的next)
 */
Route.prototype.dispatch = function dispatch(req, res, done) {
    var idx = 0;
    var stack = this.stack;
    next();
    //遞歸方式執行stack中的layer,通過next控制流程的執行
    function next(err) {
        // 出錯直接退出當前stack和路由列表中回調的后續執行
        if (err && err === "router") {
            return done(err)
        }
        //出錯直接退出當前stack列表后續執行,進行下一個路由匹配
        if (err && err === "route") {
            return done();
        }
        var layer = stack[idx++];
        //執行結束
        if (!layer) {
            return done(err);
        }
        if (layer.method && layer.method !== method) {
            return next(err);
        }
            //調用具體注冊好的邏輯
        if (err) {
            layer.handle_error(err, req, res, next);
        } else {
            layer.handle_request(req, res, next);
        }
    }
};

說明 上面是源碼的部分摘要,去除了無關的信息,對關鍵步驟加了注解。

/**
 * 對具體請求進行路由分發處理
 * out 是最后一個處理器,默認是請求的回調,不傳的話是內部提供的error handlers
 */
proto.handle = function handle(req, res, out) {
    var self = this;
    var idx = 0;
    var paramcalled = {};
    // middleware 和 roues
    var stack = self.stack;
    var done = restore(out, req, "baseUrl", "next", "params");

    next();
    //遞歸方式遍歷注冊的一維路由
    function next(err) {
        var layerError = err === "route"
            ? null
            : err;
        var layer,match,route;
        //取出注冊好的路由,進行請求匹配
        while (match !== true && idx < stack.length) {
            layer = stack[idx++];
            //req的path匹配,如果有注冊參數路由會解析參數到layer.params上
            match = matchLayer(layer, path);
            route = layer.route;
        }

        if (match !== true) {
            return done(layerError);
        }
        //將解析好的路徑參數放到請求對象上,以便后續參數回調邏輯的使用
        req.params = layer.params;

         //路徑參數回調回調  ,例如請求 /user/1 ,參數回調 app.param("user",cb1) app.get("/user/:user",cb2)   會先執行注冊的param cb1,然后才會是router中注冊的cb2
        self.process_params(layer, paramcalled, req, res, function (err) {
            if (err) {
                return next(layerError || err);
            }
            if (route) {
                return layer.handle_request(req, res, next);
            }

        });
    }
};

說明 上面摘取了請求進行路由分發處理的關鍵步驟,并做了相應的注解。

當一個請求過來的時候交給handler方法,進行路由的匹配,以遞歸的方式遍歷(路由匹配一節中介紹過),當匹配到某一個路由的時候在dispatch執行,web應用啟動初始化前注冊好的回調邏輯,執行的方式也是以遞歸的方式(中間件執行一節中介紹過)。
請求匹配執行邏輯已經介紹過了,下面結合著初始化的邏輯,進行分析,具體如下圖所示。

說明

針對上圖做一下說明,啟動服務應用的時候先進行初始化,注冊"/jsdt"的get請求,并給路由綁定相應的回調。其中我們的路由放在一維的layer中,每一層路由,例如"/jsdt"又對應一個處理列表,這個二維列表里又存儲著一系列layer(具體的回調處理邏輯),因為一維layer中已經記錄了路徑"/jsdt",所以二維的layer中就不用記錄路徑了,給個默認值"/",以保持一維layer和二維layer中結構的統一。

當一個請求過來的時候先去一維layer所存儲的路由中進行路徑匹配,以遞歸的方式。匹配到了,通過dispatch方法,在執行路由所對應的二維layer中的回調邏輯,也是以遞歸的方式執行,在遞歸的過程中,如果發生異常,通過路由中傳遞過來的out,直接進行下一個路由的匹配。

/**
 *遞歸執行stack中的handle
 * @param out  路由中的next
 */
Route.prototype.dispatch = function (req, res, out) （xxx）

當執行遇到res.end()的時候,數據響應完后,整個請求響應過程就結束了。

kao源碼去年的時候有分析過,現在對比分析思考下。
koa比較迷你,微內核,拓展性強,所以一些web框架例如阿里的eggjs就是基于koa。而express集成了路由和static中間件所以顯得重一些。

網上很多文章都說一個是線性的,一個是洋蔥模型。因為兩個我都研究過,我覺的這種說法不對,其實執行的時候都是洋蔥形。主要的區別是koa內核底層原生支持async語法,koa中的middlewares經過compose以后,每次執行到await next返回的都是一個promise,所以我們可以在頂層加一個try……catch進行異常捕獲,這算是koa比較方便的一點。還有一點很多人提到過說koa可以記錄處理時間,那是因為每次res.body賦值的時候并沒有res.end,所以在第一個中間件很容易記錄處理的時間,如下所示,在中間件執行完后,在handleResponse中才會將請求處理結果返回給客戶端。

fn(ctx)[是一個立即狀態的promise].then(handleResponse).catch(onerror);

而express每次res.send的時候數據已經發給客戶端了,當然也可以實現這種需求,只不過沒有koa方便。多說幾句,其實java中也有類似的實現,例如java中的aop,過濾器,將通用的邏輯,例如日志,權限等模塊通過配置的方式進行靈活的插入,配置在xml中。比較靈活,每個模塊之間互相解耦,根據需求實現可插拔效果。
在說一下與react中redux中間件機制區別,redux中的applyMiddleware中間件機制,可以在處理store前后加一些通用處理,利用高階函數compose,通過reduce將多個函數組合成一個可執行執行函數

//applyMiddleware.js
chain = middlewares.map(middleware => middleware(middlewareAPI))
dispatch = compose(...chain)(store.dispatch) 

//compose.js
export default function compose(...funcs) {
  return funcs.reduce((a, b) => (...args) => a(b(...args)))
}

組合好最后執行的時候是洋蔥模型效果,舉個例子 compose(a, b, c)變成 a(b(c())),而a,b,c的結構類似下面這種形式

function fnA(next) {
  return function() {
    console.log("fnA start")
    next()
    console.log("fnA end")
  }
}

所以a(b(c()))()執行的時候,就會通過next來控制調用下一個中間件,整體的執行等價于express遞歸調用方式

vue中也有路由,官方的vue-router,他解決的是url和模板組件匹配渲染的問題, 而express中解決的url和handler匹配執行的問題,而koa內核里面沒有集成路由。 從vue-router和express路由中可以看出路由的共性,是為了解決路徑和相應處理邏輯的匹配問題在web開發中。

根據上述分析的邏輯,實現了一個簡化版的express ,融入了express的核心思想,有詳盡的步驟注釋,有需要的可以參考下。

參考源碼版本說明
express 4.16.2
koa 2.2
redux 3.7.2
參考鏈接
https://github.com/koajs/koa/...
https://www.reddit.com/r/node...
https://blog.jscrambler.com/m...