随着业务系统的不断发展、微服务架构的演进，从原来的单体应用架构、垂直应用架构、分布式 SOA 架构到现在的微服务架构，系统逐步走向微服务化以适应用户高并发请求等需求。在微服务架构中，一个业务操作往往需要多个服务间协同操作，而在一个复杂的系统中出现问题的时候，需要我们能够快速的分析并定位到问题的原因，这就需要我们对业务进行一次还原，正是分布式链路追踪需要解决的问题。
分布式链路追踪就是将一次请求还原成完整的链路，将一次分布式请求的调用情况集中展示，例如请求耗时、请求节点的名称、响应状态等。 分布式链路跟踪主要功能： 故障快速定位：可以通过调用链结合业务日志快速定位错误信息，包括请求时间、响应的状态、节点名称等信息，用于到达故障定位的能力； 链路性能可视化：各个阶段链路耗时、服务依赖关系通过可视化界面展现出来； 链路分析：通过分析链路耗时、服务依赖关系可以得到用户的行为路径，汇总分析应用在很多业务场景。
链路追踪系统最早是由Goggle公开发布的一篇论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》，这篇论文讲述了 Dapper 链路追踪系统的基本原理和关键技术点，通过一个分布式全局唯一的 id（即traceId），将分布在各个服务节点上的同一次请求串联起来，还原调用关系、追踪系统问题、分析调用数据、统计系统指标。
图中一条完整的链路是：user -> 服务A -> 服务B -> 服务C -> 服务D -> 服务E -> 服务C -> 服务A -> user，服务之间经过的每一条链路构成了一条完整的链路，并且每一条局部的链路都可以用唯一的 trace id标识。
通过唯一的 trace id无法知道先是调用了服务A还是先调用了服务B，因此为了去表达这种父子关系引入了 span 的概念，相同层的 parent id 相同，span id不同，并且 span id 由小到大来表示请求的顺序。除此之外，还可以记录其他的一些信息，比如发起服务的名称、IP、被调用服务的名称、返回结果、网络耗时等。
OpenTracing 是一个中立的分布式追踪的 API 规范，提供了统一接口方便开发者在自己的服务中集成一种或者多种分布式追踪的实现，使得开发人员能够方便的添加或更换追踪系统的实现。OpenTracing 可以解决不同的分布式追踪系统 API 不兼容的问题，各个分布式追踪系统都来实现这套接口。 OpenTracing 的数据模型，主要有以下三个： Trace：可以理解为一个完整请求链路，也可以认为是由多个 span 组成的有向无环图（DAG）； Span：span 代表系统中具有开始时间和执行时长的逻辑运行单元，只要是一个完整生命周期的程序访问都可以认为是一个 span，比如一次数据库访问，一次方法的调用，一次 MQ 消息的发送等；每个 span 包含了操作名称、起始时间、结束时间、阶段标签集合（Span Tag）、阶段日志（Span Logs）、阶段上下文（SpanContext）、引用关系（Reference）； SpanContext：Trace 的全局上下文信息，span 的状态通过 SpanContext 跨越进程边界进行传递，比如包含 trace id，span id，Baggage Items（一个键值对集合）。
对于一次完整的登录请求就是一个 Trace，显然需要一个全局的 trace id 来标识，每次服务间的调用就称为一个 span，通过对应协议将 span context 进行传输。 据此调用链路信息画出调用链的可视化视图如下：