2、調用鏈路性能瓶頸分析
分析某個對外請求接口的調用鏈路上的性能瓶頸，這個瓶頸可能是某個服務內部處理開銷造成的，也可能是某兩個服務間的網絡調用開銷等等原因造成的 。
對于一次調用涉及到數十個以上微服務的復雜調用請求，每次出現的性能瓶頸很可能都會不一樣，此時就需要進行聚合統計，算出性能瓶頸出現頻次的排名，分析出針對性能瓶頸熱點的服務或服務間調用 。
以上僅僅是列舉的部分分析場景，Tracing 提供的信息其實可以支持更多的 Metric 統計和探索式分析場景，本文不再一一例舉 。
02 基于 Zipkin 和 StarRocks 構建鏈路追蹤分析系統 鏈路追蹤系統主要分為數據采集、數據存儲和分析計算三大部分，目前使用最廣泛的開源鏈路追蹤系統是 Zipkin，它主要包括數據采集和分析計算兩大部分，底層的存儲依賴其他存儲系統 。搜狐智能媒體在構建鏈路追蹤系統時，最初采用 Zipkin + ElasticSearch 得方式進行構建，后增加 StarRocks 作為底層存儲系統，并基于 StarRocks 進行分析統計，系統總體架構如下圖 。

圖 7
數據采集 Zipkin 支持客戶端全自動埋點，只需將相關庫引入應用程序中并簡單配置，就可以實現 Span 信息自動生成，Span 信息通過 HTTP 或 Kafka 等方式自動進行上傳 。Zipkin 目前提供了絕大部分語言的埋點采集庫，如 Java 語言的 Spring Cloud 提供了 Sleuth 與 Zipkin 進行深度綁定，對開發人員基本做到透明使用 。為了解決存儲空間，在使用時一般要設置 1/100 左右的采樣率，Dapper 的論文中提到即便是 1/1000 的采樣率，對于跟蹤數據的通用使用層面上，也可以提供足夠多的信息 。
數據模型
對應 圖 6，下面給出了 Zipkin Span 埋點采集示意圖 (圖 8)，具體流程如下：

圖 8
用戶發送給 Service1 的 Request 中，不含有 Trace 和 Span 信息，Service1 會創建一個 Server Span，隨機生成全局唯一的 TraceID（如圖中的 X）和 SpanId（如圖中的 A，此處的 X 和 A 會使用相同的值），記錄 Timestamp 等信息；Service1 在給用戶返回 Response 時，Service1 會統計 Server Span 的處理耗時 Duration，會將包含 TraceID、SpanID、Timestamp、Duration 等信息的 Server Span 完整信息進行上報 。
Service1 向 Service2 發送的請求，會創建一個 Client Span，使用 X 作為 Trace ID，隨機生成全局唯一的 SpanID（如圖中的 B),記錄 Timestamp 等信息，同時 Service1 會將 Trace ID（X）和 SpanID（B）傳遞給 Service2（如在 HTTP 協議的 HEADER 中添加 TraceID 和 SpanID 等相關字段）；Service1 在收到 Service2 的響應后，Service1 會處理 Client Span 相關信息，并將 Client Span 進行上報
Service2 收到 Service1 的 Request 中，包含 Trace（X）和 Span（B）等信息，Service2 會創建一個 Server Span，使用 X 作為 Trace ID，B 作為 SpanID，內部調用msg2.1 和 msg2.2 同時，將 Trace ID（X）和 SpanID（B）傳遞給它們；Service2 在收到 msg2.1 和 msg2.2 的返回后，Service1 會處理 Server Span 相關信息，并將此 Server Span 進行上報
Service2 的 msg2.1 和 msg2.2 會分別創建一個 Messaging Span，使用 X 作為 Trace ID，隨機生成全局唯一的 SpanID（如圖中的 C 和 F),記錄 Timestamp 等信息，分別向 Service3 和 Service4 發送請求；msg2.1 和 msg2.2 收到響應后，會分別處理 Messaging Span 相關信息，并將兩個 Messaging Span 進行上報
Service2 向 Service3 和 Service4 發送的請求，會各創建一個 Client Span，使用 X 作為 Trace ID，隨機生成全局唯一的 SpanID（如圖中的 D 和 G),記錄 Timestamp 等信息，同時 Service2 會將 Trace ID（X）和 SpanID（D 或 G）傳遞給 Service3 和 Service4；Service12 在收到 Service3 和 Service3 的響應后，Service2 會分別處理 Client Span 相關信息，并將兩個 Client Span 進行上報
Service3 收到 Service2 的Request中，包含 Trace（X）和Span（D）等信息，Service3 會創建一個 Server Span，使用 X 作為 Trace ID，D 作為 SpanID，內部調用 msg3；Service3 在收到 msg3 的返回后，Service3 會處理此 Server Span 相關信息，并將此 Server Span 進行上報
Service3 的 msg3 會分別創建一個 Messaging Span，使用 X 作為 Trace ID，隨機生成全局唯一的 SpanID（如圖中的 E),記錄 Timestamp 等信息，msg3 處理完成后，處理此 Messaging Span 相關信息，并將此 Messaging Span 進行上報
Service4 收到 Service2 的 Request 中，包含 Trace（X）和 Span（G）等信息，Service4 會創建一個 Server Span，使用 X 作為 Trace ID，G 作為 SpanID，再向 Service5 發送請求；Service4 在收到 Service5 的響應后，Service4 會處理此 Server Span 相關信息，并將此 Server Span 進行上報

• 中國民間故事哪個是正版,中國民間故事立人搜狐版
• 今日上市，理想L9詳解，5.3秒破百，尺寸接近寶馬X7，堪稱奶爸神車！
• bios功能設置，bios設置圖文詳解
• 太極拳二路暴垂視頻-陳式太極拳八式詳解
• 萬字果泡酒功效和作用 萬字果泡酒
• 詳解鐵觀音其他品種,鐵觀音鐵盒紅色包裝
• 臺式電腦怎么查看配置參數，怎么查看電腦配置參數詳解
• 關于孕婦不能吃的食物詳解
• 有助準媽媽安胎的食療方詳解
• 黃芪的十八大藥理作用詳解