Java 服务接入 OpenTracing（1）--从 Tracing 到 OpenTracing

• Tracing 的由来
• Tracing 数据模型
• Tracing 的架构设计
• 从 Tracing 到 OpenTracing
• OpenTracing 做了什么事情

Tracing 的由来

随着微服务技术的发展与实践，越来越多应用从单体应用架构转向了微服务架构。微服务技术使得应用能够很容易地突破单机资源局限，转变为分布式应用系统，让应用能够承载更大的流量。微服务应用系统的架构设计里团队的每个开发者只需要关注自己熟悉的几个微服务的业务代码。这也让软件行业实现了福特流水线的生产模式，长期以往，每个生产步骤（微服务）都会由最熟练的工人（开发者）进行生产。

但是在软件行业没有银弹，在我们享受着微服务架构设计的好处的同时，也需要成承担微服务架构设计的一些副作用。例如微服务架构设计会让应用复杂程度增加，应用的缺陷排查变得更加困难；如单次的服务请求调用链变长，服务使用者和服务提供者无法知道请求的全貌，对于有性能问题的调用，也没有很好的办法定位导致性能问题的代码位置。

为了解决上述问题，谷歌在 2010 年发表了论文 《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》 ，阐述了 google 内部实践的分布式链路追踪系统（distributed systems tracing infrastructure） Depper 的设计及其工作方式。这也成为了后来其他 Tracing 实现的范本。

Tracing 数据模型

由于 Tracing 数据模型基本都是基于谷歌 Dapper 论文而来，概念都大同小异。所以就以 OpenTracing 官方文档的数据模型作为引入。

OpenTra