从零到壹搭建一个商城架构--Sleuth+Zipkin服务链路追踪

如果想了解其他内容，请点击这里查看目录

1、为什么用

微服务架构是一个分布式架构，它按业务划分单元，一个分布式系统往往有很多个服务单元。由于服务单元数量众多，业务的复杂性，如果出现了错误和异常，很难去定位。主要体现在，一个请求可能需要调用很多个服务，而内部服务的调用复杂性决定了问题难以定位。所以微服务架构中，必须实现分布式链路追踪，去跟进一个请求到底哪些服务参与，参与的顺序又是怎样，从而达到每个请求的步骤清晰可见，出了问题，很快定位。

链路追踪组件有Google的Dapper，Twitter的Zipkin，以及阿里的Eagleeye（鹰眼）等，它们都是非常优秀的链路追踪开源组件

2、基本术语

• Span（跨度）：基本工作单元，发送一个远程调度任务，就会产生一个Span，Span是一个64位ID唯一标识的，Trace是用另一个64位ID唯一标识的，SPan还有其他数据信息，比如摘要、时间戳事件、Span的ID、以及进度ID。

• Trace（跟踪）：一系列Span组成的一个树状结构，请求一个微服务系统的API接口，这个API接口，需要调用多个微服务，调用每个微服务都会产生一个新的Apan，所有由这个请求产生的Span组成了这个Trace。

• Annotation（标注）：用来及时记录一个事件，一些核心注解用来定义一个请求的开始和结束。这些注解包含以下：

  • cs-Client Sent：客户端发送一个请求，这个注解描述了这个Span的开始

  • sr-Server Received：服务端获得请求并准备开始处理它，如果将其sr减去cs时间戳便可得到网络传输的时间

  • ss-Server Sent：服务端发送响应，该注解表明请求处理的完成）（当请求返回客户端），如果ss的时间戳减去sr时间戳，就可以得到服务器请求的时间

  • cr-Client Received：客户端接收响应，此时Span的结束，如果cr的时间戳减去cs的时间戳便可以得到整个请求锁消耗的时间

官方文档：https://cloud.spring.io/spring-cloud-static/spring-cloud-sleuth/2.1.3RELEASE/single/spring-cloud-sleuth.html

如果服务调用顺序如下

那么用以上概念完成的表示出来如下

3、整合Sleuth

服务提供者与消费者导入依赖

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

4、整合Zipkin可视化观察

4.1、为什么使用

通过Sleuth产生的调用链监控信息，可以得知微服务之间的调用链路，单监控信息只输出到控制台不方便查看。我们需要一个图形化的工具Zipkin。Zipkin事Twitter开源的分布式跟踪系统，主要用来手机系统的时序数据，从而追踪系统的调用问题。Zipkin官网地址如下：https://zipkin.io/

4.2、原理

4.3、安装步骤

1、docker安装zipkin服务器

docker run -d -p 9411:9411 openzipkin/zipkin

2、导入依赖

<!--导入zipkin依赖，zipkin依赖也同时包含了sleuth，可以省略sleuth的引用-->
<dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>

3、添加zipkin相关配置

spring:#服务链路追踪zipkin:#zipkin服务器地址base-url: http://192.168.56.10:9411/#关闭服务发现，否则SpringCloud会把zipkin的url当成一个服务名称discovery-client-enabled: falsesender:#设置使用http的方式传输数据type: websleuth:sampler:#设置抽样采集率为100%，默认为0.1，即10%probability: 1

5、Zipkin数据持久化

Zipkin默认是将监控数据存储在内存的，如果Zipkin挂掉或重启的话，那么监控数据就会丢失。所以如果想要搭建生产可用的Zipkin，就需要实现监控数据的持久化。而想要实现数据持久化，自然就是将数据存储到数据库。好在Zipkin支持将数据存储至：

• 内存（默认）
• mysql
• Elasticsearch
• Cassandra

Zipkin数据持久化相关的官方文档地址如下：

https://github.com/openzipkin/zipkin#storage-component

Zipkin支持的这几种存储方式中，内存显然是不适用于生产的，这一点开始也说了。而使用mysql的话，当数据量大时，查询较为缓慢，也不建议使用。Teitter官方使用的是Cassandra作为Zipkin的存储数据库，但国内大规模用Cassandra的公司较少，而且Cassandra相关文档也不多。

综上，故采用Elasticsearch是个比较好的选中，关于使用Elasticsearch作为Zipkin的存储数据库的官方文件如下：

elasticsearch-storage:

https://github.com/openzipkin/zipkin/tree/master/zipkin-server#elasticsearch-storage

zipkin-storage/elasticesearch:

https://github.com/openzipkin/zipkin/tree/master/zipkin-storage/elasticsearch

通过docker的方式，在生产环境启动如下：

docker run --env STORAGE_TYPE=elasticsearch --env ES_HOSTS=192.168.56.10:9200 openzipkin/zipkin-dependencies

可配置的环境变量参数如下：