基本概念
分布式調用鏈標準-openTracing
Span-節點組成跟蹤樹結構
有一些特定的變量，SpanName SpanId traceId spanParentId
Trace（追蹤）：代表一個完整的請求流程（如用戶下單），由多個Span組成
Span（跨度）：請求經過的單個服務或操作（如訂單服務調用支付服務）
包含：開始/結束時間、服務名、調用關系等
Context（上下文）：傳遞Trace ID、Span ID等，確保鏈路連續
分布式鏈路追蹤 = Trace ID串聯全局 + Span記錄局部 + 上下文傳遞
Span節點必須包含的內容
OperationName：操作名稱
BeiginTime：開始時間
EndTime：結束時間
SpanTag：是一組鍵值對構成的Span的標簽集合（key必須是String類型，value可以是String，Boolean和數字類型），這個的目的是為Span添加更多的描述信息
SpanLog：一組Span的日志集合，是鍵值對，記錄日志信息
SpanContext：是一個上下文對象，會從上一個節點傳遞到下一個節點，里面包含了traceId，SpanId，Baggage（這是一個跨Span集合，上一個節點往Baggage加信息下一個節點可以拿到，不要放太多信息不然會導致占用空間大影響效率）,我們通過上下文對象去進行跨進程傳遞
TraceSegment和TraceId原理
TraceSegment：
- 指的是一個進程中所有的Span的集合
- 如果多個線程協同產生同一個Trace（例如多個RPC調用不同的方法），它們只會共同創建一個TraceSegment
- 支持多入口，所以Skywalking去除了樹節點RootSpan的概念，提出了三種Span模型
TraceId：
- TraceId應該是全局唯一的
- 我們的TraceId是根據時間錯+算法生成的，所以會有時間回撥問題
- 我們有個變量lastTimeStamp保存上次TraceId生成的時間，然后在生成TraceId前進行比較，如果CuurentTimeMills比lastTimeStamp時間小，說明時間回撥了，我們就不生成Id，這樣來保證TraceId全局唯一
概念簡單總結
三個基本概念：Trace追蹤，Span服務，Context上下文（用來傳遞信息）
分布式鏈路追蹤 = Trace ID串聯全局 + Span記錄局部 + 上下文傳遞
Span中包含starTime，endTime，SpanContetx（上下文用來傳遞信息，包含TraceId，SpanId），
SpanTag（服務的標簽）,SpanLog（服務的日志信息）
TraceSegment（追蹤段）：一個進程中所有的Span的集合
TraceId：全局唯一，依賴時間戳，保存上次TraceId生成的時間，生成ID時時間戳進行對比，防止時間回撥問題
全鏈路追蹤的工作流
階段1：鏈路數據生成（埋點）
自動埋點：通過SDK或Agent自動在服務框架（如Spring Cloud、Dubbo）中注入追蹤邏輯。
手動埋點：在業務代碼中手動標記關鍵操作（如支付流程）。
示例：用戶下單時，網關生成Trace ID=ABC，創建根Span（Span ID=1）
階段2：鏈路數據采集與傳輸
采集方式：通過Agent或Sidecar（如Envoy）實時收集Span數據。
傳輸協議：通過gRPC、HTTP等將數據發送到Collector（如Jaeger Collector）。
示例：訂單服務（Span ID=2）和庫存服務（Span ID=3）的Span通過Kafka發送到收集器。
階段3：鏈路數據存儲
存儲后端：使用時序數據庫（如InfluxDB）、列式存儲（如Cassandra）或Elasticsearch。
數據模型：按Trace ID聚合Span，建立索引（如服務名、耗時、錯誤碼）。
示例：Trace ID=ABC的所有Span被存儲為一條完整鏈路。
階段4：數據查詢與分析
可視化：通過UI工具（如Zipkin、SkyWalking）展示火焰圖、調用拓撲。
分析能力：支持按服務名、耗時、錯誤碼過濾，自動統計P99延遲、錯誤率。
示例：發現庫存服務（Span ID=3）平均耗時500ms，觸發告警
流程簡單總結
- 鏈路數據生成：在進入Span服務前生成數據，一般來說再進入服務器會有自定義數據處理or服務啟動前的Agent增強讓服務有了多余的自定義邏輯
- 實時采集與傳輸鏈路數據：通過Http或者grpc采集和傳輸鏈路追蹤的數據
- 鏈路數據存儲：存儲鏈路追蹤的數據
- 數據查詢與分析可視化：通過可視化頁面展示詳細的鏈路追蹤流程和數據，顯示服務細節，耗時，錯誤等
教程)
