zipkin：打造自己的链路跟踪系统（一）

在微服务盛行的时代，一个公司的应用数量动辄成百上千个。应用之间的依赖关系错综复杂，定位问题、排查问题是一件令人头疼的事情。
为了解决这个问题，Google的Dapper论文应运而生。Twitter基于该论文打造了自己的链路跟踪系统（也就是本文章的主角）：zipkin并将其开源

简介

Zipkin is a distributed tracing system. It helps gather timing data needed to troubleshoot latency problems in service architectures. Features include both the collection and lookup of this data.

Zipkin是一个分布式追踪系统。它有助于收集解决服务架构中的延迟问题所需的计时数据。功能包括收集和查找此数据。

简单的介绍一下zipkin，详细的介绍请移步：zipkin官网

架构

• reporter：上报链路数据的模块，配置在具体的应用中
• transport：传输链路数据的模块，通常为http、Kafka
• collector：收集&消费链路数据的模块，默认通过http收集，可以配置为Kafka消费
• storage：存储链路数据的模块，具体实例可以为ES、Cassandra或者mysql

链路数据模型

[
    {
   
        "traceId":"5982fe77008310cc80f1da5e10147517",
        "name":"get",
        "id":"bd7a977555f6b982",
        "timestamp":1458702548467000,
        "duration":386000,
        "localEndpoint":{
   
            "serviceName":"zipkin-query",
            "ipv4":"192.168.1.2",
            "port":9411
        },
        "annotations":[
            {
   
                "timestamp":1458702548467000,
                "value":"sr"
            },
            {
   
                "timestamp":1458702548853000,
                "value":"ss"
            }
        ]
    }
]

其它更多有关于zipkin的信息请移步：

• zipkin官网
• zipkin github

为什么要选zipkin

业界还有其它开源的链路跟踪系统，为什么要选择zipkin？

首先列举自己的核心诉求：

1. 性能影响小：能够容忍轻微的性能损失
2. 多语言支持：Java、Node、Go等
3. 插件可扩展：可以定制化开发链路跟踪插件
4. 社区支持力度大：自己不需要过多的开发链路插件
5. 接入成本小

业界开源的主流链路跟踪系统：

1. skywalking
2. pinpoint
3. zipkin
4. jaeger

主要对比skywalking和zipkin

	skywalking	zipkin
内部实现方式	javaagent，字节码增强	aop插件
语言支持	多语言	多语言
性能	好	好
插件扩展	困难	容易
接入成本	低，开发无感知	低，开发需要配置
社区支持	好	好

可以看到

• skywalking相较于zipkin的优势在于接入成本低、性能稍好
• zipkin相较于skywalking的优势在于插件扩展容易

我们最终选择的是zipkin

zipkin和brave

首先说明一下zipkin和brave的关系：

1. 从开头的架构图中可以看到：zipkin是服务端，用于查询分析、收集和持久化链路数据
2. brave则是zipkin官方出品的Java语言的链路数据采集插件。同理还有js、go版本的采集插件

搭建zipkin服务器

在官方的demo中提供了docker镜像启动和jar包启动，但如果要做个性化开发的话必须通过自建项目然后引入zipkin server依赖进行启动。
前面两种启动方式官网都有详细的教程，这里就不介绍了。下面主要介绍一下自建项目引入zipkin server依赖启动的方式。

创建SpringBoot项目

创建好SpringBoot项目后&#