Spring Cloud Sleuth + Zipkin 链路监控

原文：https://blog.csdn.net/hubo_88/article/details/80878632

 

在微服务系统中，随着业务的发展，系统会变得越来越大，那么各个服务之间的调用关系也就变得越来越复杂。一个 HTTP 请求会调用多个不同的微服务来处理返回最后的结果，在这个调用过程中，可能会因为某个服务出现网络延迟过高或发送错误导致请求失败，这个时候，对请求调用的监控就显得尤为重要了。Spring Cloud Sleuth 提供了分布式服务链路监控的解决方案。下面介绍 Spring Cloud Sleuth 整合 Zipkin 的解决方案。

（一）简介
Zipkin 是 Twitter 的一个开源项目，它基于 Google Dapper 实现的。我们可以使用它来收集各个服务器上请求链路的跟踪数据，并通过它提供的 REST API 接口来辅助查询跟踪数据以实现对分布式系统的监控程序，从而及时发现系统中出现的延迟过高问题。除了面向开发的 API 接口之外，它还提供了方便的 UI 组件来帮助我们直观地搜索跟踪信息和分析请求链路明细，比如可以查询某段时间内各用户请求的处理时间等。

Zipkin 和 Config 结构类似，分为服务端 Server，客户端 Client，客户端就是各个微服务应用。

（二）搭建 Zipkin 服务端
在 Spring Boot 2.0 版本之后，官方已不推荐自己搭建定制了，而是直接提供了编译好的 jar 包。详情可以查看官网：https://zipkin.io/pages/quickstart.html

可以在终端使用以下命令：

curl -sSL https://zipkin.io/quickstart.sh | bash -s
java -jar zipkin.jar
使用 docker 的方式

docker run -d -p 9411:9411 openzipkin/zipkin
任一方式启动后，访问 http://localhost:9411，可以看到服务端已经搭建成功

 

（三）搭建 Zipkin 客户端
创建两个服务，spring-cloud-service1、spring-cloud-service2，service1 实现一个 REST 接口 /service1，该接口里调用 service2 应用。

3.1 创建 spring-cloud-service1
3.1.1 引入依赖，pom 文件：
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<parent>
<artifactId>spring-cloud-componets</artifactId>
<groupId>com.geny</groupId>
<version>1.0-SNAPSHOT</version>
</parent>
<modelVersion>4.0.0</modelVersion>

<artifactId>spring-cloud-service1</artifactId>

<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-ribbon</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>
</dependencies>

<build>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
</project>
3.1.2 配置文件：
server:
port: 8481
spring:
application:
name: service1
zipkin:
base-url: http://192.168.174.128:9411/
eureka:
client:
service-url:
defaultZone: http://localhost:8761/eureka/
logging:
level:
root: debug
3.1.3 启动类
@SpringBootApplication
@EnableEurekaClient
@RestController
public class Service1Application {

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

@Bean
@LoadBalanced
RestTemplate restTemplate() {
return new RestTemplate();
}

@RequestMapping(value = "service1", method = RequestMethod.GET)
public String service1() {
return restTemplate().getForObject("http://service2/service2", String.class);
}
}
3.2 创建 spring-cloud-service2
service2 的 pom.xml 文件、配置文件是一样的，只需要修改相应的端口和应用名称即可。

启动类如下：

@SpringBootApplication
@EnableEurekaClient
@RestController
public class Service2Application {

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


@RequestMapping(value = "service2", method = RequestMethod.GET)
public String service2() {
return "Hi,I'm Service2!";
}
}
3.3 验证
依次启动 eureka-server、spring-cloud-service1、spring-cloud-service2，访问 http://localhost:8481/service1

 

接口访问已经成功，此时，我们查看一下控制台的日志输出：

 

从上面的控制台输出内容中，我们可以看到多了一些如 [service1,450165b378a38236,92377ff04d8a9cfb,false] 的日志信息，而这些元素正是实现分布式服务跟踪的重要组成部分，每个值的含义如下：

第一个值：service1，它记录了应用的名称
第二个值：450165b378a38236，是 Spring Cloud Sleuth 生成的一个 ID，称为 Trace ID，它用来标识一条请求链路。一条请求链路中包含一个 Trace ID，多个 Span ID。
第三个值：92377ff04d8a9cfb，是 Spring Cloud Sleuth 生成的另外一个 ID，称为 Span ID，它表示一个基本的工作单元，比如发送一个 HTTP 请求。
第四个值：false，它表示是否要将该信息输出到 Zipkin Server 中来收集和展示。
上面四个值中的 Trace ID 和 Span ID 是 Spring Cloud Sleuth 实现分布式服务跟踪的核心。在一次请求中，会保持并传递同一个 Trance ID，从而将整个fenbu分布于不同微服务进程中的请求跟踪信息串联起来。

下面我们访问 Zipkin Server 端，http://192.168.174.128:9411/

 

 

发现服务名下并没有看到我们的应用，这是为什么呢？

这是因为 Spring Cloud Sleuth 采用了抽样收集的方式来为跟踪信息打上收集标记，也就是上面看到的第四个值。为什么要使用抽样收集呢？理论上应该是收集的跟踪信息越多越好，可以更好的反映出系统的实际运行情况，但是在高并发的分布式系统运行时，大量请求调用会产生海量的跟踪日志信息，如果过多的收集，会对系统性能造成一定的影响，所以 Spring Cloud Sleuth 采用了抽样收集的方式。

既然如此，那么我们就需要把上面第四个值改为 true，开发过程中，我们一般都是收集全部信息。

Sleuth 默认采样算法的实现是 Reservoir sampling，具体的实现类是 PercentageBasedSampler，默认的采样比例为: 0.1，即 10%。我们可以通过 spring.sleuth.sampler.probability 来设置，所设置的值介于 0 到 1 之间，1 则表示全部采集

修改配置文件如下:

server:
port: 8481
spring:
application:
name: service1
zipkin:
base-url: http://192.168.174.128:9411/
  sleuth:
sampler:
probability: 1.0
eureka:
client:
service-url:
defaultZone: http://localhost:8761/eureka/
logging:
level:
root: debug
再次启动 spring-cloud-service1、spring-cloud-service2，访问 http://localhost:8481/service1

查看后台日志：

 

这个时候，第四个值已经为true了，再访问 http://192.168.174.128:9411/

 

可以看到已经有我们的服务调用记录了

选择 service1，点击 Find Trances，可以看到我们的服务调用记录

点击记录就可以清楚的看到我们的服务调用链路关系，可以看到每一个服务所所耗费的时间

 

点击依赖分析，可以看到服务之间的依赖关系

 

 

源码下载：https://github.com/shmilyah/spring-cloud-componets