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 

posted @ 2019-08-16 10:11  这个名字想了很久~  阅读(360)  评论(0编辑  收藏  举报