在微服务系统中，随着业务的发展，系统会变得越来越大，那么各个服务之间的调用关系也就变得越来越复杂。一个 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/<span style="color:#ff0000;">
-
sleuth:
-
sampler:
-
probability:
1.0</span>
-
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/
可以看到已经有我们的服务调用记录了
点击记录就可以清楚的看到我们的服务调用链路关系，可以看到每一个服务所所耗费的时间
点击依赖分析，可以看到服务之间的依赖关系
扫一扫
7243
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
