目录
Span&Trace
关系描述
DAG有向无环图
Span间关系
参考
Span&Trace
span 跨度
trace 轨迹
关系：每一个轨迹，都是由很多跨度(弧)组成。
trace：标识一次调用的路径；span 是服务之间调用的关系，当然也可以标识为服务的节点，关系通过span之间的相互引用来体现。
关系描述
摘自：/u011537073/article/details/78299454
类似：
单个 Trace 中 Span 之间的因果关系[Span A] ←←←(the root span)|+------+------+| |[Span B][Span C] ←←←(Span C is a `ChildOf` Span A)| |[Span D]+---+-------+| |[Span E] [Span F] >>> [Span G] >>> [Span H]↑↑↑(Span G `FollowsFrom` Span F)
在一个分布式系统中，追踪一个事务或者调用流一般如上图所示。虽然这种图对于看清各组件的组合关系是很有用的，但是，它不能很好显示组件的调用时间，是串行调用还是并行调用，如果展现更复杂的调用关系，会更加复杂，甚至无法画出这样的图。另外，这种图也无法显示调用间的时间间隔以及是否通过定时调用来启动调用。一种更有效的展现一个典型的trace过程，如下图所示：
类似：
单个 Trace 中 Spans 之间的时间关系––|–––––––|–––––––|–––––––|–––––––|–––––––|–––––––|–––––––|–> time[Span A···················································][Span B··············································][Span D··········································][Span C········································][Span E·······] [Span F··] [Span G··] [Span H··]
这种展现方式增加显示了执行时间的上下文，相关服务间的层次关系，进程或者任务的串行或并行调用关系。这样的视图有助于发现系统调用的关键路径。通过关注关键路径的执行过程，项目团队可能专注于优化路径中的关键位置，最大幅度的提升系统性能。
例如：可以通过追踪一个资源定位的调用情况，明确底层的调用情况，发现哪些操作有阻塞情况。
DAG有向无环图
DAG(Directed Acyclic Graph)，中文名"有向无环图"。"有向"指的是有方向，准确的说应该是同一个方向，"无环"则指够不成闭环。
这个是区块链中应用的技术，但分布式应用调用不就是这种关系么。如下图：
一次调用Trace链路路径，就是span组成的DAG图。
span 就是里边的节点，节点有上下关系，也有先后关系。
Span间关系
OpenTracing 仅仅定义了两种关系: ChildOf 和 FollowsForm。
ChildOf：我是谁(父节点)的儿子
FollowsForm：我在谁(兄长节点)之后
示例：
1. 注册场景：通过getway路由，ucs完成注册，调用oauth完成账户创建，并通过msg发送短信
2. 审核通过：getway路由，ucs完成审核，抛出审核通过消息到MQ，并发送短信，Oauth消费消息解锁改账户
3. 调用方是JOB场景：通过xxl-调用指标采集器，通过采集协调器，动态加载采集适配器Jar包，然后调用。采集完成后通过消息通知解析器解析。
关系描述：
场景1：getway 是 ucs 的parent span。反过来 ucs就是childof getway了。
场景1：ucs先调用oauth ，再调用msg通知。msg 就是 flowfrom oauth。
参考
Span模型：/opentracing-contrib/opentracing-specification-zh/blob/master/specification.md
/aliyunyunqi/article/details/79473401
中文文档：https://wu-sheng.gitbooks.io/opentracing-io/content/pages/spec.html
Towards Turnkey Distributed Tracing：/opentracing/towards-turnkey-distributed-tracing-5f4297d1736
end
如果觉得《微服务.链路追踪.OpenTracing》对你有帮助，请点赞、收藏，并留下你的观点哦！
