【引言】
本期由阿里雲ACE（阿里雲開發者社群）&成都檸檬雲網絡技術有限公司資深架構師 曾昌強 為大家分享個人成長經歷與個人專業技術之分散式鏈路追蹤系統架構設計。
視訊：https://yq.aliyun.com/live/581

Part 1：成長經歷
講述一個不知道什麼叫程式設計的門外漢，如何穿越幾千公里來到石油名校學習計算機，當家教，炸金花最終進入目標企業的故事而後又輾轉幾千公里進入夢想公司阿里巴巴，後來又迴歸家鄉的故事講述一個如何從ERP，進入網際網路，又進入區塊鏈行業的故事。

Part 2：分散式鏈路追蹤系統架構設計

1. 為什麼需要分散式鏈路追蹤
2. 鏈路追蹤核心模型
3. 鏈路追蹤的作用，原理
4. 鏈路追蹤各個模組地設計與經驗分享
5. 鏈路追蹤產品展示
   

【正文】
一、對程式設計師的感悟與成長經歷

首先和大家講述一下我認為的程式設計師有哪些境界，搬磚，就是大家所說的苦逼程式設計師，沒有成就感，沒有技術含量，年復一日，度日如年，想想這樣也挺難熬的，畢竟還有幾十年。情懷，有一定技術含量，也能從工作中找到一些成就感，當然也能獲得可觀的收入維持程式設計師體面的生活。快樂，以程式設計為快樂，只要寫程式碼就感覺興奮，高興，深深地佩服自己的計算機技能，徜徉於自己的世界中。希望你能在程式碼中找到自己的快樂。

本人在上大學之前並不瞭解計算機程式設計時幹啥的，由於在07年的時候考上了一所大學，無奈對所學專業的不感興趣，不想就此決定此生的方向，就是年復一日的搬磚，在讀了半年之後，毅然退學。重新高考，由於當時石油很火，就想讀一個石油名校，就選擇了大慶石油學院，沒想到，拿到的通知書卻是電腦科學與技術，想著這半年來的懸樑刺股，苦逼生活，不敢再復讀了，就毅然抱著當網管的心態，去學習計算機技術了。

        到了大學，感覺挺閒的，就去找了中介，當了家教，教書育人，補貼家用，閒暇時間又通讀了古今中外經典書籍(其實就是看小說)，提升自己的文化修養。後來思考，為啥別人可以給我介紹家教掙我的錢，就迅速調研了家教中介的門檻，發現很簡單，就去學校周邊印一些廣告，然後聯絡大學生，做一個雙向溝通，遂成立天翼家教。當然還是掙了些錢，有了錢，機緣巧合之下，就去炒股了，沒想到賠了不少，發現股市比較坑人（當然在我研究了股市很長時間發現，散戶根本不能炒短線，一定要能熬，熬到莊家都怕你，兩年之後，收益100%）。然後在隔壁班同學的慫恿下，就去砸金花了，但是還被警察抓了一回(故事很長)，第一次砸金花被抓，第一次知道玩牌會被抓（四川人）。漸漸到了大三，發現明年就要找工作了，發現自己啥都不會啊，那咋辦呢？想想還是去做一下專案吧，然後就去找了個相熟的教授，進了他的實驗室，然後就開始接觸了一些專案，漸漸的發現還有那麼點意思，尤其看到自己設計的程式碼，真的按照自己的想法出結果了，並且還有人在用，並且還有收入，瞬間就膨脹了，發現計算機這行不錯。雙選會(哈工大的)的時候，進入了自己心儀的企業用友軟體，待遇在當時也算非常不錯的，因為當時還沒有bat這一說法，由於上一屆師兄的影響，認為用友軟體就是當時最牛逼的企業(當然本來也很不錯)。然後就去了用友工作，用友園區好大，就是偏僻了點，還包住，想想也是挺幸福的。在那度過了兩年多，認識了很多好朋友。後來去了58同城，把網際網路技術深入的學習了一遍。而後去了上海的餓了麼，專注於資料庫中介軟體的開發，我們是從頭開始設計架構資料庫中介軟體的，基於mysql協議，所以對mysql協議現在是非常熟悉了，同時也對資料庫相關的優化，設計，效能有一些理解。再後來，就去阿里天貓，再後來由於家裡的一些事情，就回到了成都。現在在檸檬雲任職架構師。
 

我的夢想就是成為詩人，遊俠，是不是有點像李白，對的，李白就是我的偶像。曾夢想仗劍走天涯，看一看世界的繁華。結果為什麼沒有去呢，就是bug太多了。怎麼才能bug少一些呢，或者解決bug更容易呢？我們就需要一個非常重要的工具，鏈路追蹤

二、專業技術分享：分散式鏈路追蹤系統架構設計

1. 為什麼需要分散式鏈路追蹤
我們剛才也說到，解決bug需要用到鏈路追蹤工具，下面我們來舉個“較複雜的分散式呼叫網路”的例子。

這是一個很典型的分散式網路拓撲圖，真實的環境可能比這個網路複雜得多，那麼
我們如何能理清應用之間的呼叫關係？
出錯之後如何快速定位？
如何監控每個服務的健康狀況，效能情況？
如何監控每個呼叫在各個服務的呼叫和耗時情況？

回答以上問題需要用到Trace的一次追蹤

可以很清晰地看到此次呼叫在每個服務的耗時，以及直接可以定位出效能瓶頸在哪裡

2. 鏈路追蹤主要核心領域模型，Opentracing核心模型

3.鏈路追蹤的作用與原理說明

假設遊客要進入每個景點，必須使用身份證掃描，並且記錄一個日誌在本地，有一個收集系統會定時收集所有景點的資料，彙總到一箇中央日誌處理系統。那麼，我們就是分析這些資料，得到小明這一次去遊覽了哪些景點，在每個景點停留了多久。還有每個景點在某一時刻的人流量，每個景點的最大承載量是多大等等。這就是完全類似於我們的鏈路追蹤系統。

現在開源或者在使用的鏈路追蹤系統中絕大部份是參考了Google 的這篇Dapper論文，其中最重要的就是指明瞭一個實現方向，以及證明了實現的可能性

4. 鏈路追蹤各個模組地設計與經驗分享

設計目標

整體框架

TraceId設計

我們的TraceId設計了業務欄位，包含起始appid，起始ip，取樣標識等。大家可以思考使用UUID是否可以？

Span設計
span使用多級設計，清晰明確地展示每個span在追蹤鏈中的位置。traceId一直保持不變，在所有span中傳輸，最終根據traceId和spanId的層級關係，準確還原整個呼叫鏈路。

Client設計
當請求進入某一個span之後，會建立執行緒上下文，然後對應的RPC，SQL，HTTP等呼叫，都會作為一個節點，加入到執行緒上下文中，當請求結束的時候，整個span會發送到非同步佇列中，通過執行緒逐漸傳送到server端。

Server設計

server使用netty作為網路框架，接收客戶端傳送的資料。分析之後，全量資料傳送到hbase，需要再分析的資料傳送到kafka，後續使用storm叢集來分析

Storm設計
上面為storm大致的設計拓撲圖，使用kafkaSpout讀取剛才server端寫入kafka的的資料。然後經過統一AnalysisBolt，分析進入，EntryStatistics，ErrorStatistic等，最後再經過HbaseBolt，將分析完的資料寫入Hbase。

5. 產品展示