追蹤微服務調用的背景——快速定位服務調用失敗的原因。
除此還有如下幾個作用：
一、優化系統瓶頸
通過記錄調用經過的每一條鏈路上的耗時，快速定位整個系統的瓶頸所在，做出針對性的優化。
二、優化鏈路調用
通過服務追蹤可以分析調用所經過的路徑，然后評估是否合理。比如一個服務調用下游依賴了多個服務，通過鏈路分析，可以評估是否每個依賴都是必須的，是否可以通過優化業務來減少服務依賴。
三、生成網絡拓撲
通過服務追蹤系統中記錄的鏈路信息，可以生成一張系統的網絡拓撲調用圖，反應系統依賴了哪些服務，以及服務之間的調用的關系是什么樣的。在網絡拓撲圖上還可以把服務調用的詳細信息標出來，起到服務監控作用。
四、透明傳輸數據
除了服務追蹤，業務上還經常與一種需求，期望把用戶數據，從調用的開始一直往下傳，以便系統中各個服務都能獲取到這個信息。比如業務想做一些A/B測試，這時候能通過服務追蹤系統，把A/B測試的開關邏輯一直往下傳遞，經過的每一層服務都能獲取到這個開關值，就能夠統一進行A/B測試。
服務追蹤系統原理
核心理念：通過全局唯一ID將分布在各個服務節點上的同一次請求串聯起來，從而還原原有的調用關系，可以追蹤系統問題、分析調用數據並統計各個系統指標。（Google一篇論文——Dapper）
由此衍生出：Twitter的Zipkin、阿里的鷹眼、美團MTrace（如下圖）等
traceId：用戶標識某一次具體的請求ID。當用戶的請求進入系統后，會在RPC調用網絡的第一層生成一個全局唯一的traceId，並且會隨着每一層的RPC調用，不斷往后傳遞，這樣通過traceId就可以把一次用戶請求在系統中調用的路徑串聯起來。
spanId：用於標識一次RPC調用在分布式請求中位置。當用戶的請求進入系統中，處在RPC調用網絡的第一層A時spanId初始值是0，進入下一層RPC調用B的時候spanId是0.1，繼續進入下一層RPC調用C時spanId時0.1.1，而與B處在同一層RPC調用E的spanId時0.2，這樣的話，通過spanId就可以通過spanId就可以定位某一次RPC請求在系統調用中所處的位置，以及它的上下游依賴是誰。
annotation：用於業務自定義埋點數據，可以時業務感興趣的想上傳到后端的數據，比如一次請求的用戶UID。
服務追蹤系統的架構
服務追蹤系統架構圖如上，可以分為三層
數據采集層——負責數據埋點並上報
數據處理層——負責數據的存儲與計算
數據展示層——負責數據的圖形化展示。