【微服务】关于分布式链路追踪

本篇的主要思路在于从分布式链路的思想开始，接下来介绍应用较广泛的开源实现Zipkin，最后对Spring Cloud Sleuth这个具体的解决方案进行说明。

追踪链的思想

追踪链的思想起初来源于Google关于Dapper的论文。核心思想在于：当一个请求经过多个服务，收集每个服务处理的具体执行情况。目前有很多机遇Dapper的开源实现，例如Zipkin，HTrace，SkyWalking等。

为什么需要链路追踪（链路治理）

微服务是一个分布式服务的设计范式，目的是将复杂的单体应用进行拆分，“左耳朵耗子”前辈说关于服务依赖的一句话：

微服务是服务依赖最优解的上限，服务依赖的下限是不要有依赖环

在这里，据我的理解，分布式链路追踪至少可以提供两个功能：

1. 快速定位故障节点
2. 梳理服务依赖关系

Zipkin

Zipkin可以让开发人员在服务进行调用时查看服务之间的依赖关系。

如果抛开基于Dapper的开源实现不谈，如果你来设计一个链路追踪框架，要考虑什么呢

首先，请求是跨多个服务的，怎么关联到一起；其次，日志聚合；再有，可视化，同时要有各个部分性能特征

Zipkin是一个开源数据可视化工具，可以显示跨多个服务的请求流。

Zipkin有如下四个主要组件：

1. Collector：收集器组件，主要处理从外部系统发来的跟踪信息，将信息转化为Zipkin内部处理到的Span格式，用来支持后续的存储，分析，展示等功能。
2. Storage：存储组件，主要处理收集器接收到的跟踪信息，默认存储到内存。但我们可以修改存储策略，通过其他存储组件将跟踪信息存储到数据库。
3. RESTful API：API组件，主要用来提供外部访问接口。
4. Web UI：UI组件

数据模型：

• Span：一个基础工作单元，

• Trace：具有一系列具有相同TraceId的Span串联形成的一个树状结构。在复杂的分布式系统中，每个外部请求通常会产生一个复杂的树状结构的Trace。

• Annotation：是一个包含时间戳的事件标签，用来记录一个事件的存在。对于一个HTTP请求，在Sleuth定义如下4个核心Annotation来标识一个请求开始和结束。

  1. cs（Client Send）：客户端发起了请求
  2. sr（Server Received）：服务端接收了请求
  3. ss（Server Send）：服务端处理完请求后准备发送请求响应
  4. cr（Client Received）：客户端接收到服务端的回复

• BinaryAnnotation：用来对跟踪信息添加额外的补充说明，一般以键值对方式出现

Spring Cloud Sleuth

Spring Cloud Sleuth是Spring Cloud中的分布式追踪解决方案。将关联ID填充到HTTP调用上，同时将生成的追踪数据提供给Zipkin。同时还允许开发人员自定义Trace。

实现方式：

Sleuth通过添加过滤器的方式与其他Spring组件进行交互，将生成的关联ID传递到所有系统调用。

分布式链路追踪的核心架构

Spring Cloud Sleuth和 Zipkin的合作

Sleuth自动捕获HTTP调用，入站和出站消息的追踪数据，同时将每个服务调用映射到一个跨度的概念，Zipkin可以查看一个跨度的性能。

####小试牛刀

1. 启动Zipkin的jar包（默认端口9411，数据存储在内存）

2. 应用程序中引入sleuth和zipkin相关依赖

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

3. 添加配置：spring.zipkin.baseUrl=http://localhost:9411

一个关于java入门的视频