【引言】
本期由
阿裡雲ACE（阿裡雲開發者社群）&成都檸檬雲網絡技術有限公司資深架構師 曾昌強 為大家分享個人成長經曆與個人專業技術之分布式鍊路追蹤系統架構設計。
視訊：
https://yq.aliyun.com/live/581Part 1：成長經曆
講述一個不知道什麼叫程式設計的門外漢，如何穿越幾千公裡來到石油名校學習計算機，當家教，炸金花最終進入目标企業的故事而後又輾轉幾千公裡進入夢想公司阿裡巴巴，後來又回歸家鄉的故事講述一個如何從ERP，進入網際網路，又進入區塊鍊行業的故事。
Part 2：分布式鍊路追蹤系統架構設計
- 為什麼需要分布式鍊路追蹤
- 鍊路追蹤核心模型
- 鍊路追蹤的作用，原理
- 鍊路追蹤各個子產品地設計與經驗分享
- 鍊路追蹤産品展示
【阿裡雲ACE成長記第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. 産品展示