公司業務由數以百計的分布式服務溝通，每一個請求路由過來後，會經過多個業務系統并留下足迹，并産生對各種緩存或者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
與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服務是官方預設提供的圖形化界面，我們會重寫這塊頁面，使之與滬江内部平台結合起來。
調用鍊跟蹤：把同一個TraceID和SpanID收集起來，按時間排序Timeline，把ParentID串起來就是調用棧。
