## **1、日志跟蹤** 在分布式服務架構下，一個 Web 請求從網關流入，有可能會調用多個服務對請求進行處理，拿到最終結果。這個過程中每個服務之間的通信又是單獨的網絡請求，無論請求經過的哪個服務出了故障或者處理過慢都會對前端造成影響。 處理一個Web請求要調用的多個服務，為了能更方便的查詢哪個環節的服務出現了問題，現在常用的解決方案是為整個系統引入分布式鏈路跟蹤。  在分布式鏈路跟蹤中有兩個重要的概念：跟蹤（trace）和 跨度（ span）。trace 是請求在分布式系統中的整個鏈路視圖，span 則代表整個鏈路中不同服務內部的視圖，span 組合在一起就是整個 trace 的視圖。 在整個請求的調用鏈中，請求會一直攜帶 traceid 往下游服務傳遞，每個服務內部也會生成自己的 spanid 用于生成自己的內部調用視圖，并和traceid一起傳遞給下游服務。 ## **2、TraceId 生成規則** 這種場景下，生成的ID除了要求唯一之外，還要求生成的效率高、吞吐量大。traceid需要具備接入層的服務器實例自主生成的能力，如果每個trace中的ID都需要請求公共的ID服務生成，純純的浪費網絡帶寬資源。且會阻塞用戶請求向下游傳遞，響應耗時上升，增加了沒必要的風險。所以需要服務器實例最好可以自行計算tracid，spanid，避免依賴外部服務。 產生規則：服務器 IP + ID 產生的時間 + 自增序列 + 當前進程號 ，比如： 0ad1348f1403169275002100356696 前 8 位?0ad1348f 即產生 TraceId 的機器的 IP，這是一個十六進制的數字，每兩位代表 IP 中的一段，我們把這個數字，按每兩位轉成 10 進制即可得到常見的 IP 地址表示方式 10.209.52.143，您也可以根據這個規律來查找到請求經過的第一個服務器。 后面的 13 位 1403169275002 是產生 TraceId 的時間。之后的 4 位 1003 是一個自增的序列，從 1000 漲到 9000，到達 9000 后回到 1000 再開始往上漲。最后的 5 位 56696 是當前的進程 ID，為了防止單機多進程出現 TraceId 沖突的情況，所以在 TraceId 末尾添加了當前的進程 ID。 ## **3、SpanId 生成規則** span是層的意思，比如在第一個實例算是第一層， 請求代理或者分流到下一個實例處理，就是第二層，以此類推。通過層，SpanId 代表本次調用在整個調用鏈路樹中的位置。 假設一個 服務器實例 A 接收了一次用戶請求，代表是整個調用的根節點，那么A 層處理這次請求產生的非服務調用日志記錄spanid的值都是0，A層需要通過 RPC 依次調用 B、C、D 三個服務器實例，那么在 A 的日志中，SpanId 分別是 0.1，0.2 和 0.3，在 B、C、D 中，SpanId 也分別是 0.1，0.2 和 0.3；如果 C 系統在處理請求的時候又調用了 E，F 兩個服務器實例，那么 C 系統中對應的spanid是 0.2.1 和 0.2.2，E、F 兩個系統對應的日志也是 0.2.1 和 0.2.2。 根據上面的描述可以知道，如果把一次調用中所有的 SpanId 收集起來，可以組成一棵完整的鏈路樹。 **spanid的生成本質：在跨層傳遞透傳的同時，控制大小版本號的自增來實現的。**