分布式調用跟蹤系統的設計和應用
>>為什么需要分布式調用跟蹤系統
隨着分布式服務架構的流行，特別是微服務等設計理念在系統中的應用，業務的調用鏈越來越復雜，
可以看到，隨着服務的拆分，系統的模塊變得越來越多，不同的模塊可能由不同的團隊維護，
一個請求可能會涉及到幾十個服務的協同處理， 牽扯到多個團隊的業務系統，那么如何快速准確的定位到線上故障？
同時，缺乏一個自上而下全局的調用id，如何有效的進行相關的數據分析工作？
對於大型網站系統，如淘寶、京東等電商網站，這些問題尤其突出。
一個典型的分布式系統請求調用過程：
比較成熟的解決方案是通過調用鏈的方式，把一次請求調用過程完整的串聯起來，這樣就實現了對請求調用路徑的監控。
>>調用跟蹤系統的業務場景
（1）故障快速定位
通過調用鏈跟蹤，一次請求的邏輯軌跡可以用完整清晰的展示出來。
開發中可以在業務日志中添加調用鏈ID，可以通過調用鏈結合業務日志快速定位錯誤信息。
（2）各個調用環節的性能分析
在調用鏈的各個環節分別添加調用時延，可以分析系統的性能瓶頸，進行針對性的優化。
（3）各個調用環節的可用性，持久層依賴等
通過分析各個環節的平均時延，QPS等信息，可以找到系統的薄弱環節，對一些模塊做調整，如數據冗余等。
（4）數據分析等
調用鏈是一條完整的業務日志，可以得到用戶的行為路徑，匯總分析應用在很多業務場景。
>>分布式調用跟蹤系統的設計
（1）分布式調用跟蹤系統的設計目標
低侵入性，應用透明：
作為非業務組件，應當盡可能少侵入或者無侵入其他業務系統，對於使用方透明，減少開發人員的負擔
低損耗：
服務調用埋點本身會帶來性能損耗，這就需要調用跟蹤的低損耗，
實際中還會通過配置采樣率的方式，選擇一部分請求去分析請求路徑
大范圍部署，擴展性：
作為分布式系統的組件之一，一個優秀的調用跟蹤系統必須支持分布式部署，具備良好的可擴展性
（2）埋點和生成日志
埋點即系統在當前節點的上下文信息，可以分為客戶端埋點、服務端埋點，以及客戶端和服務端雙向型埋點。
埋點日志通常要包含以下內容：
TraceId、RPCId、調用的開始時間，調用類型，協議類型，調用方ip和端口，請求的服務名等信息；
調用耗時，調用結果，異常信息，消息報文等；
預留可擴展字段，為下一步擴展做准備；
（3）抓取和存儲日志
日志的采集和存儲有許多開源的工具可以選擇，
一般來說，會使用離線+實時的方式去存儲日志，主要是分布式日志采集的方式。
典型的解決方案如Flume結合Kafka等MQ。
（4）分析和統計調用鏈數據
一條調用鏈的日志散落在調用經過的各個服務器上，
首先需要按 TraceId 匯總日志，然后按照RpcId 對調用鏈進行順序整理。
調用鏈數據不要求百分之百准確，可以允許中間的部分日志丟失。
（5）計算和展示
匯總得到各個應用節點的調用鏈日志后，可以針對性的對各個業務線進行分析。
需要對具體日志進行整理，進一步儲存在HBase或者關系型數據庫中，可以進行可視化的查詢。
>>調用跟蹤系統的選型
大的互聯網公司都有自己的分布式跟蹤系統，
比如Google的Dapper，Twitter的zipkin，淘寶的鷹眼，新浪的Watchman，京東的Hydra等。
（1）Google的Drapper
Dapper是Google生產環境下的分布式跟蹤系統，Dapper有三個設計目標：
低消耗：跟蹤系統對在線服務的影響應該做到足夠小。
應用級的透明：對於應用的程序員來說，是不需要知道有跟蹤系統這回事的。如果一個跟蹤系統想生效，就必須需要依賴應用的開發者主動配合，那么這個跟蹤系統顯然是侵入性太強的。
延展性：Google至少在未來幾年的服務和集群的規模，監控系統都應該能完全把控住。
Drapper的日志格式：
dapper用span來表示一個服務調用開始和結束的時間，也就是時間區間。
dapper記錄了span的名稱以及每個span的ID和父ID，如果一個span沒有父ID被稱之為root span。所有的span都掛在一個特定的trace上，共用一個traceID，這些ID用全局64位整數標示。
Drapper如何進行跟蹤收集：
分為3個階段：
①各個服務將span數據寫到本機日志上；
②dapper守護進程進行拉取，將數據讀到dapper收集器里；
③dapper收集器將結果寫到bigtable中，一次跟蹤被記錄為一行。
（2）淘寶的鷹眼
關於淘寶的鷹眼系統，主要資料來自於內部分享，
鷹眼埋點和生成日志：
如何抓取和存儲日志：
鷹眼的實現小結：
詳情見：淘寶-分布式調用跟蹤系統介紹
參考資料：
分布式追蹤系統dapper