摘要：變量的說法來自于，這是在多線程模型下出現(xiàn)并發(fā)問題的一種解決方案。目前已經(jīng)有庫實(shí)現(xiàn)了應(yīng)用層棧幀的可控編碼，同時(shí)可以在該棧幀存活階段綁定相關(guān)數(shù)據(jù)，我們便可以利用這種特性實(shí)現(xiàn)類似多線程下的變量。

ThreadLocal變量的說法來自于Java，這是在多線程模型下出現(xiàn)并發(fā)問題的一種解決方案。
ThreadLocal變量作為線程內(nèi)的局部變量，在多線程下可以保持獨(dú)立，它存在于
線程的生命周期內(nèi)，可以在線程運(yùn)行階段多個(gè)模塊間共享數(shù)據(jù)。那么，ThreadLocal變量
又如何與node.js扯上關(guān)系呢？

node的運(yùn)行模型無需再贅言： “事件循環(huán) + 異步執(zhí)行”，可是node開發(fā)工程師比較感興趣的點(diǎn)
大多集中在 “編碼模式”上，即異步代碼同步編寫，由此提出了多種解決回調(diào)地獄的解決方案：

yield

thunk

promise

await

可是如果從代碼執(zhí)行流程的微觀視角中跳出來，宏觀上看待node服務(wù)器處理每個(gè)HTTP請(qǐng)求，就會(huì)
發(fā)現(xiàn)這其實(shí)是多線程web服務(wù)器的另一種體現(xiàn)，雖然設(shè)計(jì)上并不像多線程模型那么直觀。在單核cpu中
每一時(shí)刻node服務(wù)器只能處理一個(gè)請(qǐng)求，可是node在當(dāng)前請(qǐng)求中執(zhí)行異步調(diào)用時(shí)，就會(huì)“中斷”進(jìn)入下一個(gè)
事件循環(huán)處理另一個(gè)請(qǐng)求，直到上一個(gè)請(qǐng)求的異步任務(wù)事件觸發(fā)執(zhí)行對(duì)應(yīng)回調(diào)，繼續(xù)執(zhí)行該請(qǐng)求的后續(xù)邏輯。
這在某種程度上類似于CPU的時(shí)間片搶占機(jī)制，微觀上的順序執(zhí)行，宏觀上卻是同步執(zhí)行。

node在單進(jìn)程單線程（js執(zhí)行線程）中“模擬”了常見的多線程處理邏輯，雖然在單個(gè)node進(jìn)程中無法
充分利用CPU的多核及超線程特性，可是卻避免了多線程模型下的臨界資源同步和線程上下文
切換的問題，同時(shí)內(nèi)存資源開銷相對(duì)較小，因此在I/O密集型的業(yè)務(wù)下使用node開發(fā)web服務(wù)
往往有著意想不到的好處。

可是在node開發(fā)中需要追蹤每個(gè)請(qǐng)求的調(diào)用鏈路，通過獲取請(qǐng)求頭的traceId字段在每一級(jí)
的調(diào)用鏈路中傳遞該字段，包括“http請(qǐng)求、dubbo調(diào)用、dao操作、redis和日志打點(diǎn)”等操作。
這樣通過追蹤traceId，就可以分析請(qǐng)求所經(jīng)過的所有中間鏈路，評(píng)估每個(gè)環(huán)節(jié)的時(shí)延與瓶頸，
更容易進(jìn)行性能優(yōu)化和錯(cuò)誤排查。

那么，如何在業(yè)務(wù)代碼中無侵入性的獲取到相關(guān)的traceId呢？這就引出了本文的ThreadLocal變量。

需手動(dòng)傳遞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執(zhí)行結(jié)束",ctx.request.headers["traceId"])
            res(123);
        },1000);
    });
    ctx.body = "hello world";
    Logger.info("請(qǐng)求返回",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業(yè)務(wù)處理函數(shù)中，在service執(zhí)行結(jié)束和body返回后都進(jìn)行日志打點(diǎn)，同時(shí)手動(dòng)
傳遞請(qǐng)求頭traceId給日志模塊，方便相關(guān)系統(tǒng)追蹤鏈路。

目前這樣編碼無法規(guī)范化日志接口，同時(shí)也對(duì)開發(fā)人員造成了很大的困擾。對(duì)于業(yè)務(wù)開發(fā)人員他們
理應(yīng)不關(guān)心如何進(jìn)行鏈路追蹤，而目前的編碼則直接侵入了業(yè)務(wù)代碼中，這塊功能應(yīng)該由日志模塊
Logger來實(shí)現(xiàn)，可是在與請(qǐng)求上下文沒有任何聯(lián)系的Logger模塊如何獲取每個(gè)請(qǐng)求的traceId呢？

這就需要依靠node.js中的ThreadLocal變量。文章開頭提到，多線程下ThreadLocal變量是與
每個(gè)線程的生命周期對(duì)應(yīng)的，那么如果在node.js的“單線程+異步調(diào)用+事件循環(huán)”的特性下實(shí)現(xiàn)
類似的ThreadLocal變量，不就可以在每個(gè)請(qǐng)求的異步回調(diào)執(zhí)行時(shí)獲取到對(duì)應(yīng)的ThreadLocal變量，
拿到相關(guān)的上下文信息嗎？

單純實(shí)現(xiàn)web服務(wù)器的中間鏈路請(qǐng)求追蹤其實(shí)并不復(fù)雜，使用全局變量Map并通過每個(gè)請(qǐng)求的唯一標(biāo)識(shí)
存儲(chǔ)上下文信息，當(dāng)執(zhí)行到該請(qǐng)求的下一個(gè)異步調(diào)用時(shí)便通過在全局Map中獲取到與該請(qǐng)求綁定的ThreadLocal
變量，不過這是在應(yīng)用層面的一種投機(jī)行為，是與請(qǐng)求緊耦合的簡易實(shí)現(xiàn)。

最徹底的方案則是在node應(yīng)用層實(shí)現(xiàn)一種棧幀，在該棧幀內(nèi)重寫所有的異步函數(shù)，并添加各個(gè)
hook在異步函數(shù)的各個(gè)生命周期執(zhí)行，實(shí)現(xiàn)異步函數(shù)執(zhí)行上下文與棧幀的映射，這便是最為
徹底的ThreadLocal實(shí)現(xiàn)，而不是僅僅停留在與HTTP請(qǐng)求的映射過程中。

目前已經(jīng)有zone.js庫實(shí)現(xiàn)了node應(yīng)用層棧幀的可控編碼，同時(shí)可以在該棧幀存活階段綁定
相關(guān)數(shù)據(jù)，我們便可以利用這種特性實(shí)現(xiàn)類似多線程下的ThreadLocal變量。

我們的目標(biāo)是實(shí)現(xiàn)無侵入的編寫包含鏈路追蹤的業(yè)務(wù)代碼，如下所示：

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

相比較，Logger.info中不需要手動(dòng)傳遞traceId變量，由日志模塊通過訪問ThreadLocal變量獲取。

通過zone.js提供的創(chuàng)建Zone（對(duì)應(yīng)于棧幀）功能，我們不僅可以獲取當(dāng)前請(qǐng)求（類似于多線程下的單個(gè)線程）的
ThreadLocal變量，還可以獲取上一個(gè)請(qǐng)求的相關(guān)信息。

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執(zhí)行結(jié)束")
            res(123);
        },1000);
    });
    ctx.body = "hello world";
    Logger.info("請(qǐng)求返回")
};
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()=>{
                // 保存請(qǐng)求上下文至parent zone
                koaZoneProperties.requestContext = ctx;
                await business(ctx);
                resolve();
            });
        });
    });
    
    app.listen(8080);
});

創(chuàng)建了兩個(gè)有繼承關(guān)系的zone（棧幀），koaZone的requestContext屬性存儲(chǔ)上一個(gè)請(qǐng)求的上下文信息；
koaMidZone的traceId屬性存儲(chǔ)traceId變量，這是一個(gè)ThreadLocal變量。
Logger.info中通過Zone.current.get("traceId") 獲取當(dāng)前“線程”的
ThreadLocal變量，無需開發(fā)人員手動(dòng)傳遞traceId變量。

關(guān)于zone.js的其他用法，讀者有興趣可以自行研究。本文主要利用zone.js保存一個(gè)執(zhí)行棧幀
內(nèi)的多個(gè)異步函數(shù)的執(zhí)行上下文與特定數(shù)據(jù)（即ThreadLocal變量）的映射。

目前，這套模型已在線上業(yè)務(wù)中用來追蹤各級(jí)鏈路，各級(jí)中間件包括dubbo client、dubbo provider、
配置中心等都依賴ThreadLocal變量實(shí)現(xiàn)數(shù)據(jù)透?jìng)骱驼{(diào)用傳遞，因此可以放心使用。