Go?分布式鏈路追蹤實現(xiàn)原理解析
在分布式、微服務(wù)架構(gòu)下,應(yīng)用一個請求往往貫穿多個分布式服務(wù),這給應(yīng)用的故障排查、性能優(yōu)化帶來新的挑戰(zhàn)。分布式鏈路追蹤作為解決分布式應(yīng)用可觀測問題的重要技術(shù),愈發(fā)成為分布式應(yīng)用不可缺少的基礎(chǔ)設(shè)施。本文將詳細介紹分布式鏈路的核心概念、架構(gòu)原理和相關(guān)開源標(biāo)準協(xié)議,并分享我們在實現(xiàn)無侵入 Go 采集 Sdk 方面的一些實踐。
為什么需要分布式鏈路追蹤系統(tǒng)
微服務(wù)架構(gòu)給運維、排障帶來新挑戰(zhàn)
在分布式架構(gòu)下,當(dāng)用戶從瀏覽器客戶端發(fā)起一個請求時,后端處理邏輯往往貫穿多個分布式服務(wù),這時會浮現(xiàn)很多問題,比如:
- 請求整體耗時較長,具體慢在哪個服務(wù)?
- 請求過程中出錯了,具體是哪個服務(wù)報錯?
- 某個服務(wù)的請求量如何,接口成功率如何?
回答這些問題變得不是那么簡單,我們不僅僅需要知道某一個服務(wù)的接口處理統(tǒng)計數(shù)據(jù),還需要了解兩個服務(wù)之間的接口調(diào)用依賴關(guān)系,只有建立起整個請求在多個服務(wù)間的時空順序,才能更好的幫助我們理解和定位問題,而這,正是分布式鏈路追蹤系統(tǒng)可以解決的。
分布式鏈路追蹤系統(tǒng)如何幫助我們
分布式鏈路追蹤技術(shù)的核心思想:在用戶一次分布式請求服務(wù)的調(diào)?過程中,將請求在所有子系統(tǒng)間的調(diào)用過程和時空關(guān)系追蹤記錄下來,還原成調(diào)用鏈路集中展示,信息包括各個服務(wù)節(jié)點上的耗時、請求具體到達哪臺機器上、每個服務(wù)節(jié)點的請求狀態(tài)等等。
如上圖所示,通過分布式鏈路追蹤構(gòu)建出完整的請求鏈路后,可以很直觀地看到請求耗時主要耗費在哪個服務(wù)環(huán)節(jié),幫助我們更快速聚焦問題。
同時,還可以對采集的鏈路數(shù)據(jù)做進一步的分析,從而可以建立整個系統(tǒng)各服務(wù)間的依賴關(guān)系、以及流量情況,幫助我們更好地排查系統(tǒng)的循環(huán)依賴、熱點服務(wù)等問題。
分布式鏈路追蹤系統(tǒng)架構(gòu)概覽
核心概念
在分布式鏈路追蹤系統(tǒng)中,最核心的概念,便是鏈路追蹤的數(shù)據(jù)模型定義,主要包括 Trace 和 Span。
其中,Trace 是一個邏輯概念,表示一次(分布式)請求經(jīng)過的所有局部操作(Span)構(gòu)成的一條完整的有向無環(huán)圖,其中所有的 Span 的 TraceId 相同。
Span 則是真實的數(shù)據(jù)實體模型,表示一次(分布式)請求過程的一個步驟或操作,代表系統(tǒng)中一個邏輯運行單元,Span 之間通過嵌套或者順序排列建立因果關(guān)系。Span 數(shù)據(jù)在采集端生成,之后上報到服務(wù)端,做進一步的處理。其包含如下關(guān)鍵屬性:
- Name:操作名稱,如一個 RPC 方法的名稱,一個函數(shù)名
- StartTime/EndTime:起始時間和結(jié)束時間,操作的生命周期
- ParentSpanId:父級 Span 的 ID
- Attributes:屬性,一組 <K,V> 鍵值對構(gòu)成的集合
- Event:操作期間發(fā)生的事件
- SpanContext:Span 上下文內(nèi)容,通常用于在 Span 間傳播,其核心字段包括 TraceId、SpanId
一般架構(gòu)
分布式鏈路追蹤系統(tǒng)的核心任務(wù)是:圍繞 Span 的生成、傳播、采集、處理、存儲、可視化、分析,構(gòu)建分布式鏈路追蹤系統(tǒng)。其一般的架構(gòu)如下如所示:
- 我們看到,在應(yīng)用端需要通過侵入或者非侵入的方式,注入 Tracing Sdk,以跟蹤、生成、傳播和上報請求調(diào)用鏈路數(shù)據(jù);
- Collect agent 一般是在靠近應(yīng)用側(cè)的一個邊緣計算層,主要用于提高 Tracing Sdk 的寫性能,和減少 back-end 的計算壓力;
- 采集的鏈路跟蹤數(shù)據(jù)上報到后端時,首先經(jīng)過 Gateway 做一個鑒權(quán),之后進入 kafka 這樣的 MQ 進行消息的緩沖存儲;
- 在數(shù)據(jù)寫入存儲層之前,我們可能需要對消息隊列中的數(shù)據(jù)做一些清洗和分析的操作,清洗是為了規(guī)范和適配不同的數(shù)據(jù)源上報的數(shù)據(jù),分析通常是為了支持更高級的業(yè)務(wù)功能,比如流量統(tǒng)計、錯誤分析等,這部分通常采用flink這類的流處理框架來完成;
- 存儲層會是服務(wù)端設(shè)計選型的一個重點,要考慮數(shù)據(jù)量級和查詢場景的特點來設(shè)計選型,通常的選擇包括使用 Elasticsearch、Cassandra、或 Clickhouse 這類開源產(chǎn)品;
- 流處理分析后的結(jié)果,一方面作為存儲持久化下來,另一方面也會進入告警系統(tǒng),以主動發(fā)現(xiàn)問題來通知用戶,如錯誤率超過指定閾值發(fā)出告警通知這樣的需求等。
剛才講的,是一個通用的架構(gòu),我們并沒有涉及每個模塊的細節(jié),尤其是服務(wù)端,每個模塊細講起來都要很花些功夫,受篇幅所限,我們把注意力集中到靠近應(yīng)用側(cè)的 Tracing Sdk,重點看看在應(yīng)用側(cè)具體是如何實現(xiàn)鏈路數(shù)據(jù)的跟蹤和采集的。
協(xié)議標(biāo)準和開源實現(xiàn)
剛才我們提到 Tracing Sdk,其實這只是一個概念,具體到實現(xiàn),選擇可能會非常多,這其中的原因,主要是因為:
- 不同的編程語言的應(yīng)用,可能采用不同技術(shù)原理來實現(xiàn)對調(diào)用鏈的跟蹤
- 不同的鏈路追蹤后端,可能采用不同的數(shù)據(jù)傳輸協(xié)議
當(dāng)前,流行的鏈路追蹤后端,比如 Zipin、Jaeger、PinPoint、Skywalking、Erda,都有供應(yīng)用集成的 sdk,導(dǎo)致我們在切換后端時應(yīng)用側(cè)可能也需要做較大的調(diào)整。
社區(qū)也出現(xiàn)過不同的協(xié)議,試圖解決采集側(cè)的這種亂象,比如 OpenTracing、OpenCensus 協(xié)議,這兩個協(xié)議也分別有一些大廠跟進支持,但最近幾年,這兩者已經(jīng)走向了融合統(tǒng)一,產(chǎn)生了一個新的標(biāo)準 OpenTelemetry,這兩年發(fā)展迅猛,已經(jīng)逐漸成為行業(yè)標(biāo)準。
OpenTelemetry 定義了數(shù)據(jù)采集的標(biāo)準 api,并提供了一組針對多語言的開箱即用的 sdk 實現(xiàn)工具,這樣,應(yīng)用只需要與 OpenTelemetry 核心 api 包強耦合,不需要與特定的實現(xiàn)強耦合。
應(yīng)用側(cè)調(diào)用鏈跟蹤實現(xiàn)方案概覽
應(yīng)用側(cè)核心任務(wù)
應(yīng)用側(cè)圍繞 Span,有三個核心任務(wù)要完成:
- 生成 Span:操作開始構(gòu)建 Span 并填充 StartTime,操作完成時填充 EndTime 信息,期間可追加 Attributes、Event 等
- 傳播 Span:進程內(nèi)通過 context.Context、進程間通過請求的 header 作為 SpanContext 的載體,傳播的核心信息是 TraceId 和 ParentSpanId
- 上報 Span:生成的 Span 通過 tracing exporter 發(fā)送給 collect agent / back-end server
要實現(xiàn) Span 的生成和傳播,要求我們能夠攔截應(yīng)用的關(guān)鍵操作(函數(shù))過程,并添加 Span 相關(guān)的邏輯。實現(xiàn)這個目的會有很多方法,不過,在羅列這些方法之前,我們先看看在 OpenTelemetry 提供的 go sdk 中是如何做的。
基于 OTEL 庫實現(xiàn)調(diào)用攔截
OpenTelemetry 的 go sdk 實現(xiàn)調(diào)用鏈攔截的基本思路是:基于 AOP 的思想,采用裝飾器模式,通過包裝替換目標(biāo)包(如 net/http)的核心接口或組件,實現(xiàn)在核心調(diào)用過程前后添加 Span 相關(guān)邏輯。當(dāng)然,這樣的做法是有一定的侵入性的,需要手動替換使用原接口實現(xiàn)的代碼調(diào)用改為包裝接口實現(xiàn)。
我們以一個 http server 的例子來說明,在 go 語言中,具體是如何做的:
假設(shè)有兩個服務(wù) serverA 和 serverB,其中 serverA 的接口收到請求后,內(nèi)部會通過 httpclient 進一步發(fā)起到 serverB 的請求,那么 serverA 的核心代碼可能如下圖所示:
以 serverA 節(jié)點為例,在 serverA 節(jié)點應(yīng)該產(chǎn)生至少兩個 Span:
- Span1,記錄 httpServer 收到一個請求后內(nèi)部整體處理過程的一個耗時情況
- Span2,記錄 httpServer 處理請求過程中,發(fā)起的另一個到 serverB 的 http 請求的耗時情況
- 并且 Span1 應(yīng)該是 Span2 的 ParentSpan
我們可以借助 OpenTelemetry 提供的 sdk 來實現(xiàn) Span 的生成、傳播和上報,上報的邏輯受篇幅所限我們不再詳述,重點來看看如何生成這兩個 Span,并使這兩個 Span 之間建立關(guān)聯(lián),即 Span 的生成和傳播 。
HttpServer Handler 生成 Span 過程
對于 httpserver 來講,我們知道其核心就是 http.Handler 這個接口。因此,可以通過實現(xiàn)一個針對 http.Handler 接口的攔截器,來負責(zé) Span 的生成和傳播。
package http type Handler interface { ServeHTTP(ResponseWriter, *Request) } http.ListenAndServe(":8090", http.DefaultServeMux)
要使用 OpenTelemetry Sdk 提供的 http.Handler 裝飾器,需要如下調(diào)整 http.ListenAndServe 方法:
import ( "net/http" "go.opentelemetry.io/otel" "go.opentelemetry.io/otel/sdk/trace" "go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp" ) wrappedHttpHandler := otelhttp.NewHandler(http.DefaultServeMux, ...) http.ListenAndServe(":8090", wrappedHttpHandler)
如圖所示,wrppedHttpHandler 中將主要實現(xiàn)如下邏輯(精簡考慮,此處部分為偽代碼):
① ctx := tracer.Extract(r.ctx, r.Header)
:從請求的 header 中提取 traceparent header 并解析,提取 TraceId和 SpanId,進而構(gòu)建 SpanContext 對象,并最終存儲在 ctx 中;
② ctx, span := tracer.Start(ctx, genOperation(r))
:生成跟蹤當(dāng)前請求處理過程的 Span(即前文所述的Span1),并記錄開始時間,這時會從 ctx 中讀取 SpanContext,將 SpanContext.TraceId 作為當(dāng)前 Span 的TraceId,將 SpanContext.SpanId 作為當(dāng)前 Span的ParentSpanId,然后將自己作為新的 SpanContext 寫入返回的 ctx 中;
③ r.WithContext(ctx)
:將新生成的 SpanContext 添加到請求 r 的 context 中,以便被攔截的 handler 內(nèi)部在處理過程中,可以從 r.ctx 中拿到 Span1 的 SpanId 作為其 ParentSpanId 屬性,從而建立 Span 之間的父子關(guān)系;
④ span.End()
:當(dāng) innerHttpHandler.ServeHTTP(w,r) 執(zhí)行完成后,就需要對 Span1 記錄一下處理完成的時間,然后將它發(fā)送給 exporter 上報到服務(wù)端。
HttpClient 請求生成 Span 過程
我們再接著看 serverA 內(nèi)部去請求 serverB 時的 httpclient 請求是如何生成 Span 的(即前文說的 Span2)。我們知道,httpclient 發(fā)送請求的關(guān)鍵操作是 http.RoundTriper 接口:
package http type RoundTripper interface { RoundTrip(*Request) (*Response, error) }
OpenTelemetry 提供了基于這個接口的一個攔截器實現(xiàn),我們需要使用這個實現(xiàn)包裝一下 httpclient 原來使用的 RoundTripper 實現(xiàn),代碼調(diào)整如下:
import ( "net/http" "go.opentelemetry.io/otel" "go.opentelemetry.io/otel/sdk/trace" "go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp" ) wrappedTransport := otelhttp.NewTransport(http.DefaultTransport) client := http.Client{Transport: wrappedTransport}
如圖所示,wrappedTransport 將主要完成以下任務(wù)(精簡考慮,此處部分為偽代碼):
① req, _ := http.NewRequestWithContext(r.ctx, “GET”,url, nil)
:這里我們將上一步 http.Handler 的請求的 ctx,傳遞到 httpclient 要發(fā)出的 request 中,這樣在之后我們就可以從 request.Context() 中提取出 Span1 的信息,來建立 Span 之間的關(guān)聯(lián);
② ctx, span := tracer.Start(r.Context(), url)
:執(zhí)行 client.Do() 之后,將首先進入 WrappedTransport.RoundTrip() 方法,這里生成新的 Span(Span2),開始記錄 httpclient 請求的耗時情況,與前文一樣,Start 方法內(nèi)部會從 r.Context() 中提取出 Span1 的 SpanContext,并將其 SpanId 作為當(dāng)前 Span(Span2)的 ParentSpanId,從而建立了 Span 之間的嵌套關(guān)系,同時返回的 ctx 中保存的 SpanContext 將是新生成的 Span(Span2)的信息;
③ tracer.Inject(ctx, r.Header)
:這一步的目的是將當(dāng)前 SpanContext 中的 TraceId 和 SpanId 等信息寫入到 r.Header 中,以便能夠隨著 http 請求發(fā)送到 serverB,之后在 serverB 中與當(dāng)前 Span 建立關(guān)聯(lián);
④ span.End()
:等待 httpclient 請求發(fā)送到 serverB 并收到響應(yīng)以后,標(biāo)記當(dāng)前 Span 跟蹤結(jié)束,設(shè)置 EndTime 并提交給 exporter 以上報到服務(wù)端。
基于 OTEL 庫實現(xiàn)調(diào)用鏈跟蹤總結(jié)
我們比較詳細的介紹了使用 OpenTelemetry 庫,是如何實現(xiàn)鏈路的關(guān)鍵信息(TraceId、SpanId)是如何在進程間和進程內(nèi)傳播的,我們對這種跟蹤實現(xiàn)方式做個小的總結(jié):
如上分析所展示的,使用這種方式的話,對代碼還是有一定的侵入性,并且對代碼有另一個要求,就是保持 context.Context 對象在各操作間的傳遞,比如,剛才我們在 serverA 中創(chuàng)建 httpclient 請求時,使用的是http.NewRequestWithContext(r.ctx, ...)
而非http.NewRequest(...)
方法,另外開啟 goroutine 的異步場景也需要注意 ctx 的傳遞。
非侵入調(diào)用鏈跟蹤實現(xiàn)思路
我們剛才詳細展示了基于常規(guī)的一種具有一定侵入性的實現(xiàn),其侵入性主要表現(xiàn)在:我們需要顯式的手動添加代碼使用具有跟蹤功能的組件包裝原代碼,這進一步會導(dǎo)致應(yīng)用代碼需要顯式的引用具體版本的 OpenTelemetry instrumentation 包,這不利于可觀測代碼的獨立維護和升級。
那我們有沒有可以實現(xiàn)非侵入跟蹤調(diào)用鏈的方案可選?
所謂無侵入,其實也只是集成的方式不同,集成的目標(biāo)其實是差不多的,最終都是要通過某種方式,實現(xiàn)對關(guān)鍵調(diào)用函數(shù)的攔截,并加入特殊邏輯,無侵入重點在于代碼無需修改或極少修改。
上圖列出了現(xiàn)在可能的一些無侵入集成的實現(xiàn)思路,與 .net、java 這類有 IL 語言的編程語言不同,go 直接編譯為機器碼,導(dǎo)致無侵入的方案實現(xiàn)起來相對比較麻煩,具體有如下幾種思路:
編譯階段注入:可以擴展編譯器,修改編譯過程中的ast,插入跟蹤代碼,需要適配不同編譯器版本。啟動階段注入:修改編譯后的機器碼,插入跟蹤代碼,需要適配不同 CPU 架構(gòu)。如 monkey, gohook。運行階段注入:通過內(nèi)核提供的 eBPF 能力,監(jiān)聽程序關(guān)鍵函數(shù)執(zhí)行,插入跟蹤代碼,前景光明!如,tcpdump,bpftrace。
Go 非侵入鏈路追蹤實現(xiàn)原理
Erda 項目的核心代碼主要是基于 golang 編寫的,我們基于前文所述的 OpenTelemetry sdk,采用基于修改機器碼的的方式,實現(xiàn)了一種無侵入的鏈路追蹤方式。
前文提到,使用 OpenTelemetry sdk 需要代碼做一些調(diào)整,我們看看這些調(diào)整如何以非侵入的方式自動的完成:
我們以 httpclient 為例,做簡要的解釋。
gohook 框架提供的 hook 接口的簽名如下:
// target 要hook的目標(biāo)函數(shù) // replacement 要替換為的函數(shù) // trampoline 將源函數(shù)入口拷貝到的位置,可用于從replcement跳轉(zhuǎn)回原target func Hook(target, replacement, trampoline interface{}) error
對于 http.Client
,我們可以選擇 hook DefaultTransport.RoundTrip()
方法,當(dāng)該方法執(zhí)行時,我們通過 otelhttp.NewTransport()
包裝起原 DefaultTransport
對象,但需要注意的是,我們不能將 DefaultTransport
直接作為 otelhttp.NewTransport()
的參數(shù),因為其 RoundTrip()
方法已經(jīng)被我們替換了,而其原來真正的方法被寫到了 trampoline
中,所以這里我們需要一個中間層,來連接 DefaultTransport
與其原來的 RoundTrip
方法。具體代碼如下:
//go:linkname RoundTrip net/http.(*Transport).RoundTrip //go:noinline // RoundTrip . func RoundTrip(t *http.Transport, req *http.Request) (*http.Response, error) //go:noinline func originalRoundTrip(t *http.Transport, req *http.Request) (*http.Response, error) { return RoundTrip(t, req) } type wrappedTransport struct { t *http.Transport } //go:noinline func (t *wrappedTransport) RoundTrip(req *http.Request) (*http.Response, error) { return originalRoundTrip(t.t, req) } //go:noinline func tracedRoundTrip(t *http.Transport, req *http.Request) (*http.Response, error) { req = contextWithSpan(req) return otelhttp.NewTransport(&wrappedTransport{t: t}).RoundTrip(req) } //go:noinline func contextWithSpan(req *http.Request) *http.Request { ctx := req.Context() if span := trace.SpanFromContext(ctx); !span.SpanContext().IsValid() { pctx := injectcontext.GetContext() if pctx != nil { if span := trace.SpanFromContext(pctx); span.SpanContext().IsValid() { ctx = trace.ContextWithSpan(ctx, span) req = req.WithContext(ctx) } } } return req } func init() { gohook.Hook(RoundTrip, tracedRoundTrip, originalRoundTrip) }
我們使用 init()
函數(shù)實現(xiàn)了自動添加 hook,因此用戶程序里只需要在 main 文件中 import 該包,即可實現(xiàn)無侵入的集成。
值得一提的是 req = contextWithSpan(req)
函數(shù),內(nèi)部會依次嘗試從 req.Context()
和 我們保存的 goroutineContext map
中檢查是否包含 SpanContext
,并將其賦值給 req
,這樣便可以解除了必須使用 http.NewRequestWithContext(...)
寫法的要求。
詳細的代碼可以查看 Erda 倉庫:https://github.com/erda-project/erda-infra/tree/master/pkg/trace
參考鏈接
https://opentelemetry.io/registry/
https://opentelemetry.io/docs/instrumentation/go/getting-started/
https://www.ipeapea.cn/post/go-asm/
https://github.com/brahma-adshonor/gohook
https://www.jianshu.com/p/7b3638b47845
https://paper.seebug.org/1749/
到此這篇關(guān)于Go 分布式鏈路追蹤實現(xiàn)原理的文章就介紹到這了,更多相關(guān)Go 分布式鏈路追蹤內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
golang使用bcrypt包對密碼進行加密的方法實現(xiàn)
本文主要介紹了golang使用bcrypt包對密碼進行加密的方法實現(xiàn),文中通過示例代碼介紹的非常詳細,對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2023-07-07Go項目與Docker結(jié)合實現(xiàn)高效部署深入探究
在現(xiàn)代軟件開發(fā)中,使用Docker部署應(yīng)用程序已經(jīng)成為一種標(biāo)準實踐,本文將深入探討如何將Go項目與Docker結(jié)合,實現(xiàn)高效、可靠的部署過程,通過詳細的步驟和豐富的示例,你將能夠迅速掌握這一流程2023-12-12Go語言中TCP/IP網(wǎng)絡(luò)編程的深入講解
這篇文章主要給大家介紹了關(guān)于Go語言中TCP/IP網(wǎng)絡(luò)編程的相關(guān)資料,文中通過示例代碼介紹的非常詳細,對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2018-05-05