序言

sleuth是spring cloud的分布式跟踪工具，主要记录链路调用数据，本身只支持内存存储，在业务量大的场景下，为拉提升系统性能也可通过http传输数据，也可换做rabbit或者kafka来传输数据。

zipkin是Twitter开源的分布时追踪系统，可接收数据，存储数据（内存/cassandra/mysql/es），检索数据，展示数据，他本神不会直接在分布式的系统服务种trace追踪数据，可便捷的使用sleuth来收集传输数据。

这样描述，大家应该很清晰啦。

服务追踪意义

目前流行的架构现状，都是站在微服务架构的基础之上，那么势必会产生出越来越多的服务，相互依赖调用，那么如果服务调用关系如下图所示。

越来越多的服务可能，调用关系就如下啦，一团乱麻，如果没有服务之间的链路追踪的记录查询方案，想快速定位问题，翻代码都不知从何翻起，估计锁定责任人更要撕逼一翻啦，哈哈。

行业方案

Google开源的 Dapper链路追踪组件，并在2010年发表了论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》，这篇文章是业内实现链路追踪的标杆和理论基础，具有非常大的参考价值。

链路追踪组件有如下产品，都很赞，很值得学习：

Google的Dapper
Twitter的Zipkin
阿里的Eagleeye （鹰眼）
美团点评的Cat
新浪的Watchman
京东的Hydra
个人吴晟（华为开发者）开源的skywalking (很赞)
韩国团队naver团队开源pinpoint

有时间大家学习一番啊。

Sleuth链路追踪专业术语

Spring Cloud Sleuth采用的是Google的开源项目Dapper的专业术语。

Span：基本工作单元，例如，在一个新建的span中发送一个RPC等同于发送一个回应请求给RPC，span通过一个64位ID唯一标识，trace以另一个64位ID表示，span还有其他数据信息，比如摘要、时间戳事件、关键值注释(tags)、span的ID、以及进度ID(通常是IP地址),span在不断的启动和停止，同时记录了时间信息，当你创建了一个span，你必须在未来的某个时刻停止它。
Trace：一系列spans组成的一个树状结构，例如，如果你正在跑一个分布式大数据工程，你可能需要创建一个trace。
Annotation：用来及时记录一个事件的存在，一些核心annotations用来定义一个请求的开始和结束
- cs - Client Sent -客户端发起一个请求，这个annotion描述了这个span的开始
- sr - Server Received -服务端获得请求并准备开始处理它，如果将其sr减去cs时间戳便可得到网络延迟
- ss - Server Sent -注解表明请求处理的完成(当请求返回客户端)，如果ss减去sr时间戳便可得到服务端需要的处理请求时间
- cr - Client Received -表明span的结束，客户端成功接收到服务端的回复，如果cr减去cs时间戳便可得到客户端从服务端获取回复的所有所需时间

将Span和Trace在一个系统中使用Zipkin注解的过程图形化：

trace id 整个链路中是唯一不变的，这样也方便查询。

zipkin介绍

zipkin主要有四个组件：collector，storage，API，web UI。collector用于收集各服务发送到zipkin的数据，storage用于存储这些链路数据，目前支持Cassandra，ElasticSearch（推荐使用，易于大规模扩展）和MySQL，API用来查找和检索跟踪链，提供给界面UI展示。

链路的追踪原理：跟踪器位于应用程序中，记录发生的操作的时间和元数据，收集的跟踪数据称为Span，将数据发送到Zipkin的仪器化应用程序中的组件称为Reporter，Reporter通过几种传输方式（http，kafka）之一将追踪数据发送到Zipkin收集器(collector)，然后将跟踪数据进行存储(storage)，由API查询存储以向UI提供数

具体项目搭建

上面是我的示例项目。

1.trade-zipkin-server是zipkinserver，是用来展示，搜索，存储trade追踪数据用的。

2.shop-->order-->shouhou & promotion（简单的调用链路，这里是具体需要的业务链路追踪的trace项目哈）。

zipkinserver配置代码

@EnableZipkinServer
public class StartMain {
    public static void main(String[] args) {
        SpringApplication.run(StartMain.class, args);
    }
}

    <dependency>
            <groupId>io.zipkin.java</groupId>
            <artifactId>zipkin-server</artifactId>
            <version>2.11.8</version>
        </dependency>
        <dependency>
            <groupId>io.zipkin.java</groupId>
            <artifactId>zipkin-autoconfigure-ui</artifactId>
            <version>2.11.8</version>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-zipkin</artifactId>
        </dependency>

业务项目配置

spring.sleuth.enabled=true
spring.sleuth.sampler.percentage=1
spring.zipkin.base-url=http://localhost:8087

 <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-sleuth</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-sleuth-zipkin</artifactId>
        </dependency>

note：

spring.sleuth.sampler.percentage参数配置（如果不配置默认0.1），如果我们调大此值为1，可以看到信息收集就更及时。但是当这样调整后，我们会发现我们的rest接口调用速度比0.1的情况下慢了很多，即使在0.1的采样率下，我们多次刷新consumer的接口，会发现对同一个请求两次耗时信息相差非常大，如果取消spring-cloud-sleuth后我们再测试，会发现并没有这种情况，可以看到这种方式追踪服务调用链路会给我们业务程序性能带来一定的影响。

zipkin收集展示数据界面如下：

seluth+zipkin数据写入Elasticsearch，使用kibana展示

配置zipkinserver

zipkin.storage.StorageComponent=elasticsearch
zipkin.storage.type=elasticsearch
#可以做集群，我用的本地测试没有部署elastic集群
zipkin.storage.elasticsearch.hosts=es.me.com
zipkin.storage.elasticsearch.cluster=iron-man
zipkin.storage.elasticsearch.index=trade-zipkin
zipkin.storage.elasticsearch.index-shards=5
zipkin.storage.elasticsearch.index-replicas=1

总结

其实，我这个案例，只是让你熟悉了解服务链路追踪，能够兼顾性能的整体方案如下。

Spring Cloud Sleuth+ZipKin+ELK服务链路追踪（七）

序言