草庐IT

一文详解｜Go 分布式链路追踪实现原理

尔达Erda 2023-03-28 原文
在分布式、微服务架构下，应用一个请求往往贯穿多个分布式服务，这给应用的故障排查、性能优化带来新的挑战。分布式链路追踪作为解决分布式应用可观测问题的重要技术，愈发成为分布式应用不可缺少的基础设施。本文将详细介绍分布式链路的核心概念、架构原理和相关开源标准协议，并分享我们在实现无侵入 Go 采集 Sdk 方面的一些实践。


为什么需要分布式链路追踪系统

微服务架构给运维、排障带来新挑战

在分布式架构下，当用户从浏览器客户端发起一个请求时，后端处理逻辑往往贯穿多个分布式服务，这时会浮现很多问题，比如：

  1. 请求整体耗时较长，具体慢在哪个服务？
  2. 请求过程中出错了，具体是哪个服务报错？
  3. 某个服务的请求量如何，接口成功率如何？

回答这些问题变得不是那么简单，我们不仅仅需要知道某一个服务的接口处理统计数据，还需要了解两个服务之间的接口调用依赖关系，只有建立起整个请求在多个服务间的时空顺序，才能更好的帮助我们理解和定位问题，而这，正是分布式链路追踪系统可以解决的。

分布式链路追踪系统如何帮助我们

分布式链路追踪技术的核心思想：在用户一次分布式请求服务的调⽤过程中，将请求在所有子系统间的调用过程和时空关系追踪记录下来，还原成调用链路集中展示，信息包括各个服务节点上的耗时、请求具体到达哪台机器上、每个服务节点的请求状态等等。

如上图所示，通过分布式链路追踪构建出完整的请求链路后，可以很直观地看到请求耗时主要耗费在哪个服务环节，帮助我们更快速聚焦问题。 同时，还可以对采集的链路数据做进一步的分析，从而可以建立整个系统各服务间的依赖关系、以及流量情况，帮助我们更好地排查系统的循环依赖、热点服务等问题。

分布式链路追踪系统架构概览

核心概念

在分布式链路追踪系统中，最核心的概念，便是链路追踪的数据模型定义，主要包括 Trace 和 Span。

其中，Trace 是一个逻辑概念，表示一次（分布式）请求经过的所有局部操作（Span）构成的一条完整的有向无环图，其中所有的 Span 的 TraceId 相同。 Span 则是真实的数据实体模型，表示一次(分布式)请求过程的一个步骤或操作，代表系统中一个逻辑运行单元，Span 之间通过嵌套或者顺序排列建立因果关系。Span 数据在采集端生成，之后上报到服务端，做进一步的处理。其包含如下关键属性：


  • Name：操作名称，如一个 RPC 方法的名称，一个函数名
  • StartTime/EndTime：起始时间和结束时间，操作的生命周期
  • ParentSpanId：父级 Span 的 ID
  • Attributes：属性，一组 <K,V> 键值对构成的集合
  • Event：操作期间发生的事件
  • SpanContext：Span 上下文内容，通常用于在 Span 间传播，其核心字段包括 TraceId、SpanId

一般架构

分布式链路追踪系统的核心任务是：围绕 Span 的生成、传播、采集、处理、存储、可视化、分析，构建分布式链路追踪系统。其一般的架构如下如所示：


  • 我们看到，在应用端需要通过侵入或者非侵入的方式，注入 Tracing Sdk，以跟踪、生成、传播和上报请求调用链路数据；
  • Collect agent 一般是在靠近应用侧的一个边缘计算层，主要用于提高 Tracing Sdk 的写性能，和减少 back-end 的计算压力；
  • 采集的链路跟踪数据上报到后端时，首先经过 Gateway 做一个鉴权，之后进入 kafka 这样的 MQ 进行消息的缓冲存储；
  • 在数据写入存储层之前，我们可能需要对消息队列中的数据做一些清洗和分析的操作，清洗是为了规范和适配不同的数据源上报的数据，分析通常是为了支持更高级的业务功能，比如流量统计、错误分析等，这部分通常采用flink这类的流处理框架来完成；
  • 存储层会是服务端设计选型的一个重点，要考虑数据量级和查询场景的特点来设计选型，通常的选择包括使用 Elasticsearch、Cassandra、或 Clickhouse 这类开源产品；
  • 流处理分析后的结果，一方面作为存储持久化下来，另一方面也会进入告警系统，以主动发现问题来通知用户，如错误率超过指定阈值发出告警通知这样的需求等。
刚才讲的，是一个通用的架构，我们并没有涉及每个模块的细节，尤其是服务端，每个模块细讲起来都要很花些功夫，受篇幅所限，我们把注意力集中到靠近应用侧的 Tracing Sdk，重点看看在应用侧具体是如何实现链路数据的跟踪和采集的。


协议标准和开源实现

刚才我们提到 Tracing Sdk，其实这只是一个概念，具体到实现，选择可能会非常多，这其中的原因，主要是因为：


  1. 不同的编程语言的应用，可能采用不同技术原理来实现对调用链的跟踪
  2. 不同的链路追踪后端，可能采用不同的数据传输协议
当前，流行的链路追踪后端，比如 Zipin、Jaeger、PinPoint、Skywalking、Erda，都有供应用集成的 sdk，导致我们在切换后端时应用侧可能也需要做较大的调整。 社区也出现过不同的协议，试图解决采集侧的这种乱象，比如 OpenTracing、OpenCensus 协议，这两个协议也分别有一些大厂跟进支持，但最近几年，这两者已经走向了融合统一，产生了一个新的标准 OpenTelemetry，这两年发展迅猛，已经逐渐成为行业标准。


OpenTelemetry 定义了数据采集的标准 api，并提供了一组针对多语言的开箱即用的 sdk 实现工具，这样，应用只需要与 OpenTelemetry 核心 api 包强耦合，不需要与特定的实现强耦合。


应用侧调用链跟踪实现方案概览

应用侧核心任务

应用侧围绕 Span，有三个核心任务要完成：


  1. 生成 Span：操作开始构建 Span 并填充 StartTime，操作完成时填充 EndTime 信息，期间可追加 Attributes、Event 等
  2. 传播 Span：进程内通过 context.Context、进程间通过请求的 header 作为 SpanContext 的载体，传播的核心信息是 TraceId 和 ParentSpanId
  3. 上报 Span：生成的 Span 通过 tracing exporter 发送给 collect agent / back-end server
要实现 Span 的生成和传播，要求我们能够拦截应用的关键操作（函数）过程，并添加 Span 相关的逻辑。实现这个目的会有很多方法，不过，在罗列这些方法之前，我们先看看在 OpenTelemetry 提供的 go sdk 中是如何做的。


基于 OTEL 库实现调用拦截

OpenTelemetry 的 go sdk 实现调用链拦截的基本思路是：基于 AOP 的思想，采用装饰器模式，通过包装替换目标包（如 net/http）的核心接口或组件，实现在核心调用过程前后添加 Span 相关逻辑。当然，这样的做法是有一定的侵入性的，需要手动替换使用原接口实现的代码调用改为包装接口实现。 我们以一个 http server 的例子来说明，在 go 语言中，具体是如何做的：

假设有两个服务 serverA 和 serverB，其中 serverA 的接口收到请求后，内部会通过 httpclient 进一步发起到 serverB 的请求，那么 serverA 的核心代码可能如下图所示：


以 serverA 节点为例，在 serverA 节点应该产生至少两个 Span：

  1. Span1，记录 httpServer 收到一个请求后内部整体处理过程的一个耗时情况
  2. Span2，记录 httpServer 处理请求过程中，发起的另一个到 serverB 的 http 请求的耗时情况
  3. 并且 Span1 应该是 Span2 的 ParentSpan
我们可以借助 OpenTelemetry 提供的 sdk 来实现 Span 的生成、传播和上报，上报的逻辑受篇幅所限我们不再详述，重点来看看如何生成这两个 Span，并使这两个 Span 之间建立关联，即 Span 的生成和传播 。


HttpServer Handler 生成 Span 过程

对于 httpserver 来讲，我们知道其核心就是 http.Handler 这个接口。因此，可以通过实现一个针对 http.Handler 接口的拦截器，来负责 Span 的生成和传播。

package http

type Handler interface {
ServeHTTP(ResponseWriter, *Request)
}

http.ListenAndServe(":8090", http.DefaultServeMux)
要使用 OpenTelemetry Sdk 提供的 http.Handler 装饰器，需要如下调整 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 中将主要实现如下逻辑（精简考虑，此处部分为伪代码）： ① ​​ctx := tracer.Extract(r.ctx, r.Header)​​：从请求的 header 中提取 traceparent header 并解析，提取 TraceId和 SpanId，进而构建 SpanContext 对象，并最终存储在 ctx 中；

② ​​ctx, span := tracer.Start(ctx, genOperation(r))​​：生成跟踪当前请求处理过程的 Span（即前文所述的Span1），并记录开始时间，这时会从 ctx 中读取 SpanContext，将 SpanContext.TraceId 作为当前 Span 的TraceId，将 SpanContext.SpanId 作为当前 Span的ParentSpanId，然后将自己作为新的 SpanContext 写入返回的 ctx 中；

③ ​​r.WithContext(ctx)​​：将新生成的 SpanContext 添加到请求 r 的 context 中，以便被拦截的 handler 内部在处理过程中，可以从 r.ctx 中拿到 Span1 的 SpanId 作为其 ParentSpanId 属性，从而建立 Span 之间的父子关系；

④ ​​span.End()​​：当 innerHttpHandler.ServeHTTP(w,r) 执行完成后，就需要对 Span1 记录一下处理完成的时间，然后将它发送给 exporter 上报到服务端。


HttpClient 请求生成 Span 过程

我们再接着看 serverA 内部去请求 serverB 时的 httpclient 请求是如何生成 Span 的（即前文说的 Span2）。我们知道，httpclient 发送请求的关键操作是 http.RoundTriper 接口：

package http

type RoundTripper interface {
RoundTrip(*Request) (*Response, error)
}
OpenTelemetry 提供了基于这个接口的一个拦截器实现，我们需要使用这个实现包装一下 httpclient 原来使用的 RoundTripper 实现，代码调整如下：

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 将主要完成以下任务（精简考虑，此处部分为伪代码）： ① ​​req, _ := http.NewRequestWithContext(r.ctx, “GET”,url, nil)​​ ：这里我们将上一步 http.Handler 的请求的 ctx，传递到 httpclient 要发出的 request 中，这样在之后我们就可以从 request.Context() 中提取出 Span1 的信息，来建立 Span 之间的关联；

② ​​ctx, span := tracer.Start(r.Context(), url)​​：执行 client.Do() 之后，将首先进入 WrappedTransport.RoundTrip() 方法，这里生成新的 Span（Span2），开始记录 httpclient 请求的耗时情况，与前文一样，Start 方法内部会从 r.Context() 中提取出 Span1 的 SpanContext，并将其 SpanId 作为当前 Span（Span2）的 ParentSpanId，从而建立了 Span 之间的嵌套关系，同时返回的 ctx 中保存的 SpanContext 将是新生成的 Span（Span2）的信息；

③ ​​tracer.Inject(ctx, r.Header)​​：这一步的目的是将当前 SpanContext 中的 TraceId 和 SpanId 等信息写入到 r.Header 中，以便能够随着 http 请求发送到 serverB，之后在 serverB 中与当前 Span 建立关联；

④ ​​span.End()​​：等待 httpclient 请求发送到 serverB 并收到响应以后，标记当前 Span 跟踪结束，设置 EndTime 并提交给 exporter 以上报到服务端。


基于 OTEL 库实现调用链跟踪总结

我们比较详细的介绍了使用 OpenTelemetry 库，是如何实现链路的关键信息（TraceId、SpanId）是如何在进程间和进程内传播的，我们对这种跟踪实现方式做个小的总结：

如上分析所展示的，使用这种方式的话，对代码还是有一定的侵入性，并且对代码有另一个要求，就是保持 context.Context 对象在各操作间的传递，比如，刚才我们在 serverA 中创建 httpclient 请求时，使用的是 ​​http.NewRequestWithContext(r.ctx, ...)​​​ 而非​​http.NewRequest(...)​​方法，另外开启 goroutine 的异步场景也需要注意 ctx 的传递。

非侵入调用链跟踪实现思路

我们刚才详细展示了基于常规的一种具有一定侵入性的实现，其侵入性主要表现在：我们需要显式的手动添加代码使用具有跟踪功能的组件包装原代码，这进一步会导致应用代码需要显式的引用具体版本的 OpenTelemetry instrumentation 包，这不利于可观测代码的独立维护和升级。 那我们有没有可以实现非侵入跟踪调用链的方案可选？ 所谓无侵入，其实也只是集成的方式不同，集成的目标其实是差不多的，最终都是要通过某种方式，实现对关键调用函数的拦截，并加入特殊逻辑，无侵入重点在于代码无需修改或极少修改。

上图列出了现在可能的一些无侵入集成的实现思路，与 .net、java 这类有 IL 语言的编程语言不同，go 直接编译为机器码，导致无侵入的方案实现起来相对比较麻烦，具体有如下几种思路：


  1. 编译阶段注入：可以扩展编译器，修改编译过程中的ast，插入跟踪代码，需要适配不同编译器版本。
  2. 启动阶段注入：修改编译后的机器码，插入跟踪代码，需要适配不同 CPU 架构。如 monkey, gohook。
  3. 运行阶段注入：通过内核提供的 eBPF 能力，监听程序关键函数执行，插入跟踪代码，前景光明！如，tcpdump，bpftrace。

Go 非侵入链路追踪实现原理

Erda 项目的核心代码主要是基于 golang 编写的，我们基于前文所述的 OpenTelemetry sdk，采用基于修改机器码的的方式，实现了一种无侵入的链路追踪方式。 前文提到，使用 OpenTelemetry sdk 需要代码做一些调整，我们看看这些调整如何以非侵入的方式自动的完成：


我们以 httpclient 为例，做简要的解释。 gohook 框架提供的 hook 接口的签名如下：

// target 要hook的目标函数
// replacement 要替换为的函数
// trampoline 将源函数入口拷贝到的位置，可用于从replcement跳转回原target

func Hook(target, replacement, trampoline interface{}) error
对于 ​​http.Client​​，我们可以选择 ​​hook DefaultTransport.RoundTrip()​​ 方法，当该方法执行时，我们通过 ​​otelhttp.NewTransport()​​ 包装起原 ​​DefaultTransport​​ 对象，但需要注意的是，我们不能将 ​​DefaultTransport​​ 直接作为 ​​otelhttp.NewTransport()​​ 的参数，因为其 ​​RoundTrip()​​ 方法已经被我们替换了，而其原来真正的方法被写到了 ​​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()​​ 函数实现了自动添加 hook，因此用户程序里只需要在 main 文件中 import 该包，即可实现无侵入的集成。

值得一提的是 ​​req = contextWithSpan(req)​​ 函数，内部会依次尝试从 ​​req.Context()​​ 和 我们保存的 ​​goroutineContext map​​ 中检查是否包含 ​​SpanContext​​，并将其赋值给 ​​req​​，这样便可以解除了必须使用 ​​http.NewRequestWithContext(...)​​ 写法的要求。

详细的代码可以查看 Erda 仓库： https://github.com/erda-project/erda-infra/tree/master/pkg/trace

参考链接

一文详解paddingspanbackground链路数据服务端微服务云原生云平台云计算

有关一文详解｜Go 分布式链路追踪实现原理的更多相关文章

  1. ruby - 如何根据特征实现 FactoryGirl 的条件行为 - 2

    我有一个用户工厂。我希望默认情况下确认用户。但是鉴于unconfirmed特征，我不希望它们被确认。虽然我有一个基于实现细节而不是抽象的工作实现，但我想知道如何正确地做到这一点。factory:userdoafter(:create)do|user,evaluator|#unwantedimplementationdetailshereunlessFactoryGirl.factories[:user].defined_traits.map(&:name).include?(:unconfirmed)user.confirm!endendtrait:unconfirmeddoenden

  2. ruby - 分布式事务和队列，ruby，erlang，scala - 2

    我有一个涉及多台机器、消息队列和事务的问题。因此，例如用户点击网页，点击将消息发送到另一台机器，该机器将付款添加到用户的帐户。每秒可能有数千次点击。事务的所有方面都应该是容错的。我以前从未遇到过这样的事情，但一些阅读表明这是一个众所周知的问题。所以我的问题。我假设安全的方法是使用两阶段提交，但协议(protocol)是阻塞的，所以我不会获得所需的性能，我是否正确？我通常写Ruby，但似乎Redis之类的数据库和Rescue、RabbitMQ等消息队列系统对我的帮助不大——即使我实现某种两阶段提交，如果Redis崩溃，数据也会丢失，因为它本质上只是内存。所有这些让我开始关注erlang和

  3. 华为OD机试用Python实现 -【明明的随机数】 2023Q1A - 2

    华为OD机试题本篇题目：明明的随机数题目输入描述输出描述：示例1输入输出说明代码编写思路最近更新的博客华为od2023|什么是华为od，od薪资待遇，od机试题清单华为OD机试真题大全，用Python解华为机试题|机试宝典【华为OD机试】全流程解析+经验分享,题型分享,防作弊指南华为o

  4. 基于C#实现简易绘图工具【100010177】 - 2

    C#实现简易绘图工具一.引言实验目的:通过制作窗体应用程序(C#画图软件),熟悉基本的窗体设计过程以及控件设计,事件处理等,熟悉使用C#的winform窗体进行绘图的基本步骤,对于面向对象编程有更加深刻的体会.Tutorial任务设计一个具有基本功能的画图软件**·包括简单的新建文件,保存,重新绘图等功能**·实现一些基本图形的绘制,包括铅笔和基本形状等,学习橡皮工具的创建**·设计一个合理舒适的UI界面**注明:你可能需要先了解一些关于winform窗体应用程序绘图的基本知识,以及关于GDI+类和结构的知识二.实验环境Windows系统下的visualstudio2017C#窗体应用程序三.

  5. MIMO-OFDM无线通信技术及MATLAB实现（1）无线信道：传播和衰落 - 2

     MIMO技术的优缺点优点通过下面三个增益来总体概括：阵列增益。阵列增益是指由于接收机通过对接收信号的相干合并而活得的平均SNR的提高。在发射机不知道信道信息的情况下，MIMO系统可以获得的阵列增益与接收天线数成正比复用增益。在采用空间复用方案的MIMO系统中，可以获得复用增益，即信道容量成倍增加。信道容量的增加与min(Nt,Nr)成正比分集增益。在采用空间分集方案的MIMO系统中，可以获得分集增益，即可靠性性能的改善。分集增益用独立衰落支路数来描述，即分集指数。在使用了空时编码的MIMO系统中，由于接收天线或发射天线之间的间距较远，可认为它们各自的大尺度衰落是相互独立的，因此分布式MIMO

  6. 【Java入门】使用Java实现文件夹的遍历 - 2

    遍历文件夹我们通常是使用递归进行操作，这种方式比较简单，也比较容易理解。本文为大家介绍另一种不使用递归的方式，由于没有使用递归，只用到了循环和集合，所以效率更高一些！一、使用递归遍历文件夹整体思路1、使用File封装初始目录，2、打印这个目录3、获取这个目录下所有的子文件和子目录的数组。4、遍历这个数组，取出每个File对象4-1、如果File是否是一个文件，打印4-2、否则就是一个目录，递归调用代码实现publicclassSearchFile{publicstaticvoidmain(String[]args){//初始目录Filedir=newFile("d:/Dev");Datebeg

  7. ruby - Arrays Sets 和 SortedSets 在 Ruby 中是如何实现的 - 2

    通常，数组被实现为内存块，集合被实现为HashMap，有序集合被实现为跳跃列表。在Ruby中也是如此吗？我正在尝试从性能和内存占用方面评估Ruby中不同容器的使用情况 最佳答案 数组是Ruby核心库的一部分。每个Ruby实现都有自己的数组实现。Ruby语言规范只规定了Ruby数组的行为，并没有规定任何特定的实现策略。它甚至没有指定任何会强制或至少建议特定实现策略的性能约束。然而，大多数Rubyist对数组的性能特征有一些期望，这会迫使不符合它们的实现变得默默无闻，因为实际上没有人会使用它:插入、前置或追加以及删除元素的最坏情况步骤复

  8. ruby - "public/protected/private"方法是如何实现的，我该如何模拟它？ - 2

    在ruby中，你可以这样做:classThingpublicdeff1puts"f1"endprivatedeff2puts"f2"endpublicdeff3puts"f3"endprivatedeff4puts"f4"endend现在f1和f3是公共(public)的，f2和f4是私有(private)的。内部发生了什么，允许您调用一个类方法，然后更改方法定义？我怎样才能实现相同的功能(表面上是创建我自己的java之类的注释)例如...classThingfundeff1puts"hey"endnotfundeff2puts"hey"endendfun和notfun将更改以下函数定

  9. ruby - 实现k最近邻需要哪些数据？ - 2

    我目前有一个reddit克隆类型的网站。我正在尝试根据我的用户之前喜欢的帖子推荐帖子。看起来K最近邻或k均值是执行此操作的最佳方法。我似乎无法理解如何实际实现它。我看过一些数学公式(例如k表示维基百科页面)，但它们对我来说并没有真正意义。有人可以推荐一些伪代码，或者可以查看的地方，以便我更好地了解如何执行此操作吗？ 最佳答案 K最近邻(又名KNN)是一种分类算法。基本上，您采用包含N个项目的训练组并对它们进行分类。如何对它们进行分类完全取决于您的数据，以及您认为该数据的重要分类特征是什么。在您的示例中，这可能是帖子类别、谁发布了该项

  10. ruby-on-rails - 使用 Ruby 正确处理 Stripe 错误和异常以实现一次性收费 - 2

    我查看了Stripedocumentationonerrors，但我仍然无法正确处理/重定向这些错误。基本上无论发生什么，我都希望他们返回到edit操作(通过edit_profile_path)并向他们显示一条消息(无论成功与否)。我在edit操作上有一个表单，它可以POST到update操作。使用有效的信用卡可以正常工作(费用在Stripe仪表板中)。我正在使用Stripe.js。classExtrasController5000,#amountincents:currency=>"usd",:card=>token,:description=>current_user.email)

随机推荐