背景
公司業務由數以百計的分布式服務溝通，每一個請求路由過來后，會經過多個業務系統並留下足跡，並產生對各種緩存或者DB的訪問，但是這些分散的數據對於問題排查，或者流程優化比較有限。對於一個跨進程的場景，匯總收集並分析海量日志就顯得尤為重要。在這種架構下，跨進程的業務流會經過很多個微服務的處理和傳遞，我們難免會遇到這樣的問題:
- 一次請求的流量從哪個服務而來？ 最終落到了哪個服務中去？
- 為什么這個請求這么慢? 到底哪個環節出了問題?
- 這個操作需要依賴哪些東西? 是數據庫還是消息隊列? Redis掛了，哪些業務受影響?
對於這個問題，業內已經有了一些實踐和解決方案，通過調用鏈的方式，把一次請求調用過程完整的串聯起來，這樣就實現了對請求條用路徑的監控。在業界，Twitter的Zipkin和淘寶的鷹眼就是類似的系統，它們都起源於Google Dapper論文，就像歷史上Hadoop起源於Google Map/Reduce論文，Hbase起源於Google BigTable論文一樣
設計目標
- 低消耗性：跟蹤系統對業務系統的影響應該做到足夠小。在一些高度優化過的服務，即使一點點損耗也容易察覺到，而且有可能迫使在線負責的部署團隊不得不將跟蹤系統關停
- 低侵入性：作為非業務組件，應當盡可能少侵入或者無侵入業務系統，對於使用方透明，減少開發人員的負擔
- 時效性：從數據的收集產生，到數據計算處理，再到最終展現，都要求盡可能快
- 決策支持：這些數據是否能在決策支持層面發揮作用，特別是從DevOps的角度
- 數據可視化：做到不用看日志通過可視化進行篩選
實現功能
- 故障快速定位
- 調用鏈路跟蹤，一次請求的邏輯軌跡可以完整清晰的展示出來。
- 各個調用環節的性能分析
- 調用鏈的各個環節分表添加調用耗時，可以分析出系統的性能瓶頸，並針對性的優化。
- 數據分析
- 調用鏈是一條完整的業務日志，可以得到用戶的行為路徑，匯總分析應用在很多業務場景
設計性能指標
| 項目 | 指標 |
|---|---|
| kafka | > 5000 Query Per Second |
| 數據延遲 | < 1 Min |
| 查詢延遲 | < 3 Second |
相關軟件與硬件
| 名稱 | 數量 | 備注 |
|---|---|---|
| Kafka | 1套3節點 | 與監控系統共用一套集群，分屬不同Topic |
| ElasticSearch | 1套3節點 | 與ELK共用一套集群，前提ELK需做擴容准備 |
| API機器 | 虛擬機3台 | 公司標准虛擬機配置4core 8G即可 |
系統限制
公司服務部署在多個機房中，但是分布式跟蹤的數據需匯總收集並展示，故暫時進行采用不了多機房部署方案。考慮到分布式跟蹤系統類似於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公共組件的方案，實現跟蹤系統對業務無感知。同時如果需要顯示使用這個標簽功能的話，我們同樣提供出來，由業務方自行決定是否使用標簽。
技術選型
| 公司 | 選項 | 是否開源 | 優缺點 |
|---|---|---|---|
| 淘寶 | EagleEye | 否 | 主要基於內部HSF實現，HSF沒有開源，故鷹眼也沒有開源 |
| Zipkin | 是 | 基於Http實現，支持語言較多，比較適合我們公司業務 | |
| 點評 | CAT | 是 | 自定義改造難度大，代碼比較復雜，侵入代碼，需要埋點 |
| 京東 | Hydra | 是 | 主要基於Dubbo實現，不適合公司Http請求為主的場景 |
綜上所述，最終我們覺得采用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串起來就是調用棧。
