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

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

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變量，
拿到相關的上下文信息嗎？

單純實現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變量實現數據透傳和調用傳遞，因此可以放心使用。