分布式服务跟踪及Spring Cloud的实现

在分布式服务架构中，需要对分布式服务进行治理——在分布式服务协同向用户提供服务时，每个请求都被哪些服务处理？在遇到问题时，在调用哪个服务上发生了问题？在分析性能时，调用各个服务都花了多长时间？哪些调用可以并行执行？…… 为此，分布式服务平台就需要提供这样一种基础服务——可以记录每个请求的调用链；调用链上调用每个服务的时间；各个服务之间的拓扑关系…… 我们把这种行为称为“分布式服务跟踪”。

背景

现今业界分布式服务跟踪的理论基础主要来自于 Google 的一篇论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》，使用最为广泛的开源实现是 Twitter 的 Zipkin，为了实现平台无关、厂商无关的分布式服务跟踪，CNCF 发布了布式服务跟踪标准 Open Tracing。国内，淘宝的“鹰眼”、京东的“Hydra”、大众点评的“CAT”、新浪的“Watchman”、唯品会的“Microscope”、窝窝网的“Tracing”都是这样的系统。

原理

一般的，一个分布式服务跟踪系统，主要有三部分：数据收集、数据存储和数据展示。根据系统大小不同，每一部分的结构又有一定变化。譬如，对于大规模分布式系统，数据存储可分为实时数据和全量数据两部分，实时数据用于故障排查（troubleshooting），全量数据用于系统优化；数据收集除了支持平台无关和开发语言无关系统的数据收集，还包括异步数据收集（需要跟踪队列中的消息，保证调用的连贯性），以及确保更小的侵入性；数据展示又涉及到数据挖掘和分析。虽然每一部分都可能变得很复杂，但基本原理都类似。

服务追踪的追踪单元是从客户发起请求（request）抵达被追踪系统的边界开始，到被追踪系统向客户返回响应（response）为止的过程，称为一个“trace”。每个 trace 中会调用若干个服务，为了记录调用了哪些服务，以及每次调用的消耗时间等信息，在每次调用服务时，埋入一个调用记录，称为一个“span”。这样，若干个有序的 span 就组成了一个 trace。在系统向外界提供服务的过程中，会不断地有请求和响应发生，也就会不断生成 trace，把这些带有span 的 trace 记录下来，就可以描绘出一幅系统的服务拓扑图。附带上 span 中的响应时间，以及请求成功与否等信息，就可以在发生问题的时候，找到异常的服务；根据历史数据，还可以从系统整体层面分析出哪里性能差，定位性能优化的目标。

实现

Spring Cloud 是基于 Java 的分布式服务平台，提供一系列的分布式服务所需的中间件。其中，用于分布式服务跟踪的模块是 Spring Cloud Sleuth。

Spring Cloud Sleuth 主要用于收集 Spring Boot 程序中的数据，即上文所说的数据收集。其包含的 spring-cloud-sleuth-zipkin 模块可以把收集到的数据发送到 zipkin 服务器。Zipkin 本身具有数据存储和展示的功能，这样，我们就可以在 Spring Boot 系统中埋入 Spring Cloud Sleuth 收集数据，在后台使用 Zipkin 服务作为数据存储和展示的服务。

使用 Zipkin 作为后台的另一个好处是，Zipkin 除了支持 Spring Cloud Sleuth 以外，还支持其他开发语言和平台的数据收集器。这使得在系统中让不同种种语言开发的服务可以共存。

首先，我们要搭建一个 Zipkin 的后台服务，然后把我们已有的 Spring Boot 服务中埋入 Spring Cloud Sleuth，最后，将 Spring Cloud Sleuth 接入 Zipkin 服务，一个非常简单的分布式服务跟踪服务就搭建起来了。

搭建 Zipkin 最简单的办法是直接使用 Zipkin 官方的 Docker 镜像。Zipkin 的存储引擎也是可以配置的，启动 Zipkin 时，如果没有配置 Zipkin 的存储引擎，那么默认 Zipkin 把数据存在内存中。这里，由于我们已经有了一个 MySQL 的高可用环境，所以配置 MySQL 为 Zipkin 的存储引擎。

# 下载镜像
docker pull openzipkin/zipkin
# 运行镜像，并指定存储引擎
docker run -d -p 9411:9411 -e MYSQL_USER=root -e MYSQL_PASS=password -e MYSQL_HOST=192.168.0.8 -e STORAGE_TYPE=mysql openzipkin/zipkin

Zipkin 运行起来后，可以通过浏览器访问 9411 端口，确认 Zipkin 的运行状态。

接下来需要改造已有的 Spring Boot 服务。

首先，在 pom.xml 中引入 Spring Cloud Sleuth。因为使 zipkin 模块，所以只引入 spring-cloud-starter-zipkin即可。版本使用 Spring Cloud 统一管理。

<dependencyManagement>
	<dependencies>
		<dependency>
			<groupId>org.springframework.cloud</groupId>
			<artifactId>spring-cloud-dependencies</artifactId>
			<version>Camden.SR5</version>
			<type>pom</type>
			<scope>import</scope>
		</dependency>
	</dependencies>
</dependencyManagement>
...
<dependency>
  <groupId>org.springframework.cloud</groupId>
  <artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>

使用环境变量，或者直接在 application.properties、application.yml或 bootstrap.yml 配置文件中配置必要的属性。

spring.zipkin.baseUrl=http://zipkin.host.com:9411/
spring.sleuth.sampler.percentage=1.0

至此，Spring Boot 程序就可以把访问记录到 Zipkin 服务器中。

有些时候，譬如，访问第三方 API，或者数据库操作等场合，我们也希望在其中添加一些调用信息。那么可以手工插入一些代码来实现（俗称“埋点”）。

首先，在需要添加的类中注入Tracer。

import org.springframework.cloud.sleuth.Span;
import org.springframework.cloud.sleuth.Tracer;
...
@Autowired
private Tracer tracer;

然后，在调用之前，插入代码。

// 创建一个 span
final Span span = tracer.createSpan("3rd_service");
try {
  span.tag(Span.SPAN_LOCAL_COMPONENT_TAG_NAME, "3rd_service");
  span.logEvent(Span.CLIENT_SEND);
  // 这里时调用第三方 API 的代码
} finally {
  ...
}

最后，在调用之后的 finally 中（确保异常后也被调用到），插入代码。

span.tag(Span.SPAN_PEER_SERVICE_TAG_NAME, "3rd_service");
span.logEvent(Span.CLIENT_RECV);
tracer.close(span);

通过埋点我们可以生成任意详细的调用记录，我们就可以看到哪里还欠缺监控，需要手工埋点；哪里调用时间过长，是影响性能的瓶颈；以及哪些调用可以并行，优化性能降低响应时间。