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

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

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

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

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

/**
 * 對具體請求進行路由分發(fā)處理
 * out 是最后一個處理器,默認(rèn)是請求的回調(diào),不傳的話是內(nèi)部提供的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匹配,如果有注冊參數(shù)路由會解析參數(shù)到layer.params上
            match = matchLayer(layer, path);
            route = layer.route;
        }

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

         //路徑參數(shù)回調(diào)回調(diào)  ,例如請求 /user/1 ,參數(shù)回調(diào) app.param("user",cb1) app.get("/user/:user",cb2)   會先執(zhí)行注冊的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);
            }

        });
    }
};

說明 上面摘取了請求進行路由分發(fā)處理的關(guān)鍵步驟,并做了相應(yīng)的注解。

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

說明

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

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

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

當(dāng)執(zhí)行遇到res.end()的時候,數(shù)據(jù)響應(yīng)完后,整個請求響應(yīng)過程就結(jié)束了。

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

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

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

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

//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)))
}

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

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

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

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

根據(jù)上述分析的邏輯,實現(xiàn)了一個簡化版的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...