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

序言

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

<dependency>
            <groupId>io.zipkin.java</groupId>
            <artifactId>zipkin-autoconfigure-storage-elasticsearch-http</artifactId>
            <version>2.8.4</version>
        </dependency>

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

总结

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