分佈式跟蹤調研與設計

背景

公司業務由數以百計的分佈式服務溝通，每個請求路由過來後，會通過多個業務系統並留下足跡，併產生對各類緩存或者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沒有開源，故鷹眼也沒有開源
Twitter	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串起來就是調用棧。

參考資料

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