分布式链路追踪
背景：
在单体服务下，借助于拦截器/AOP+MDC可以实现请求的日志追踪。https://www.cnblogs.com/yangyongjie/p/10940843.html
但是，在分布式系统下，一次请求往往需要经过内部多个微服务一系列调用才能完成。
在这一系列的调用中，可能有些是串行的，而有些是并行的。在这种情况下，想要确定整个请求调用了哪些服务模块，服务模块所在具体机器，以及调用的先后顺序，还有调用服务模块的性能如何，就需要对整个请求链路进行追踪。
链路追踪
链路追踪是分布式系统下用来追踪一个请求的整个执行链路，也就是将一次分布式请求还原成调用链路，将一次请求的调用情况集中展示。比如，各个服务节点上的耗时、请求具体到达哪台机器上，每个服务节点的请求状态等。
有了链路追踪，我们更清晰一个请求的执行路径和流程，当出现问题时，便于排查和复现。其主要作用如下：
1）自动采集请求链路数据
2）分析数据，产生完整调用链；有了请求的完整调用链，问题有很大概率可复现
3）数据可视化，每个组件的性能可视化，能帮助我们很好定位系统的性能瓶颈，及时找出问题所在。
分布式调用链标准（OpenTracing）
OpenTracing是一个轻量级的标准化层，它位于应用程序/类库和追踪或日志分析程序之间。它的出现是为了解决不同的分布式追踪系统 API 不兼容的问题
OpenTracing 通过提供与平台和厂商无关的 API，使得开发人员能够方便地添加（或更换）追踪系统，就像单体架构下的AOP（切面编程）一样。
OpenTracing 的数据模型，主要有以下三个：Trace、Span、SpanContext
1、Trace
一个完整的请求链路。TraceId是这个请求的全局标识。
2、Span
一次调用过程
Trace中的每一次调用，无论是HTTP、RPC、存储访问甚至是本地方法调用等，都可以称为一个Span
Span 代表系统中具有开始时间和执行时长的逻辑单元，Span 之间通过嵌套或者顺序排列建立逻辑因果关系。
每个 Span 中可以包含以下的信息：
1）操作名称：例如访问的具体 RPC 服务，访问的 URL 地址等；
2）起始时间；
3）结束时间；
4）Span Tag：一组键值对构成的 Span 标签集合，其中键必须为字符串类型，值可以是字符串、bool 值或者数字；
5）Span Log：一组 Span 的日志集合；
6）SpanContext：Trace 的全局上下文信息；
7）References：Span 之间的引用关系
①：ChildOf关系
一个 Span 可能是一个父级 Span 的孩子，即为 ChildOf 关系。ChildOf关系中的父级SPan都要等待子Span的返回，子Span的执行影响了其所在父级Span的执行时间，父级Span依赖子Span的执行结果。
一个父Span可能会有多个并行的子Span，这种情况下父Span可以合并所有子Span的执行结果并等待所有并行子Span结束。
如：一个 HTTP 请求之中，被调用的服务端产生的 Span，与发起调用的客户端产生的 Span，就构成了 ChildOf 关系
②：FollowsFrom关系
在分布式系统中，一些上游系统（父节点）不以任何方式依赖下游系统（子节点）的执行结果，例如，上游系统通过消息队列向下游系统发送消息。这种情况下，下游系统对应的子 Span 和上游系统对应的父级 Span 之间是 FollowsFrom 关系
3、SpanContext
Trace的全局上下文信息，如里面有TraceId
一次完成的请求链路就是一个Trace。TraceId是这个请求的全局标识。内部的每一次调用就称为一个Span，每个Span都要带上全局的TraceId，这样就能把全局TraceId与每个调用关联起来，TraceId是通过SpanContext传输的。
分布式链路追踪系统，skywalking：https://skywalking.apache.org/
TLog轻量级分布式链路追踪：
官网：https://tlog.yomahub.com/
Github：https://github.com/dromara/TLog 有空看下源码，不错
TLog提供了一种最简单的方式来解决日志追踪问题，它不收集日志，也不需要另外的存储空间，它只是自动的对你的日志进行打标签，自动生成TraceId贯穿你微服务的一整条链路。并且提供上下游节点信息。适合中小型企业以及想快速解决日志追踪问题的公司项目使用
参考：https://www.toutiao.com/i6884571378981274123/
原来10张图就可以搞懂分布式链路追踪系统原理：https://zhuanlan.zhihu.com/p/692868472
END.
