分布式追蹤系統
分布式系統為什麼需要 Tracing？
先介紹一個概念：分布式跟蹤，或分布式追蹤。
電商平台由數以百計的分布式服務構成，每一個請求路由過來後，會經過多個業務系統并留下足迹，并産生對各種Cache或DB的通路，但是這些分散的資料對于問題排查，或是流程優化都幫助有限。對于這麼一個跨程序/跨線程的場景，彙總收集并分析海量日志就顯得尤為重要。要能做到追蹤每個請求的完整調用鍊路，收集調用鍊路上每個服務的性能資料，計算性能資料和比對性能名額（SLA），甚至在更遠的未來能夠再回報到服務治理中，那麼這就是分布式跟蹤的目标了。在業界，twitter 的 zipkin 和淘寶的鷹眼就是類似的系統，它們都起源于 Google Dapper 論文，就像曆史上 Hadoop 發源于 Google Map/Reduce 論文，HBase 源自 Google BigTable 論文一樣。
好了，整理一下，Google叫Dapper，淘寶叫鷹眼，Twitter叫ZipKin，京東商城叫Hydra，eBay叫Centralized Activity Logging (CAL)，大衆點評網叫CAT，我們叫Tracing。
這樣的系統通常有幾個設計目标：
（1）低侵入性——作為非業務元件，應當盡可能少侵入或者無侵入其他業務系統，對于使用方透明，減少開發人員的負擔；
（2）靈活的應用政策——可以（最好随時）決定所收集資料的範圍和粒度；
（3）時效性——從資料的收集和産生，到資料計算和處理，再到最終展現，都要求盡可能快；
（4）決策支援——這些資料是否能在決策支援層面發揮作用，特别是從 DevOps 的角度；
（5）可視化才是王道。
先來一個直覺感受：
下面依次展示了 ZipKin、鷹眼、窩窩的調用鍊繪制界面。
圖1 twitter zipkin 調用鍊
圖2 淘寶鷹眼的調用鍊
圖3 京東商城hydra調用鍊
圖4 窩窩tracing調用鍊
滑鼠移動到調用鍊的每一層點選，可以看到執行時長、主控端IP、資料庫操作、傳入參數甚至錯誤堆棧等等具體資訊。
淘寶如何實作的：
同一次請求的所有相關調用的情況，在淘寶 EagleEye 裡稱作 調用鍊。同一個時刻某一台伺服器并行發起的網絡調用有很多，怎麼識别這個調用是屬于哪個調用鍊的呢？可以在各個發起網絡調用的中間件上下手。
在前端請求到達伺服器時，應用容器在執行實際業務處理之前，會先執行 EagleEye 的埋點邏輯（類似 Filter 的機制），埋點邏輯為這個前端請求配置設定一個全局唯一的調用鍊ID。這個ID在 EagleEye 裡面被稱為 TraceId，埋點邏輯把 TraceId 放在一個調用上下文對象裡面，而調用上下文對象會存儲在 ThreadLocal 裡面。調用上下文裡還有一個ID非常重要，在 EagleEye 裡面被稱作 RpcId。RpcId 用于區分同一個調用鍊下的多個網絡調用的發生順序和嵌套層次關系。對于前端收到請求，生成的 RpcId 固定都是0。
當這個前端執行業務處理需要發起 RPC 調用時，淘寶的 RPC 調用用戶端 HSF 會首先從目前線程 ThreadLocal 上面擷取之前 EagleEye 設定的調用上下文。然後，把 RpcId 遞增一個序号。在 EagleEye 裡使用多級序号來表示 RpcId，比如前端剛接到請求之後的 RpcId 是0，那麼 它第一次調用 RPC 服務A時，會把 RpcId 改成 0.1。之後，調用上下文會作為附件随這次請求一起發送到遠端的 HSF 伺服器。
HSF 服務端收到這個請求之後，會從請求附件裡取出調用上下文，并放到目前線程 ThreadLocal 上面。如果服務A在處理時，需要調用另一個服務，這個時候它會重複之前提到的操作，唯一的差别就是 RpcId 會先改成 0.1.1 再傳過去。服務A的邏輯全部處理完畢之後，HSF 在傳回響應對象之前，會把這次調用情況以及 TraceId、RpcId 都列印到它的通路日志之中，同時，會從 ThreadLocal 清理掉調用上下文。如圖6-1展示了一個浏覽器請求可能觸發的系統間調用。
圖6-1-一個浏覽器請求可能觸發的系統間調用
圖6-1描述了 EagleEye 在一個非常簡單的分布式調用場景裡做的事情，就是為每次調用配置設定 TraceId、RpcId，放在 ThreadLocal 的調用上下文上面，調用結束的時候，把 TraceId、RpcId 列印到通路日志。類似的其他網絡調用中間件的調用過程也都比較類似，這裡不再贅述了。通路日志裡面，一般會記錄調用時間、遠端IP位址、結果狀态碼、調用耗時之類，也會記錄與這次調用類型相關的一些資訊，如URL、服 務名、消息topic等。很多調用場景會比上面說的完全同步的調用更為複雜，比如會遇到異步、單向、廣播、并發、批處理等等，這時候需要妥善處理好 ThreadLocal 上的調用上下文，避免調用上下文混亂和無法正确釋放。另外，采用多級序号的 RpcId 設計方案會比單級序号遞增更容易準确還原當時的調用情況。
最後，EagleEye 分析系統把調用鍊相關的所有通路日志都收集上來，按 TraceId 彙總在一起之後，就可以準确還原調用當時的情況了。
圖6-2-一個典型的調用鍊
如圖6-2所示，就是采集自淘寶線上環境的某一條實際調用鍊。調用鍊通過樹形展現了調用情況。調用鍊可以清晰地看到目前請求的調用情況，幫助問題定 位。如上圖，mtop應用發生錯誤時，在調用鍊上可以直接看出這是因為第四層的一個(tair@1)請求導緻網絡逾時，使最上層頁面出現逾時問題。這種調用鍊，可以在 EagleEye 系統監測到包含異常的通路日志後，把目前的錯誤與整個調用鍊關聯起來。問題排查人員在發現入口錯誤量上漲或耗時上升時，通過 EagleEye 查找出這種包含錯誤的調用鍊采樣，提高故障定位速度。
這種分析能力對于複雜的分布式環境的調用關系梳理尤為重要。傳統的調用統計日志是按固定時間視窗預先做了統計的日志，上面缺少了鍊路細節導緻沒辦法對超過兩層以上的調用情況進行分析。例如，後端資料庫就無法評估資料庫通路是來源于最上層的哪些入口；每個前端系統也無法清楚确定目前入口由于雙十一活動流量翻倍，會對後端哪些系統造成多大的壓力，需要分别準備多少機器。有了 EagleEye 的資料，這些問題就迎刃而解了。
下圖6-4展示了資料流轉過程。
圖6-4 鷹眼的資料收集和存儲
京東如何實作的：
京東商城引入了阿裡開源的服務治理中間件 Dubbo，是以它的分布式跟蹤 Hydra 基于 Dubbo 就能做到對業務系統幾乎無侵入了。
Hydra 的領域模型如下圖7所示：
圖7 hydra 領域模型以及解釋
hydra 資料存儲是 HBase，如下圖8所示：
圖8 hydra 架構
窩窩如何實作的：
2012年，逐漸看到自建分布式跟蹤系統的重要性，但随即意識到如果沒有對 RPC 調用架構做統一封裝，就可能侵入到每一個業務工程裡去寫埋點日志，于是推廣 Dubbo 也提上日程。2013年，确定系統建設目标，開始動手。由于 tracing 跟 DevOps 息息相關，是以資料聚合、存儲、分析和展示由運維部向榮牽頭開發，各個業務工程資料埋點和上報由研發部國玺負責。
經過後續向榮、劉卓、國玺、明斌等人的不斷改進，技術選型大緻如下所示。
- 埋點
- 實作線程内 trace 上下文傳遞，即伺服器内部的方法互調時不需要強制在方法形參中加 Message 參數；
- 實作 trace 埋點邏輯自動織入功能，即業務開發人員不需要在方法中列印 trace 日志，隻需要給該方法加注解辨別 ；
-
【架構】分布式追蹤系統設計與實作 - 原理：
- 利用 Javaagent 機制，執行 main 方法之前，會先執行 premain 方法，在該方法中将位元組碼轉換器載入 instrumentation，而後 jvm 在加載 class 檔案之前都會先執行位元組碼轉換器。
- 位元組碼轉換器中的邏輯為，識别出注解 trace 的類及方法，并修改該方法位元組碼，織入埋點邏輯。進入方法時會初始 trace 上下文資訊，并存儲線上程的 threadLocals 中，退出方法會列印 trace 日志并清空該方法的上下文。
- 資料聚合
- 應用層 trace 日志通過 flume agents 實時發送至 flume collector；
- 資料存儲
- 服務端分别通過 hdfs-sink 和 hbase-sink，實時錄入至 hbase、hdfs；
- hdfs 有 tmp 臨時檔案存放實時聚合過來的資料，每5分鐘生成一個 done 檔案；
- 資料分析和統計
- load 程式每 4 分鐘檢查 done 檔案并存放至 hive 表 hkymessage 指定分區；
-
分析程式每5分鐘執行一次, 将生成統計資料入庫, 結果集資料如下：
資料格式：{5個分層的5個響應時段請求個數合集} {5個分層5-10s和大于10s散點資料合集} 目前5分鐘最後一次請求rootid 統計時間
- 資料展示
- 基于 Python 的 Django
基于這些資料分析和統計，我們就能繪制性能曲線圖，從中可以發現哪些時間點哪些層有性能問題，然後一路點進去，直到找到到底是哪一個調用鍊裡的哪一個環節慢。
圖9 性能曲線預設圖形
還可以從每一次調用結果分析出各層的異常曲線，并按照 memcached/redis/mongodb/mysql/runtime/fail 分類檢視。
圖10 異常曲線預設圖形
還可以進一步統計各個業務工程的通路量、通路品質和平均通路時長，并于曆史同期對比，進而快速了解系統服務品質。
如上所述，窩窩的 Tracing（鷹眼） 系統目前已投入使用，歸并在 OAP（運維自動化平台）裡。
-over-