Goroutine的上下文儲存

後端開發中，問題分析通常是請求層級的，如果能通過一個唯一的請求號對日誌進行過濾，能對分析問題帶來不少的便捷。我們的項目中也希望在請求相關的日誌中，嵌入請求號。

Golang在http.Request中提供了一個Context用於儲存kv對，我們可以通過這個來儲存請求相關的資料。在請求入口，我們把唯一的requstID儲存到context中，在後續需要調用的地方把值取出來列印。如果日誌是在controller中列印，這個很好處理，http.Request是作為入參的。但如果是在更底層呢？比如說是在model甚至是一些工具類中。我們當然可以給每個方法都提供一個參數，由調用方把context一層一層傳下來，但這種方式明顯不夠優雅。

那麼Golang有沒有提供一個靜態方案擷取當前context呢？答案是否定的。有沒有提供類似ThreadLocal這樣的機制擷取Goroutine的上下文呢？答案也是否定的。

理由是Andrew Gerrand認為通過線程上下文這種方式傳參“帶來的問題比解決的問題多”。

We wouldn't even be having this discussion if thread local storage wasn't useful. But every feature comes at a cost, and in my opinion the cost of threadlocals far outweighs their benefits. They're just not a good fit for Go.

官方不但不提供這樣的方法，還不遺餘力的讓第三方也無法提供--Golang不提供任何可以讓你獲知當前GoroutineID的方法。

不過，哪裡有壓迫，哪裡就有反抗。還是有第三方的庫做了類似的功能。

首先是一個庫做了一個擷取當前所在GoRoutine的方法，https://github.com/bradfitz/http2/blob/dc0c5c000ec33e263612939744d51a3b68b9cece/gotrack.go

原理是利用了runtime.Stack的字串格式

可以看到在Stack的開頭列印了一個類似於goroutineID的東西。有了goroutineID，GoRoutine的local storage實現方式也就是順理成章了，只要把context存放在以goroutineID為key的map中即可。

另外有一個庫jtolds/gls，它的實現方式就奇特多了。同在runtime包下面，有一個Callers方法，可以擷取當前調用棧的pc列表。這個gls庫就是利用這個Callers方法。

gls庫預先定義了16個可嵌套的空方法，調用方需要用到GoRoutineLocal功能時，需要把用到這個功能的根方法作為參數傳入到gls中，gls按順序產生未被使用的GoRoutineID，然後把GoRoutineID種入到調用棧中。具體的方法就是利用前面所述的16個空方法進行編碼，每個方法使用與否分別代表一個bit的0或1，最終通過這16個方法編碼成16個bit的GoRoutineID。解碼時，只需通過Callers方法擷取pc列表，與16個方法的pc進行匹配即可把GoRoutineID解碼出來。

第一種方法利用的是golang列印格式，雖說這種列印格式不太可能會在golang的未來版本發生改變，但畢竟噁心；第二種方法腦迴路清奇，似乎也沒有什麼限制，但要用在生產上的話，還是算了吧。