Spring Cloud 应用篇 之 Spring Cloud Sleuth + Zipkin（一）链路监控
在微服务系统中，随着业务的发展，系统会变得越来越大，那么各个服务之间的调用关系也就变得越来越复杂。一个 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 文件：
spring-cloud-componets
com.geny
1.0-SNAPSHOT
4.0.0
spring-cloud-service1
org.springframework.boot
spring-boot-starter-web
org.springframework.cloud
spring-cloud-starter-netflix-eureka-client
org.springframework.cloud
spring-cloud-starter-netflix-ribbon
org.springframework.cloud
spring-cloud-starter-zipkin
org.springframework.boot
spring-boot-maven-plugin
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: debug3.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/
可以看到已经有我们的服务调用记录了
点击记录就可以清楚的看到我们的服务调用链路关系，可以看到每一个服务所所耗费的时间
点击依赖分析，可以看到服务之间的依赖关系
