Sleuth+Zipkin 来进行分布式服务链路的追踪

为什么用

微服务架构是一个分布式架构，它按业务划分服务单元，一个分布式系统往往有很多个服务

单元。由于服务单元数量众多，业务的复杂性，如果 出现了错误和异常，很难去定位 。主要

体现在， 一个请求可能需要调用很多个服务 ，而内部服务的调用复杂性，决定了问题难以

定位。所以微服务架构中，必须实现分布式链路追踪，去跟进一个请求到底有哪些服务参与，

参与的顺序又是怎样的，从而 达到每个请求的步骤清晰可见，出了问题，很快定位 。

链路追踪组件有 Google 的 Dapper ， Twitter 的 Zipkin ，以及阿里的 Eagleeye （鹰眼）等，它

们都是非常优秀的链路追踪开源组件。

基本术语

Span （跨度）：基本工作单元，发送一个远程调度任务 就会产生一个 Span ， Span 是一

个 64 位 ID 唯一标识的， Trace 是用另一个 64 位 ID 唯一标识的， Span 还有其他数据信

息，比如摘要、时间戳事件、 Span 的 ID 、以及进度 ID 。

Trace （跟踪）：一系列 Span 组成的一个树状结构。请求一个微服务系统的 API 接口，

这个 API 接口，需要调用多个微服务，调用每个微服务都会产生一个新的 Span ，所有

由这个请求产生的 Span 组成了这个 Trace 。

Annotation （标注）：用来及时记录一个事件的，一些核心注解用来定义一个请求的开

始和结束 。这些注解包括以下：

cs - Client Sent - 客户端发送一个请求，这个注解描述了这个 Span 的开始

sr - Server Received - 服务端获得请求并准备开始处理它，如果将其 sr 减去 cs 时间戳

便可得到网络传输的时间。

ss - Server Sent （服务端发送响应） – 该注解表明请求处理的完成 ( 当请求返回客户

端 ) ，如果 ss 的时间戳减去 sr 时间戳，就可以得到服务器请求的时间。

cr - Client Received （客户端接收响应） - 此时 Span 的结束，如果 cr 的时间戳减去

cs 时间戳便可以得到整个请求所消耗的时间。

项目整合Sleuth+Zipkin

导入maven依赖

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

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-dependencies</artifactId>
            <version>Greenwich.SR3</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

properties配置文件

spring.zipkin.base-url=http://121.37.191.188:9411/
spring.zipkin.discovery-client-enabled=false
spring.zipkin.sender.type=web
spring.sleuth.sampler.probability=1

测试

 

总结

分布式微服务系统接口出现问题了之后，可以使用这个Zipkin进行排查具体的问题所在