最近接手一份代碼，采用的是golang revel web框架，期間不停的有運(yùn)營(yíng)，測(cè)試來(lái)騷擾，新手必須要老實(shí)，有問(wèn)必答，來(lái)一個(gè)我就去日志文件查看一下，“尼瑪，不停的刷屏，怎么看，大概什么時(shí)間，給個(gè)訂單號(hào)唄”，這是我做的最多的事情。實(shí)在是看的心累，日志記錄內(nèi)容太少，關(guān)鍵字太少，并發(fā)請(qǐng)求太多，分不清是不是一個(gè)請(qǐng)求的。程序員得用程序解放勞動(dòng)力，怎么能浪費(fèi)在看日志的時(shí)間上。有了需求點(diǎn)，那么對(duì)日志的記錄就得規(guī)范。總結(jié)幾個(gè)記日志的關(guān)鍵點(diǎn)。

1. 入口打印請(qǐng)求參數(shù)，出口打印返回值。--便于和前后端扯皮，什么參數(shù)傳錯(cuò)了，沒(méi)返回等等

2.日志關(guān)鍵字明確，時(shí)間，級(jí)別，行號(hào)函數(shù)名。--便于grep 各種搜索，隨時(shí)定位代碼

3.一個(gè)請(qǐng)求有一個(gè)唯一請(qǐng)求ID ，一路追蹤，無(wú)論多少次rpc,或者函數(shù)調(diào)用

1.2 這兩個(gè)問(wèn)題很好解決，第3個(gè)就很麻煩，在網(wǎng)上查了很多問(wèn)題資料，看到一個(gè)google的分布式跟蹤的，但這個(gè)主要是基于rpc 的，但是我想的是基于函數(shù)調(diào)用的，一個(gè)請(qǐng)求，無(wú)論調(diào)用多少層函數(shù)，那么函數(shù)里面日志都攜帶一個(gè)唯一表示此請(qǐng)求的ID，別的請(qǐng)求調(diào)用的就攜帶別的ID，不能重。 鑒于需求是這樣，那么我想到一個(gè)方案，每一次函數(shù)調(diào)用時(shí)都多傳一個(gè)ID，傳入log 這樣，但這樣太麻煩了，還要改動(dòng)所有l(wèi)og 調(diào)用的地方，不可取。其實(shí)這個(gè)問(wèn)題，仔細(xì)分析變成了找多個(gè)請(qǐng)求調(diào)用多個(gè)函數(shù)調(diào)用的共同點(diǎn)， 什么是共同的1.請(qǐng)求是共同的，但這個(gè)傳入，log 侵入代碼成本太高， 還有一個(gè)是共同的，順著函數(shù)堆棧往上追，都能追到請(qǐng)求處理的初始函數(shù)，但我們還要區(qū)分不同請(qǐng)求,不能只是追蹤調(diào)用路線，想到一個(gè)辦法，就是能不能根據(jù)每一個(gè)調(diào)用堆棧分配一個(gè)ID，在各個(gè)字函數(shù)里面能獲取所在堆棧的ID，但這個(gè)只是我的設(shè)想不知道，怎么實(shí)現(xiàn)。?

終于找到了還有一個(gè)共同點(diǎn)，每一次請(qǐng)求都是go 一個(gè)協(xié)程，而里面的調(diào)用各個(gè)函數(shù)都是在這個(gè)協(xié)程里的，這樣只需要獲取所在協(xié)程的ID 不就是唯一對(duì)應(yīng)這個(gè)請(qǐng)求嗎。 問(wèn)題終于解決了。

下面是golang 獲取協(xié)程ID的一些方法 資料。

1. https://www.zhihu.com/question/39863941/answer/83575802?

2.http://blog.sgmansfield.com/2015/12/goroutine-ids/

3.https://github.com/huandu/goroutine