Dubbox 链路追踪（基于Brave+Zipkin的简单实现）上

很多时候，我们都能体会到分布式架构的话好处，其实一个系统不大，做分布式的成本是很高的，系统变得松耦合，这样做的好处不言而喻，说说坏处吧，A系统远程调用B系统，B系统又依赖C,D系统，当线上某个接口报错，或者超时的时候，亦或者是业务问题的时候，定位一个问题是麻烦的，因为日记不在一个系统里面，排查问题的时候，需要花费很大的时间，往往定位问题的所在比解决这个问题花的时间长的多，所以解决这个问题，才会出来N多优秀的链路监控追踪系统。

  可惜，很多优秀的链路监控并没有开源~

 

其实链路追踪的实现的比较粗浅的理解（我的理解），其实就是前后filter，在filter中做埋点，记录调用的时间，参数，异常，等等信息，分布式系统需要多做的一件事就是有一个全局的变量（全局调用Id）来将整个调用链连接起来，形成调用闭环，最后最好再有一个可视化的监控平台，这样就可以帮助我们去查询问题的所在了。

5.2.1 简介Zipkin

5.2.1.1 走进Zipkin

 

如果不借助任何的第三方的jar包，单纯解决这种问题，还是比较困难的。简单的说下开源的Zipkin,Zipkin官网：http://zipkin.io/

Zipkin是一个分布式追踪系统，当我们在微服务架构中遇到潜在问题的时候，它会帮助我们按照时间的顺序有规则的去收集数据，并且帮我们管理数据和查询有用的数据，Zipkin是根据Google的论文Dapper设计的（dapper (dutch) = brave (english)）

 

Zipkin目的是用来记录应用程序的时间数据日记的，Zipkin UI还提供了一个系统之间的调用依赖图来向我们展示各个系统之间的请求链路关系，如果你遇到了一些bug或者系统报错的时候，你可以使用Zipkin UI来过滤，排序，通过这样的方式去排查问题，你可以在Zipkin中清晰的看见整个调用过程的链路长度，注释，时间戳，当你选择一条那个出问题的具体链路，你可以清晰的看见每个调用段占整个调用段的时间占比，这样就能够帮助你找到问题链路或者超时链路

5.2.1.2 Zipkin 搭建

作为学习用，Zipkin的搭建还是很简单的，它是默认使用内存做数据存储的，当然它也支持Elasticsearch,Mysql等做数据存储的，简单地搭建作为学习用的话，使用内存就可以了，生产环境还是使用Elasticsearch比较好，mysql性能也是堪忧

Windows7下搭建Zipkin，先打开http://zipkin.io/pages/quickstart.html

点击Lastest release

下载好之后：

进入下载好的目录,运行命令java-jar zipkin-server-1.19.1-exec.jar

因为是spring boot项目所以能够直接启动，浏览器打开localhost:9411

这样就完成了最简单的基于内存的Zipkin的搭建了

 

 

5.2.1.3 Zipkin 简单说明

 

Zipkin的简单设计原理图：

上图中，Instrumented client 目标服务消费者，如果它是需要进行链路导航的，它会在调用的时候，它会将在调用服务的时候，把一些参数通过Transport传递给Zipkin，同样当服务提供者接收到调用者的请求的时候，也会得到调用的上下文，也会把调用的信息，返回的信息形成Reporter通过Transport传递给Zipkin，相反，如果某些服务没有开启导航功能，则不会发出Reporter，Zipkin通过信息收集器（Collector）获取到信息之后，进行存储，然后形成调用查询的API,供UI页面查询。

 

  用大白话说，就是在远程调用的时候，服务消费者和服务提供者如果需要进行链路追踪，需要把调用的信息通过某个东西的传输给Zipkin，Zipkin帮忙分析记录你的调用过程。

 

Zipkin的数据设计和细节简单说明：

 

之前说过，Zipkin可以把分布式系统调用的日记集中在一起做分析处理，帮我们在远程调用出问题的时候，快速的定位问题，设计的简单思路就是类似那种filter，在特定的时候，进行数据拦击记录，然后形成固定的格式数据发送给Zipkin做处理。

 

考虑一下细节,与具体的使用场景进行结合，比如Dubbo，使用Dubbo在进行远程调用的时候，服务消费者在调用的时候，这个阶段Zipkin定义为CS

CS表示客户端开启，客户端开始请求，在这个阶段也会设置span

 

当请求通过网络到达服务提供者的时候，便达到了第二个阶段，Zipkin称之为SR

SR表示服务端接收，当服务提供者接收到请求的时候，将会去处理这个请求，这个阶段与上一个阶段其实是有上下文连接的，（CS可以在调用的上下文偷偷放置一个全局的TraceId）,当然这个阶段与上个阶段会有网络延迟和时间间隔

 

 

当服务提供者处理好请求准备返回的时候，到了第三个阶段SS

SS表示服务端发送请求，这个阶段表示服务端已经完成了请求的处理，然后准备把请求的结果发送回客户端，当然SS与SR之间在时间的维度上的区别就是多了服务消费者的处理时间

 

当返回结果通过网络达到服务消费者端的时候，就达到了第四阶段CR

CR表示客户端接收，当服务消费者接收到服务提供者的响应的时候，这就是表示了Span的结束了，经历了四个阶段，表示整个RPC的调用流程完成了，并且也会被这四个阶段记录.

 

 

 

5.2.1.4 Zipkin的几个重要的概念：

 

上文说有四个阶段，其实在分布式中，这四个阶段其实是在不同的系统中的，如果你想把这四个阶段连接在一起，也是经过处理的，打个比方，这四个节点就像四个珠子，如果你想把这四个珠子串联起来，还需要一条线：

 

线的定义（TraceId），链路ID，整个调用流程在CS阶段会形成一个链路ID,接下来的三个阶段公用整个TraceId

珠子的定义（span），每一个珠子都有一个模型叫做span，也有它的唯一标识SpanId，那么对于Span对象来说，它肯定知道自己上一个珠子的id（ParentId），自己的Id（SpanId）,整个链路的Id（TraceId）

 

5.2.1.5 Zipkin 小节

 

本小节简单地介绍了Zipkin的几个概念，还有一些细节，不是很好理解，比如Sampled, Flags等等，这些概念在使我们接下来的使用过程中会有些接触，接触到了，代码撸出来了，估计也会理解了。