node.js與ThreadLocal(AsyncContext Bound)

ThreadLocal變量的說法來自於Java，這是在多線程模型下出現併發問題的一種解決方案。
ThreadLocal變量做爲線程內的局部變量，在多線程下能夠保持獨立，它存在於
線程的生命週期內，能夠在線程運行階段多個模塊間共享數據。那麼，ThreadLocal變量
又如何與node.js扯上關係呢？

在node.js領域，因爲沒有線程的概念，因此筆者更願意稱 ThreadLocal爲 「AsyncContext Bound」, 實現地址： github

node模型

node的運行模型無需再贅言： 「事件循環 + 異步執行」，但是node開發工程師比較感興趣的點
大多集中在 「編碼模式」上，即異步代碼同步編寫，由此提出了多種解決回調地獄的解決方案：

• yield
• thunk
• promise
• await

但是若是從代碼執行流程的微觀視角中跳出來，宏觀上看待node服務器處理每一個HTTP請求，就會
發現這實際上是多線程web服務器的另外一種體現，雖然設計上並不像多線程模型那麼直觀。在單核cpu中
每一時刻node服務器只能處理一個請求，但是node在當前請求中執行異步調用時，就會「中斷」進入下一個
事件循環處理另外一個請求，直到上一個請求的異步任務事件觸發執行對應回調，繼續執行該請求的後續邏輯。
這在某種程度上相似於CPU的時間片搶佔機制，微觀上的順序執行，宏觀上倒是同步執行。

node在單進程單線程（js執行線程）中「模擬」了常見的多線程處理邏輯，雖然在單個node進程中沒法
充分利用CPU的多核及超線程特性，但是卻避免了多線程模型下的臨界資源同步和線程上下文
切換的問題，同時內存資源開銷相對較小，所以在I/O密集型的業務下使用node開發web服務
每每有着意想不到的好處。

但是在node開發中須要追蹤每一個請求的調用鏈路，經過獲取請求頭的traceId字段在每一級
的調用鏈路中傳遞該字段，包括「http請求、dubbo調用、dao操做、redis和日誌打點」等操做。
這樣經過追蹤traceId，就能夠分析請求所通過的全部中間鏈路，評估每一個環節的時延與瓶頸，
更容易進行性能優化和錯誤排查。

那麼，如何在業務代碼中無侵入性的獲取到相關的traceId呢？這就引出了本文的ThreadLocal變量。

傳統的日誌追蹤模式

需手動傳遞traceId給日誌中間件：

var koa = require('koa');
var app =  new koa();
var Logger = {
    info(msg,traceId){
        console.log(msg,traceId);
    }
};
let business = async function(ctx){
    let v = await new Promise((res)=>{
        setTimeout(()=>{
            Logger.info('service執行結束',ctx.request.headers['traceId'])
            res(123);
        },1000);
    });
    ctx.body = 'hello world';
    Logger.info('請求返回',ctx.request.headers['traceId'])
};

app.use(async(ctx,next)=>{
    ctx.request.headers['traceId'] = Date.now() + Math.random();
    await next();
});

app.use(async(ctx,next)=>{
    await business(ctx);
});

app.listen(8080);

在business業務處理函數中，在service執行結束和body返回後都進行日誌打點，同時手動
傳遞請求頭traceId給日誌模塊，方便相關係統追蹤鏈路。

目前這樣編碼沒法規範化日誌接口，同時也對開發人員形成了很大的困擾。對於業務開發人員他們
理應不關心如何進行鏈路追蹤，而目前的編碼則直接侵入了業務代碼中，這塊功能應該由日誌模塊
Logger來實現，但是在與請求上下文沒有任何聯繫的Logger模塊如何獲取每一個請求的traceId呢？

這就須要依靠node.js中的ThreadLocal變量。文章開頭提到，多線程下ThreadLocal變量是與
每一個線程的生命週期對應的，那麼若是在node.js的「單線程+異步調用+事件循環」的特性下實現
相似的ThreadLocal變量，不就能夠在每一個請求的異步回調執行時獲取到對應的ThreadLocal變量，
拿到相關的上下文信息嗎？

ThreadLocal的node實現

單純實現web服務器的中間鏈路請求追蹤其實並不複雜，使用全局變量Map並經過每一個請求的惟一標識
存儲上下文信息，當執行到該請求的下一個異步調用時便經過在全局Map中獲取到與該請求綁定的ThreadLocal
變量，不過這是在應用層面的一種投機行爲，是與請求緊耦合的簡易實現。

最完全的方案則是在node應用層實現一種棧幀，在該棧幀內重寫全部的異步函數，並添加各個
hook在異步函數的各個生命週期執行，實現異步函數執行上下文與棧幀的映射，這即是最爲
完全的ThreadLocal實現，而不是僅僅停留在與HTTP請求的映射過程當中。

目前已經有zone.js庫實現了node應用層棧幀的可控編碼，同時能夠在該棧幀存活階段綁定
相關數據，咱們即可以利用這種特性實現相似多線程下的ThreadLocal變量。

咱們的目標是實現無侵入的編寫包含鏈路追蹤的業務代碼，以下所示：

app.use(async(ctx,next)=>{
    let v = await new Promise((res)=>{
        setTimeout(()=>{
            Logger.info('service執行結束')
            res(123);
        },1000);
    });
    ctx.body = 'hello world';
    Logger.info('請求返回')
});

相比較，Logger.info中不須要手動傳遞traceId變量，由日誌模塊經過訪問ThreadLocal變量獲取。

經過zone.js提供的建立Zone（對應於棧幀）功能，咱們不只能夠獲取當前請求（相似於多線程下的單個線程）的
ThreadLocal變量，還能夠獲取上一個請求的相關信息。

require('zone.js');
var koa = require('koa');
var app =  new koa();
var Logger = {
    info(msg){
        console.log(msg,Zone.current.get('traceId'));
    }
};

var koaZoneProperties = {
    requestContext: null
};
var koaZone = Zone.current.fork({
    name: 'koa',
    properties: koaZoneProperties
});
let business = async function(ctx){
    let v = await new Promise((res)=>{
        setTimeout(()=>{
            Logger.info('service執行結束')
            res(123);
        },1000);
    });
    ctx.body = 'hello world';
    Logger.info('請求返回')
};
koaZone.run(()=>{
    app.use(async(ctx,next)=>{
        console.log(koaZone.get('requestContext'))
        ctx.request.headers['traceId'] = Date.now();
        await next();
    });
    
    app.use(async(ctx,next)=>{
        await new Promise((resolve)=>{
            let koaMidZone = koaZone.fork({
                name: 'koaMidware',
                properties: {
                    traceId: ctx.request.headers['traceId']
                }
            }).run(async()=>{
                // 保存請求上下文至parent zone
                koaZoneProperties.requestContext = ctx;
                await business(ctx);
                resolve();
            });
        });
    });
    
    app.listen(8080);
});

建立了兩個有繼承關係的zone（棧幀），koaZone的requestContext屬性存儲上一個請求的上下文信息；
koaMidZone的traceId屬性存儲traceId變量，這是一個ThreadLocal變量。
Logger.info中經過Zone.current.get('traceId') 獲取當前「線程」的
ThreadLocal變量，無需開發人員手動傳遞traceId變量。

關於zone.js的其餘用法，讀者有興趣能夠自行研究。本文主要利用zone.js保存一個執行棧幀
內的多個異步函數的執行上下文與特定數據（即ThreadLocal變量）的映射。

說明

目前，這套模型已在線上業務中用來追蹤各級鏈路，各級中間件包括dubbo client、dubbo provider、 配置中心等都依賴ThreadLocal變量實現數據透傳和調用傳遞，所以能夠放心使用。