开源项目
auto-log 自动日志输出
分布式链路追踪简介
随着业务系统的不停发展、微服务架构的演进，从原来的单体应用架构、垂直应用架构、分布式 SOA 架构到如今的微服务架构，系统渐渐走向微服务化以顺应用户高并发哀求等需求。
在微服务架构中，一个业务操纵往往需要多个服务间协同操纵，而在一个复杂的系统中出现问题的时间，需要我们能够快速的分析并定位到问题的原因，这就需要我们对业务举行一次还原，正是分布式链路追踪需要办理的问题。
分布式链路追踪就是将一次哀求还原成完备的链路，将一次分布式哀求的调用情况会合展示，比方哀求耗时、哀求节点的名称、相应状态等。
分布式链路跟踪重要功能： 故障快速定位：可以通过调用链团结业务日志快速定位错误信息，包括哀求时间、相应的状态、节点名称等信息，用于到达故障定位的本事；
链路性能可视化：各个阶段链路耗时、服务依靠关系通过可视化界面展现出来；
链路分析：通太过析链路耗时、服务依靠关系可以得到用户的举动路径，汇总分析应用在许多业务场景。
分布式链路追踪的基本原理
2.1 Dapper 模型
链路追踪系统最早是由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、被调用服务的名称、返回效果、网络耗时等。
疑问Q1：平级的节点之间，怎样知道先后，来生成不同大小的 spanid 呢？
如果上游节点，只是把 parent_sid（简称 psid） 传入下去。
那么，下游可以根据 psid 直接得到上游的 sid 信息，然后生成自己的 sid。
这样可以保证层级关系。
但是如果 psid 同时调用了两个下游 A / B。两个服务如果是独立的，各自生成 sid，又怎样保证大小呢？
引入一个新的变量，request_time 哀求的时间戳？
如果在上游，可以把下游节点的 sid 生成呢？也不合适
疑问Q2: 跨进程传递-上游的 traceId 与 psid 要怎样传递？
在 Dubbo 中的 attachment 就相当于 header，所以我们把 context 放在 attachment 中，这样就办理了 context 的传递问题。
类似的，http 与 mq 又怎样传递？
疑问Q3：生命周期怎样管理？
一个链路中的 traceId 是在什么时间设置，又是在什么时间清空的？
类似的, psid 应该在什么时间设置，又在什么时间清空？是不是类似于 mdc 的生命周期？
2.2 OpenTracing 模型
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 举行传输。
据此调用链路信息画出调用链的可视化视图如下：
链路追踪基本原理
链路追踪系统（可能）最早是由Goggle公开发布的一篇论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》被大家广泛熟悉，所以各位技术大牛们如果有黑武器不要藏起来赶紧去发表论文吧。
在这篇闻名的论文中重要报告了Dapper链路追踪系统的基本原理和关键技术点。
接下来挑几个重点的技术点详细给大家先容一下。
Trace
Trace的含义比较直观，就是链路，指一个哀求经过所有服务的路径，可以用下面树状的图形表示。
图中一条完备的链路是：chrome -> 服务A -> 服务B -> 服务C -> 服务D -> 服务E -> 服务C -> 服务A -> chrome。
服务间经过的局部链路构成了一条完备的链路，其中每一条局部链路都用一个全局唯一的traceid来标识。
Span
在上图中可以看出来哀求经过了服务A，同时服务A又调用了服务B和服务C，但是先调的服务B还是服务C呢？
从图中很难看出来，只有通过查看源码才知道顺序。
为了表达这种父子关系引入了Span的概念。
同一层级parent id相同，span id不同，span id从小到大表示哀求的顺序，从下图中可以很明显看出服务A是先调了服务B然后再调用了C。
上下层级代表调用关系，如下图服务C的span id为2，服务D的parent id为2，这就表示服务C和服务D形成了父子关系，很明显是服务C调用了服务D。
总结：通过事先在日志中埋点，找出相同traceId的日志，再加上parent id和span id就可以将一条完备的哀求调用链串联起来。
Annotations
Dapper中还界说了annotation的概念，用于用户自界说事件，用来辅助定位问题。
通常包罗四个注解信息：
cs：Client Start，表示客户端发起哀求；
sr：ServerReceived，表示服务端收到哀求；
ss： Server Send，表示服务端完成处理，并将效果发送给客户端；
cr：ClientReceived，表示客户端获取到服务端返回信息；
一次哀求和相应过程
上图中描述了一次哀求和相应的过程，四个点也就是对应四个Annotation事件。
如下面的图表示从客户端调用服务端的一次完备过程。如果要盘算一次调用的耗时，只需要将客户端接收的时间点减去客户端开始的时间点，也就是图中时间线上的T4 - T1。
如果要盘算客户端发送网络耗时，也就是图中时间线上的T2 - T1，其他类似可盘算。
带内数据与带外数据
链路信息的还原依靠于带内和带外两种数据。
带外数据是各个节点产生的事件，如cs，ss，这些数据可以由节点独立生成，并且需要会合上报到存储端。
通过带外数据，可以在存储端分析更多链路的细节。
带内数据如traceid,spanid,parentid，用来标识trace，span，以及span在一个trace中的位置，这些数据需要从链路的起点一直传递到终点。
通过带内数据的传递，可以将一个链路的所有过程串起来。
采样
由于每一个哀求都会生成一个链路，为了减少性能消耗，制止存储资源的浪费，dapper并不会上报所有的span数据，而是使用采样的方式。
举个例子，每秒有1000个哀求访问系统，如果设置采样率为1/1000，那么只会上报一个哀求到存储端。
通过收罗端自顺应地调解采样率，控制span上报的数目，可以在发现性能瓶颈的同时，有用减少性能消耗。
存储
链路中的span数据经过收集和上报后会会合存储在一个地方，Dapper使用了BigTable数据仓库，常用的存储还有ElasticSearch, HBase, In-memory DB等。
小结
盼望本文对你有所资助，如果喜好，接待点赞收藏转发一波。
我是老马，期待与你的下次相遇。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
