在分布式服務架構下，一個 Web 請求從網關流入，有可能會調用多個服務對請求進行處理，拿到最終結果。這個過程中每個服務之間的通信又是單獨的網絡請求，無論請求經過的哪個服務出了故障或者處理過慢都會對前端造成影響。

處理一個Web請求要調用的多個服務

為了能更方便的查詢哪個環節的服務出現了問題，現在常用的解決方案是為整個系統引入分布式鏈路跟蹤。

在分布式鏈路跟蹤中有兩個重要的概念：跟蹤（trace）和 跨度（ span）。trace 是請求在分布式系統中的整個鏈路視圖，span 則代表整個鏈路中不同服務內部的視圖，span 組合在一起就是整個 trace 的視圖。

在整個請求的調用鏈中，請求會一直攜帶 traceid 往下游服務傳遞，每個服務內部也會生成自己的 spanid 用于生成自己的內部調用視圖，并和traceid一起傳遞給下游服務。

traceid 在請求的整個調用鏈中始終保持不變，所以在日志中可以通過 traceid 查詢到整個請求期間系統記錄下來的所有日志。請求到達每個服務后，服務都會為請求生成spanid，而隨請求一起從上游傳過來的上游服務的 spanid 會被記錄成parent-spanid或者叫 pspanid。當前服務生成的 spanid 隨著請求一起再傳到下游服務時，這個spanid 又會被下游服務當做 pspanid 記錄。

分布式鏈路跟蹤中的trace和span

通過在訪問日志和業務日志里記錄的traceid、spanid 和 pspanid 能完整的還原出整個請求的調用鏈路視圖，對錯誤排查能起到很大的幫助。

上面就是分布式鏈路跟蹤的原理，我們可以自己實現，也可以依賴 opentracing 這種開源的解決方案。一般是在請求到達網關的開始，生成本次請求的traceid 和 在網關服務內的spanid ，將他們放在HTTP 請求頭或者RPC調用的元數據里，在調用下游服務時繼續向下傳遞。下游的RESTful API服務的全局路由中間件和RPC服務的攔截器里會接收請求攜帶的traceid 和生成當次請求在服務內部的spanid，從上游接收到的 spanid 在這里會被轉換成 pspanid。除此之外我們甚至可以把 traceid 和 spanid 注入到一些數據庫連接池應用里，讓記錄的慢SQL日志里同樣能打上 traceid 和 spanid 信息，為請求的響應過慢提供有效的分析數據。

總結

以上是生活随笔為你收集整理的分布式链路跟踪中的 traceid 和 spanid 代表什么？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。