Sleuth 二

一，二篇是一起在写，没有实物参考，感觉很难说。

首先启动一个Eureka注册中心，然后启动一个生产者，一个消费者，消费者去调用生产者。

在两个服务的pom.xml中添加依赖：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-sleuth</artifactId>
    <version>1.3.2.RELEASE</version>
</dependency>

然后启动调用:会在消费者这端刷出大量的日志。

 INFO [trace-1,14071cd1d63f3520,e559bbd4e7057442,false] 

第一个值： trace-1, 它记录了应用的名称，也就是 application.properties中 spring.application.name参数配置的属性

第二个值： 1,14071cd1d63f3520, Spring Cloud Sleuth生成的一个ID,称为Trace ID,它用来标识一条请求链路。 一条请求链路中包含一个TraceID, 多个SpanID。

第三个值： e559bbd4e7057442, Spring Cloud Sleuth生成的另外一个 ID, 称为Span ID, 它表示一个基本的工作单元， 比如发送一个HTTP请求。

第四个值： false, 表示是否要将该信息输出到Zipkin等服务中来收集和展示。

上面四个值中的Trace ID和SpanID是Spring Cloud Sleuth实现分布式服务跟踪的核心。 在一次服务请求链路的调用过程中， 会保待并传递同一个Trace ID, 从而将整个分布于不同微服务进程中的请求跟踪 信息串联起来。

    在使用RestTemplate请求，sleuth 组件会对该请求进行处理。在发送到trace-2 之前， Sleuth会 在该请求的Header中增加实现 跟踪需要的重要信息，主要有下面这几个（更多关于头信息的定义可以通过查看 org.springframework.cloud.sleuth.Span的源码获取）。

• X-B3-Traceld: 一条请求链路 (Trace) 的唯一标识， 必需的值。

• X-B3-Spanld: 一个工作单元 (Span) 的唯一标识， 必需的值。

• X-B3-ParentSpanld: 标识当前工作单元所属的上一个工作单元 ， Root Span(请求链路的第一个工作单元)的该值为空。

• X-B3-Sampled: 是否被抽样输出的标志， 1 表示需要被输出 ， 0 表示不需要被输出 。

• X-Span-Name: 工作单元的名称。

这些参数都是可以在请求头中取到的。

Sleuth和ELK配合使用，可以帮助我们收集日志

    通过之前的准备与整合，我们已经为trace-1和trace-2引入了Spring Cloud Sleuth，实现了在各个微服务的日志信息中添加跟踪信息的功能。但是，由于日志文件都离散地存储在各个服务实例的文件系统之上， 仅仅通过查看日志文件来分析我们的请求链路依然是一件相当麻烦的事， 所以我们还需要一些工具来帮助集中收集、 存储和搜索这些跟踪信息。 引入基于日志的分析系统是一个不错的选择， 比如ELK平台， 它可以轻松地帮助我们收集和存储这些跟踪日志， 同时在需要的时候我们也 可以根据Trace ID来轻松地搜索出对应请求链路 相关的明细日志。大多都是配置，在这里就不多叙述了。

与Zipkin整合

        虽然通过 ELK 平台提供的收集、存储、 搜索等强大功能， 我们对跟踪信息的管理和使用已经变得非常便利。但是，在 ELK 平台中的数据分析维度缺少对请求链路中各阶段时间延迟的关注， 很多时候我们追溯请求链路的一个原因是为了找出整个调用链路中出现延迟过高的瓶颈源， 或为了实现对分布式系统做延迟监控等与时间消耗相关的需求， 这时候类似 ELK 这样的日志分析系统就显得有些乏力了。 对于这样的问题， 我们就可以引入 Zipkin来得以轻松解决。Zipkin 是 Twitter 的一个开源项目， 它基于 Google Dapper 实现。 我们可以使用它来收集各个服务器上请求链路的跟踪数据， 并通过它提供的 REST API 接口来辅助查询跟踪数据以实现对分布式系统的监控程序， 从而及时发现系统中出现的延迟升高问题并找出系统性能瓶颈的根源。 除了面向开发的 API 接口之外， 它还提供了方便的 UI 组件来帮助我们直观地搜索跟踪信息和分析请求链路明细， 比如可以查询某段时间内各用户请求的处理时间等。

        简单的说：使用Zipkin可以帮助我们收集系统的时序数据，来跟踪微服务框架的系统延时的问题。Zipkin还有一个页面可以帮助我们分析追踪数据。

    Zipkin的基础结构，它主要是4个核心组件构成的。

    

整合Zipkin：

新启动一个工程，pom.xml

<dependency>
    <groupId>io.zipkin.java</groupId>
    <artifactId>zipkin-server</artifactId>
    <version>2.4.6</version>
</dependency>

<dependency>
    <groupId>io.zipkin.java</groupId>
    <artifactId>zipkin-autoconfigure-ui</artifactId>
    <version>2.4.6</version>
</dependency>

配置:

spring.application.name=zipkin-server
server.port=9411

然后在生产者和消费者添加依赖和配置，一样的。

pom.xml

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-sleuth-zipkin</artifactId>
    <version>1.3.2.RELEASE</version>
</dependency>

配置:

spring.zipkin.base-url=http://localhost:9411

然后将4个项目启动，在页面上访问http://localhost:9411/就可以看见Zipkin的可视化页面。

但是这样会导致，Zipkin和我们程序的耦合性比较高，可以通过队列来降低耦合性。可以使用stream来达到我们的要求。

在生产者和消费者依赖：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-eureka</artifactId>
    <version>1.3.5.RELEASE</version>
</dependency>

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-sleuth</artifactId>
    <version>1.3.2.RELEASE</version>
</dependency>
<!--在使用队列的时候这个依赖需要删除 不然会冲突-->
<!--<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-sleuth-zipkin</artifactId>
    <version>1.3.2.RELEASE</version>
</dependency>-->

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-sleuth-stream</artifactId>
    <version>1.3.2.RELEASE</version>
</dependency>

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-stream-rabbit</artifactId>
    <version>1.3.2.RELEASE</version>
</dependency>

Zipkin服务端:

<dependency>
    <groupId>io.zipkin.java</groupId>
    <artifactId>zipkin-server</artifactId>
    <version>2.4.6</version>
</dependency>

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-sleuth-zipkin-stream</artifactId>
    <version>1.3.2.RELEASE</version>
</dependency>

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-stream-rabbit</artifactId>
    <version>1.3.2.RELEASE</version>
</dependency>

<dependency>
    <groupId>io.zipkin.java</groupId>
    <artifactId>zipkin-autoconfigure-ui</artifactId>
    <version>2.4.6</version>
</dependency>

启动类:

package com.yjp.zipkinserver;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.sleuth.zipkin.stream.EnableZipkinStreamServer;

@EnableZipkinStreamServer
//@EnableZipkinServer
@SpringBootApplication
public class ZipkinServerApplication {

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

这样就可以使用队列的方式了。

还有一个最后存储的问题。

    默认情况下， Zipkin Server 会将跟踪信息存储在内存中， 每次重启 Zipkin Server 都会使之前收集的跟踪信息丢失， 并且当有大量跟踪信息时我们的内存存储也会成为瓶颈， 所以通常情况下我们都需要将跟踪信息对接到外部存储组件中去， 比如使用 MySQL 存储。Zipkin 的 Storage 组件中默认提供了对 MySQL 的支持， 所以我们可以很轻松地为Zipkin -server 增加 MySQL 存储功能。 下面我们详细介绍基于消息中间件实现的Zipkin -server 应用， 对其进行 MySQL 存储扩展的详细过程。

pom.xml

<!--将跟踪信息存储到mysql中-->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-jdbc</artifactId>
</dependency>

<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
</dependency>
<!--导入这个包是因为版本bug的原因-->
<dependency>
    <groupId>org.jooq</groupId>
    <artifactId>jooq</artifactId>
    <version>3.8.0</version>
</dependency>

配置:

#存储的数据库的配置
spring.datasource.schema=classpath:/mysql.sql
spring.datasource.url=jdbc:mysql://localhost:3306/zipk印
spring.datasource.username=root
spring.datasource.password=l23456
spring.datasrouce.continueOnError=true
spring.datasrouce.initialize=true
#切换存储类型
zipkin.storage.type=mysql

这样就完成了存储类型的转换。整合到这里就结束了，大多都是书上的内容。

努力吧，皮卡丘。