背景

公司業務由數以百計的分散式服務溝通，每一個請求路由過來後，會經過多個業務系統並留下足跡，並產生對各種緩存或者DB的訪問，但是這些分散的數據對於問題排查，或者流程優化比較有限。對於一個跨進程的場景，彙總收集並分析海量日誌就顯得尤為重要。在這種架構下，跨進程的業務流會經過很多個微服務的處理和傳遞，我們難免會遇到這樣的問題:

• 一次請求的流量從哪個服務而來？ 最終落到了哪個服務中去？
• 為什麼這個請求這麼慢? 到底哪個環節出了問題?
• 這個操作需要依賴哪些東西? 是資料庫還是消息隊列? Redis掛了，哪些業務受影響?

對於這個問題，業內已經有了一些實踐和解決方案，通過調用鏈的方式，把一次請求調用過程完整的串聯起來，這樣就實現了對請求條用路徑的監控。在業界，Twitter的Zipkin和淘寶的鷹眼就是類似的系統，它們都起源於Google Dapper論文，就像歷史上Hadoop起源於Google Map/Reduce論文，Hbase起源於Google BigTable論文一樣

設計目標

• 低消耗性：跟蹤系統對業務系統的影響應該做到足夠小。在一些高度優化過的服務，即使一點點損耗也容易察覺到，而且有可能迫使線上負責的部署團隊不得不將跟蹤系統關停
• 低侵入性：作為非業務組件，應當儘可能少侵入或者無侵入業務系統，對於使用方透明，減少開發人員的負擔
• 時效性：從數據的收集產生，到數據計算處理，再到最終展現，都要求儘可能快
• 決策支持：這些數據是否能在決策支持層面發揮作用，特別是從DevOps的角度
• 數據可視化：做到不用看日誌通過可視化進行篩選

實現功能

• 故障快速定位
  • 調用鏈路跟蹤，一次請求的邏輯軌跡可以完整清晰的展示出來。
• 各個調用環節的性能分析
  • 調用鏈的各個環節分表添加調用耗時，可以分析出系統的性能瓶頸，並針對性的優化。
• 數據分析
  • 調用鏈是一條完整的業務日誌，可以得到用戶的行為路徑，彙總分析應用在很多業務場景

設計性能指標

相關軟體與硬體

系統限制

公司服務部署在多個機房中，但是分散式跟蹤的數據需彙總收集並展示，故暫時進行採用不了多機房部署方案。考慮到分散式跟蹤系統類似於ELK系統的基礎服務，部署架構與現有ELK保證一致，核心服務部署在B7機房

設計思路

一般分散式跟蹤系統, 主要有三個部分：數據收集，數據存儲和數據展示。根據系統大小不同，每一部分的結構又有一定變化。譬如，對於大規模分散式系統，數據存儲可分為實時數據和全量數據兩部分，實時數據用於故障排查，全量數據用於系統優化；數據收集除了支持平臺無關和開發語言無關係統的數據收集，還包括非同步數據收集（需要跟蹤隊列中的消息，保證調用的連貫性），以及確保更小的侵入性；數據展示又涉及到數據挖掘和分享。雖然每一部分都可能變的很複雜，但基本原理都類似。

圖1：這個路徑由用戶的X請求發起，穿過一個簡單的服務系統。用字母標識的節點代表分散式系統中的不同處理過程。

分散式服務的跟蹤系統需要記錄在一次特定的請求後系統中完成的所有工作的信息。舉個例子，圖1展現的是一個和5台伺服器相關的一個服務，包括：前端（A），兩個中間層（B和C），以及兩個後端（D和E）。當一個用戶（這個用例的發起人）發起一個請求時，首先到達前端，然後發送兩個RPC到伺服器B和C。B會馬上做出反應，但是C需要和後端的D和E交互之後再返還給A，由A來響應最初的請求。對於這樣一個請求，簡單實用的分散式跟蹤的實現，就是為伺服器上每一次你發送和接收動作來收集跟蹤標識符(message identifiers)和時間戳(timestamped events)。

黑盒和標簽方案

為了將所有記錄條目與發起者慣量上並記錄所有信息，現在有兩種解決方案，黑盒和基於標簽(annotation-based)的監控方案。
黑盒方案採用framework為基礎，將依賴集成進去，對各接入業務線透明。基於標簽的方案，依賴業務線明確標記一個trace id，從而連接每一條記錄和發起者的請求。基於標簽的方案主要缺點很明顯，需要植入與業務無關代碼。所以預設情況下，我們提供基於hjframework公共組件的方案，實現跟蹤系統對業務無感知。同時如果需要顯示使用這個標簽功能的話，我們同樣提供出來，由業務方自行決定是否使用標簽。

技術選型

綜上所述，最終我們覺得採用Zipkin的方式來實現，比較適合公司目前以Http請求為主的場景。雖然採用第三方開源產品，但是客戶端依賴的SDK，仍需我們開發集成到HJFramewor中。針對Node和JS，Zipkin同樣提供對應的前端SDK，我們集成好之後，就能正常使用。

系統設計

整體架構圖及說明

基於Zipkin的基礎上，我們對其架構進行了擴展，基於Google Dapper的概念，設計一套基於Http的分散式跟蹤系統。其種涵蓋了信息的收集，處理和展現。
整體架構如下圖所示，主要由四個部分構成：收集器、數據傳輸、數據存儲、查詢及web界面

收集器

業務方之間依賴我們提供的SDK，進行數據收集。其中SDK主要採用Spring Cloud中分散式跟蹤模塊是Spring Cloud Sleuth。該模塊主要用於收集Spring boot系統中數據，發送至緩衝隊列Kafka中。同時官方提供了針對Node、Python等一些常用的客戶端SDK

數據傳輸

我們在SDK與後端服務之間加了一層Kafka，這樣做既可以實現兩邊工程的解耦，又可以實現數據的延遲消費。我們不希望因為瞬時QPS過高而導致數據丟失，當然為此也付出了一些實效性上的代價。

數據存儲

預設存儲採用ElasticSearch 來保證數據，考慮到數據量的規模，先期只保存最近1個月的數據

查詢及Web界面

查詢主要用來向其他服務提供數據查詢的能力，而Web服務是官方預設提供的圖形化界面，我們會重寫這塊頁面，使之與滬江內部平臺結合起來。

SDK分析

調用鏈跟蹤：把同一個TraceID和SpanID收集起來，按時間排序Timeline，把ParentID串起來就是調用棧。

參考資料

• Google的大規模分散式系統的跟蹤系統Dapper
• Twitter開源的Zipkin
• 窩窩網介紹Tracing的一篇博客