Spring Cloud F 版整合 Sleuth服务链路追踪 Zipkin 组件

前言

在微服务系统里，随着业务的发展，服务拆分成越来越多的微服务时，服务之间的调用关系也越来越复杂，经常一个业务流程要调用 N 个微服务才能完成，当一个业务流程请求变慢或者卡死时，我们需要知道到底是哪里调用出现了问题，所以需要服务链路追踪功能，帮助我们解决问题，Spring CLoud Sleuth应运而生。

Spring CLoud Sleuth

Spring CLoud Sleuth是一个服务链路追踪框架，可以结合 Zipkin 使用，将服务链路信息发送给 zipkin，通过zip-ui展示服务调用信息，只要各个服务添加依赖即可使用。

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

Zipkin

Zipkin 是一个由Twitter公司开源开源的分布式的跟踪系统，，它可以以解决微服务架构中的延迟问题，包括数据的收集、存储、查找和展现。

Spring Cloud F 版已经不用自己构建 Zipkin 服务了，只需要下载相应 jar 包，启动即可。

下载地址：https://dl.bintray.com/openzipkin/maven/io/zipkin/java/zipkin-server/

如图：

服务引入依赖后，默认 zipkin 的地址是 http://localhosty:9411/，可以通过配置文件修改：

spring:
  zipkin:
    base-url: http://localhost:9411/
  sleuth:
    sampler:
      probability: 1.0

这里有个坑是zipkin默认采样比率是0.1，也就是10次调用才采样一次，为了让每次调用都能被监控到，需要配置

spring.sleuth.sampler.probability的值，取值范围是 0.1到1.0，默认为0.1，这里配置成1.0。使其全部采样。

调用一次服务，观察页面：

调用详情

依赖关系

Zipkin数据存储方式

本次测试直接用的in-Memory 方式，在 Zipkin 服务重启后先前的调用数据就丢失了。

Zipkin提供了可插拔数据存储方式：In-Memory、Cassandra、MySql以及Elasticsearch。生产上比较推荐使用 Elasticseach。