前言

通过记录请求调用的链路信息，可以帮助我们明确调用关系，定位耗时环节，分析用户行为等，现在大多数应用都不会是一个程序，而是有多个服务组成的分布式系统，通过sleuth可以实现服务间的链路追踪，确定调用关系。以网关为场景，有spring gateway网关程序提供对外访问，user-rest程序提供用户相关接口，网关及服务间通过注册中心进行注册发现，当用户请求网关时，网关会调用相应下层服务，获取结果返给用户，下层服务可能还会调用其它服务，这一过程就是一个调用链，以此为例实现sleuth与zipkin集成，得益于spring的高度集成，集成过程也非常简单。

集成sleuth

在各层服务程序中加入sleuth支持，添加maven依赖：

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

添加配置：

spring:
  sleuth:
    sampler:
      probability: 1 # 样本采集比率

其中抽样率控制传输到远程服务的比例，如设为0.5，则对每一请求会有50%的机率收集跟踪信息并传输至远程存储服务(如zipkin)。

此时启动程序，调用相应接口，程序有日志打印，就会看到sleuth已经将跟踪信息注入到了日志中，如下：

INFO [user-rest,2ffbf34c7ab86715,0d14ed6c18834a3c] 880 --- [io-18100-exec-1] t.w.userrest.controller.UserController   : Get user info ...

其中INFO后中括号内内容即为sleuth注入的跟踪信息，有逗号隔开三部分组成，第一部分为服务名，第二部分为parent trace id，第三部分为span id，对于一条完整的调用链，其trace id应该是一致的，对于调用链中的每一服务，其span id是一致的，也就是通过trace id可唯一确定一条完整调用链，span id可确定调用链中的一个环节。调用链及服务调用依赖关系即可根据这两个id分析生成。

引入zipkin

只引入sleuth追踪信息只是在服务自身的log日志中可见，通过引入zipkin，统一收集各服务的调用链信息并分析，可直观的看到各分布式服务的调用链、依赖关系及耗时情况。

下载zipkin服务

zipkin提供了自动下载脚本，脚本会自动下载zipkin的jar包并进行md5校验：

curl -sSL https://zipkin.io/quickstart.sh | bash -s

下载下来的为一个jar包，直接通过java -jar运行即可：

java -jar zipkin.jar

访问http://localhost:9411/zipkin/即可看到zipkin界面。

集成zipkin

在各服务中引入依赖：

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

配置文件中配置zipkin的服务地址：

spring:
  zipkin:
    base-url: http://127.0.0.1:9411

sleuth检测到zipkin依赖后，会自动将链路信息报告给zipkin，zipkin将信息上报给server端。

启动程序进行访问，在zipkin中即可看到依赖关系：

其还比较贴心的动态展示了数据流的方向。

同时可查询到调用链：

点击记录，可查看到详细的调用链信息，如下：

同时点击相应记录能看到具体每个span的时间信息：

并且标签中可以看到调用的方法：

除了这种以http的方式上报信息至server端外，zipkin还提供了mysql、Elasticsearch、RabbitMq等的集成，可以应用于需求更复杂的链路信息存储、分析场景。