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 官方文档的数据模型作为引入。

OpenTracing 中的 Trace （调用链）通过归属于此调用链的 Span 来隐性的定义。
特别说明，一条 Trace （调用链）可以被认为是一个由多个 Span 组成的有向无环图（DAG图），
Span 与 Span 的关系被命名为 References 。

例如：下面的示例 Trace 就是由8个 Span 组成：

单个Trace中，span间的因果关系[Span A]  ←←←(the root span)|+------+------+|             |[Span B]      [Span C] ←←←(Span C 是 Span A 的孩子节点, ChildOf)|             |[Span D]      +---+-------+|           |[Span E]    [Span F] >>> [Span G] >>> [Span H]↑↑↑(Span G 在 Span F 后被调用, FollowsFrom)

有些时候，使用下面这种，基于时间轴的时序图可以更好的展现 Trace （调用链）：

单个Trace中，span间的时间关系––|–––––––|–––––––|–––––––|–––––––|–––––––|–––––––|–––––––|–> time[Span A···················································][Span B··············································][Span D··········································][Span C········································][Span E·······]        [Span F··] [Span G··] [Span H··]

每个 Span 包含以下的状态:（译者注：由于这些状态会反映在OpenTracing API中，所以会保留部分英文说明）

An operation name，操作名称
A start timestamp，起始时间
A finish timestamp，结束时间
Span Tag ，一组键值对构成的Span标签集合。键值对中，键必须为string，值可以是字符串，布尔，或者数字类型。
Span Log ，一组span的日志集合。
每次log操作包含一个键值对，以及一个时间戳。
键值对中，键必须为string，值可以是任意类型。
但是需要注意，不是所有的支持OpenTracing的Tracer,都需要支持所有的值类型。
SpanContext ，Span上下文对象 (下面会详细说明)
References (Span间关系)，相关的零个或者多个Span（ Span 间通过 SpanContext 建立这种关系）

每一个 SpanContext 包含以下状态：

任何一个OpenTracing的实现，都需要将当前调用链的状态（例如：trace和span的id），依赖一个独特的Span去跨进程边界传输
Baggage Items ，Trace的随行数据，是一个键值对集合，它存在于trace中，也需要跨进程边界传输

更多 OpenTracing 相关定义请参考 OpenTracing语义标准

Tracing 的架构设计

先来看看目前市面上比较流行的几个 Tracing 组件架构设计
Zipkin Tracing 实现架构图

Jaeger Tracing 实现架构图

Skywalking Tracing 实现架构图

可以看出来 Tracing 的实现架构一般都是大同小异，一般都实现了四个基本功能组件: Instrument, Reporter, Collector, Querier。
- Instrument
  
  一个 Instrument 是对特定开源组件做 Span 打点后并转给 Reporter 的实现，但是一般 Tracing 不自己实现 Instrument，而是提供产生 Span 的工具，由对应开源组件的维护者编写对应的 Instrument。所以这部分一般不会在 Tracing 架构图出现。
  
  在各个 Tracing 的官方文档里面，搜索 instrument 关键字，都可以找到其对应的已经实现过的 instruments。
- Reporter
  - 作为一个组件在微服务里面运行，主要功能包括在微服务里面采集 Span 信息，在不影响或尽量少影响微服务性能的情况下发送 Span 信息给 Collector。
  - 在 Zipkin 中对应 reporter，在 Jaeger 中对应 jeager-client 和 jaeger-agent，在 Skywalking 中对应各种 agents。
- Collector
  - 一般是独立的服务，用于收集 Reporter 发过来的 Span 信息并持久化（落库）。一般来说，Collector 收集到的 Span 信息是离散的，很可能还没办法组合成一个完整的 Trace 就落库了。
  - 在 Zipkin 中对应 Collector，在 Jaeger 中对应 jaeger-collector，在 Skywalking 中对应 Reveiver/Aggregator Cluster。
- Querier
  - 一般与 Collector 在同一个服务里面，主要实现在持久化存储中把分散的 Span 聚合为完整的 Trace 展示给使用者。
  - 在 Zipkin 中对应 API + UI，在 Jaeger 中对应 jaeger-query + UI，在 Skywalking 中对应 Aggregator + UI。

从 Tracing 到 OpenTracing

从 2010 年谷歌发布 Dapper papper 以来，出现许多的 Tracing 开源项目实现，如 Zipkin/Skywalking/Jaeger/Pinpoint 等。一般来说 Tracing 开源项目他们只提供 Instrument 的接入方式，但是却不提供 Instrument 的具体实现，如果其他开源项目想接入 Tracing ，则是需要这些开源项目的开发者们自己去实现对应的 Instrument。即使一些 Tracing 开源项目的开发者们直接支持了一些开源组件的 Instrument（如 Pinpoint），也可能很快由于其他开源项目的架构升级，导致原来的 Instrument 实现不可用。

如果市场只有一个 Tracing 还好，但是百花齐放的 Tracing 开源实现会让开源组件的开发者们并不是很乐于去实现某个 Tracing 的 Instrument。而且开源组件的每次大版本升级，都有可能导致原先的 Instrument 无法工作。基于这个思考， 2016 年 Ben Sigelman 发表博客《Towards Turnkey Distributed Tracing》，提出了 OpenTracing 这个概念。

OpenTracing 做了什么事情

Ben Sigelman 博文中列举 Tracing 中需要做统一的五个关键点，分别为：

Standardized span management: 统一的 Span 的开始/信息记录/结束接口
Standardized inter-process propagation: 统一的 Trace 在不同线程/协程间的上下文（SpanContext）的传递接口
Standardized active span management: 统一的线程/协程内对 Span 的生成与获取接口
Standardized in-band context encoding: 统一的服务内上下文（SpanContext）的传递接口
Standardized out-of-band trace data encoding: 统一的服务外上下文（SpanContext）的传递接口

现有的 Tracing 开源项目都是基于谷歌的 Dapper 论文做的实现。里面更多的关注了第4点和第5点。然而实际的情况是第4点与第5点的标准化对于 Instrument 持续可用性是没有什么很大帮助的。而 1-3 点的标准化对于推动其他开源项目加入 Tracing 产生帮助更大，所以 OpenTracing 主要做的事情就是定义一组标准的 OpenTracing API 来实现 1-3 的标准化。

所以 OpenTracing 其实并没有实现 Tracing，而是定义了开源项目接入 Tracing 的标准，让开源软件更加容易地接入 Tracing

Java 服务接入 OpenTracing（1）--从 Tracing 到 OpenTracing相关推荐

Java 服务接入 OpenTracing（2） -- Java 项目快速接入 OpenTracing
接入前准备搭建 Collector 和 Querier 准备被织入 java 项目(如果已经有自己的项目jar包,可以直接跳过此步) 准备 java-specialagent 包 Java 项目织入 ...
Java 服务接入「东方通（tongweb）」
目标调研东方通(tongweb)中间件,将 Authing 核心 Java 服务接入东方通(tongweb)替换 springboot tomcat 东方通(tongweb) 东方通,中国中间件的开 ...
酷家乐如何使用 Istio 解决新服务治理系统（Serverless）接入已有成熟自研 Java 服务治理体系...
本文来自酷家乐先进技术工程团队,作者罗宁,酷家乐资深开发工程师. 公司背景酷家乐 [1] 公司以分布式并行计算和多媒体数据挖掘为技术核心,推出的家居云设计平台,致力于云渲染.云设计.BIM.VR.A ...
java 故障排查_目前最全的 Java 服务问题排查套路
问题分类: CPU问题内存问题(GC问题.内存泄漏. OOM,Coredump 等) I/O问题问题排查工具箱: 系统级别的工具: top:查看系统/进程cpu.内存.swap等资源占用情况的必备 ...
SpringCloud（第 017 篇）电影微服务接入Feign，添加 fallbackFactory 属性来触发请求进行容灾降级...
2019独角兽企业重金招聘Python工程师标准>>> SpringCloud(第 017 篇)电影微服务接入Feign,添加 fallbackFactory 属性来触发请求进行容灾 ...
谷歌支付（Java服务端）
Google Pay主要支付流程 1.手机端向Java服务端发起支付,生成预订单,给手机端返回生成的订单号 2.手机端向Google发起支付(传入本地服务器生成的订单号) 3.Google服务器将支付 ...
SkyWalking服务端的搭建、微服务接入SkyWalking
文章目录 SkyWalking SkyWalking介绍 SkyWalking服务端部署 Skywalking接入微服务 linux windows SkyWalking接入多个微服务基于Mysql ...
用“逐步排除”的方法定位Java服务线上“系统性”故障
说明:原文地址已经不可访问,其他地方有转载,不过很多丢失图片,所以,找到一处有图的重新配好图. 用"逐步排除"的方法定位Java服务线上"系统性"故障 Post ...
Flex通信-Java服务端通信实例
Flex与Java通信的方式有很多种,比较常用的有以下方式: WebService:一种跨语言的在线服务,只要用特定语言写好并部署到服务器,其它语言就可以调用 HttpService:通过http请求 ...

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