背景

圖片

圖片

圖片

前段時間有朋友問我關于 spring cloud 的應用在調用到 Go 的 API 之后出現 Trace 沒有串聯起來的問題。

完整的調用流程如下：

┌──────┐             
│Client│             
└┬─────┘             
┌▽──────────────────┐
│SpringCloud GateWay│
└┬──────────────────┘
┌▽──────────────┐    
│SpringBoot(app)│    
└┬──────────────┘    
┌▽──────────┐        
│Feign(http)│        
└┬──────────┘        
┌▽─────┐             
│Go Gin│             
└──────┘

根因

在解決這個問題之前想要搞清楚 Trace 是如何跨語言以及跨應用傳遞的。

其實也可以類比為在分布式系統中如何傳遞上下文；既然要傳遞數據那就涉及到系統之間的調用，也就是我們常說的 RPC（remote procedure call)。

提到 PRC 我們常見的一般有兩種協議：

? 基于 HTTP 協議，簡單易讀，兼容性好

? 基于 TCP 的私有協議，高效性能更佳

基于 TCP 私有協議的又誕生出許多流行的框架，比如：

? Dubbo

? Thrift

? gRPC(基于 HTTP2,嚴格來說不算私有協議)

? 基于 MQ 實現的 RPC（生產消費者模式，本質上這些 MQ 都是私有協議，比如 RocketMQ、Pulsar 等）

但我們需要在 RPC 調用的過程中在上下文里包含 Trace 時，通常都是將 TraceId 作為元數據進行傳遞。

對于 HTTP 來說就是 header、而其余的私有 TCP 協議通常也會提供一個元數據的結構用于存放一些非業務數據。

圖片

圖片

圖片

比如在 OpenTelemetry-Go 的 sdk 中，會在一次 RPC 中對 Trace 數據進行埋點。

最終也是使用 metadata metadata.MD 來獲取上下文。

在 Pulsar 中是將 TraceId 存放在 properties 中，也相當于是元數據。

┌──────┐
│Client│
└┬─────┘
┌▽─────┐
│Pulsar│
└┬─────┘
┌▽───┐  
│gRPC│  
└────┘

func (s *server) SayHello(ctx context.Context, in *pb.HelloRequest) (*pb.HelloReply, error) {  
    defer apiCounter.Add(ctx, 1)  
    md, _ := metadata.FromIncomingContext(ctx)  
    log.Printf("Received: %v, md: %v", in.GetName(), md)  
    name, _ := os.Hostname()  
    span := trace.SpanFromContext(ctx)  
    span.SetAttributes(attribute.String("request.name", in.Name))  
    s.span(ctx)  
    return &pb.HelloReply{Message: fmt.Sprintf("hostname:%s, in:%s, md:%v", name, in.Name, md)}, nil  
}

圖片

圖片

在這樣一次調用中如果我們將 Pulsar 的 properties 和 gRPC meta 打印出來將會看到 TraceID 是如何進行傳遞的。

解決

回到這個問題本身，Trace 在 Gin Server 端沒有關聯起來，明顯就是 Gin 沒有接收到上游的 TraceId，導致它認為是新的一次調用，從而會創建一個 Trace。

解決起來也很容易，只需要在啟動 Gin 的時候傳入一個 OTEL 提供的攔截器，在這個攔截器中 OTEL 的 sdk 會自動從 HTTP header 里解析出 TraceId 然后塞入到當前的 context 中，這樣兩個進程的 Trace 就可以關聯起來了。

相關代碼如下：

r := gin.New()
    r.Use(otelgin.Middleware("my-server"))

由于 Go 沒有提供類似于 Java 的 javaagent 擴展，這類原本可以全自動打樁的代碼都需要硬編碼實現。

在這個 otelgin 實現的 Middleware 里會使用 HTTP header 來傳輸 context。

圖片

圖片

圖片

本質上是操作 HTTP header 查詢和寫入 Trace

圖片

會首先獲取上游的 TraceID，這里的 traceparentHeader 也就是我們剛才看到的 traceparent。

如果獲取到了就會解析里面的 TraceID，并生成當前的 Context，這樣這個 context 就會一直往后傳遞了。

流程與上文提到 gRPC 類似。

image.png

這是目前 otel-go-sdk 支持的自動打樁框架[1]，目前看來還不太多，但常用的也都支持了。

總結

如何跨進程調的 Trace 信息都是通過網絡傳遞的，只是對于不同的協議傳輸的細節也各不相同，但原理都是類似的。

圖片

關鍵就是上面這兩張圖，進程 1 在調用進程 2 的時候將信息寫入進去，進程 2 在收到請求的時候解析出 Trace，這兩個步驟缺一不可。#Blog

引用鏈接

[1] 自動打樁框架: https://github.com/open-telemetry/opentelemetry-go-contrib/tree/main/instrumentation