背景
随着业务的发展，系统规模会变得越来越大，各微服务间的调用关系变得越来越复杂。通常一个由客户端发起的请求在后端系统中会经过多个不同的微服务调用来协调产生最后的请求结果，在复杂的微服务架构中，几乎每一个前端请求都会形成一条复杂的分布式服务调用链路，在每条链路中任何一个依赖服务出现延迟过高或错误的时候都有可能引起请求最后的失败。这时候，对于每个请求全链路调用的跟踪就显得很重要
案例准备
现在有一个微服务应用：trace-1，实现了一个REST接口/trace-1，调用该接口后将触发对trace-2应用的调用
trace-1
接下来创建trace-2服务，实现了一个REST接口/trace-2供trace-1调用：
trace-2
实现跟踪
在trace-1和trace-2中添加依赖：
依赖
此时再发送请求到trace-1，控制台输出如下所示：
控制台输出
这里面有几个重要的参数：
- trace-1：应用的名称
- f410ab57afd5cl45：称为TraceId，用来标识一条请求链路，一条请求链路中只包含一个TraceId
- a9f2118fa2019684：SpanId，表示一个基本的工作单元，比如发送一个HTTP请求，一条请求链路中包含多个SpanId
- false：表示是否要将该信息输出到zipkin等服务中来收集和展示
跟踪原理
主要包含下面两个关键点：
- 当请求发送到系统的入口端点时，服务跟踪框架为该请求创建一个唯一的跟踪标识，同时在系统内部流转的时候，框架始终保持传递该唯一标识，直到返回请求为止，这个唯一标识就是TraceId，通过TraceId的记录，就能将所有请求过程的日志关联起来
- 为了统计各处理单元的时间延迟，当请求到达各个服务组件时，或是处理逻辑到达某个状态时，也通过一个唯一标识来标记它的开始，具体过程以及结束，该标识就是SpanID；对于每个Span来说，必须有开始和结束两个节点，通过记录开始Span和结束Span的时间戳，就能统计出该Span的时间延迟，除了时间戳记录之外，还包含一些其他元数据，比如事件名称，请求信息等
网友评论