但行好事，莫问前程。互联网的前程如何网络上各种大神从十万八千个纬度已经分析过了，但是作为技术人员，我们需要的是练好内功，厚积薄发。

一、为什么要用链路跟踪

微服务大行其道的今天，如果做的是一个单体应用，甚至三个以内的服务，对于问题的排查上，使用原始的登录服务器，一个一个日志文件对比当然可行，并且一般结合用户的资金情况，大概率是要使用这种方案的。

然后当有了五个、十个、五十个服务，每个服务有10个节点的集群时候，怎么破？一台一台去查？当然不现实。这时候就需要一个分布式日志系统来帮忙收集、清洗、分析日志，并提供良好的查询方式。

日志可以查询了，那么所有的都集中到一起，微服务又是网格状调用关系，怎么知道哪个服务的上下游关系呢？知道了上下游之后又怎么对应到某一次请求上呢？

顾名思义：链路跟踪解决某一次请求从头到尾（经历N个微服务调用）的整个链路状况，包括各服务上时间消耗、调用顺序等。

二、方案选择

基于以上需求，日志管理系统当前有多种解决方案：阿里系、腾讯系。当然对于更多的应该是开源系，开源环境中当前最流行的莫过于ELK架构。但是对于这个系列文章，只针对日志系统中链路跟踪这一个小的点进行讨论。

网上有多种方案，zipkin+sleuth、skywalking、CAT、Pinpoint等，各有优缺点，大家可以参考下图自行比较选择。 由于我使用springboot+spring cloud，因此决定走全家桶的模式，选择zipkin+sleuth，理论上应该会支持的更好，然鹅······ 

现实很骨感，因为我的RPC框架选择了dubbo，而阿里早已将dubbo交给apache，包路径已从com.alibaba.dubbo 2.6.6 升级为org.apache.dubbo 2.7.12，而sleuth的进展比较缓慢，如今仍不支持dubbo2.7+，因此暂时舍弃sleuth，只集成zipkin来进行手动跟踪。

三、原理

通过拦截器生成(或放入) traceId，spanId，parentId，其中traceId作为整个请求过程的跟踪依据，贯穿整个请求过程；spanId为某个服务唯一，作为下游服务的parentId，用于构建上下游调用关系。

四、预期效果

构建web应用A，dubbo服务B，dubbo服务C。A作为请求入口，调用服务B，服务B作为消费者，调用服务C。希望可以通过traceId,spanId,parentId来分析整个调用过程。 

希望得到如下结构，便可根据traceId=1获取整个请求过程由A、B、C组成，且调用关系为A-->B-->C：

A: traceId = 1,spanId = 1,parentId='';B: traceId = 1,spanId = 2, parentId = 1;C: traceId = 1,spanId = 3, parentId = 2;