链路追踪解决什么问题

对接阿里云的时候，遇到问题提交工单，如果遇到复杂一点的问题，客服会让你发一下 trace id，这个 trace id 一般能在请求追踪里面看到。

淘宝由很多个微服务组成，微服务无可避免地存在子服务请求。开发的时候，请求子服务遇到错误，可以将错误日志打印出来。

假设有几个微服务：主服务、订单服务、钱包服务、数据库。

现在模拟这个微服务处理订单。这是正常的情况。

主服务请求订单服务，如果订单服务处理失败，则主服务终端打印错误信息。

但是现在 只知道订单服务炸了，而不知道订单服务哪个步骤出了问题。所以，订单服务请求数据库打印日志、请求钱包服务也打印日志。

如果订单服务出了问题，会在主服务反映出来。然后一步一步来跟踪日志:

• 检查主服务的日志输出

• 检查订单服务的日志输出

实际上，钱包服务也会访问个人信息服务、访问数据库。每个微服务有各自的进程，有各自的终端，其中一个服务出了问题，就要逐个微服务查看日志。遇到大量请求，日志刷屏的情况下是非常难追踪问题的。

来看看链路追踪如何解决这个问题。

在上方的流程中，主服务生成一个 trace_id 作为追踪的ID，带上 trace_id 请求订单服务，并写入链路日志；订单服务访问数据库、请求钱包服务也写入链路日志；钱包服务收到 trace_id ，处理业务也写入链路日志。所有的微服务业务日志都送至链路追踪系统统一管理，主服务处理完后，将 trace_id 返回客户，客户遇到 bug ，可以提供 trace_id 到运维，运维直接在后台查看时间线，做业务回放。

OpenTracing 概念

OpenTracing 是链路追踪的标准，它描述的追踪过程有几个基本概念。

Span 对象

Span 描述一段工作流程，它可以有子 Span，根 Span 就是一段完整的追踪记录。

Span Tag

存储 Span 的 key,value 信息

Span Log

存储 Span 的流程日志

Span Tag vs. Span Log

Tag 不存储时间戳。

在一些可视化追踪界面上，如果存在一个 Tag (key: error, value: true)，界面会标记这个 Span 为失败状态。(OpenTracing对Log、Tag、Baggage的解释)

SpanContext 对象

Span 包含一个 SpanContext，可以在不同应用（进程）之间共享数据，比如本次追踪记录 TraceID，共享数据等。

Baggage 则为 SpanContext 存储的共享数据。