六、链路跟踪：Sleuth和Zipkin

微服务结构是一个分布式架构，微服务系统按照业务划分服务单元，一个微服务系统往往有很多个服务单元。由于服务单元数量众多，服务单元之间的调用很复杂，一旦出现错误和异常，很难去定位。所以在微服务架构中必须实现分布式服务链路追踪。目前，常见的链路追踪组件有Google的Dapper，Twitter的Zipkin，以及阿里的Eagleeye（鹰眼）等，它们都是非常优秀的链路追踪开源组件。

应用场景：一个网页request了一个应用M，花费了多少时间，请求的IP是多少，请求的网络开销是多少。应用M执行时间是多久，是否执行成功，然后到下一步，A，B，C，D四个应用本次执行的时间是多久，有没有超时，调用了多少次DB，返回了什么内容，每次调用花费了多少时间。

1.1 Spring Cloud Sleuth

一般的，一个分布式服务跟踪系统主要由三部分构成：
1. 数据收集
2. 数据存储
3. 数据展示

1.1.1 基本术语

1. SPAN：基本工作单元，例如，在一个新建的SPAN中发送一个RPC等同于发送一个回应请求给RPC，SPAN通过一个64位ID唯一标识，TRACE以另一个64位ID表示，SPAN还有其他数据信息，比如摘要、时间戳事件、关键值注释(TAGS)、SPAN的ID、以及进度ID(通常是IP地址)
2. TRACE：由一系列SPAN 组成的，呈树状结构。假如请求一个微服务系统的API接口，这个API接口需要调用多个微服务单元，调用每个微服务单元都会产生一个新的SPAN， 所有由这个请求产生的SPAN组成了这个TRACE 。
3. ANNOTATION：用来及时记录一个事件的存在，一些核心ANNOTATIONS用来定义一个请求的开始和结束。
    - CS-CLIENT SENT -客户端发起一个请求，这个ANNOTION描述了这个SPAN的开始。
	- SR-SERVER RECEIVED -服务端获得请求并准备开始处理它，如果将其SR减去CS时间戳便可得到网络延迟。
	- SS-SERVER SENT -注解表明请求处理的完成(当请求返回客户端)，如果SS减去SR时间戳便可得到服务端需要的处理请求时间。
	- CR-CLIENT RECEIVED -表明SPAN的结束，客户端成功接收到服务端的回复，如果CR减去CS时间戳便可得到客户端从服务端获取回复的所有所需时间。

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

1.1.3 Spring Cloud Sleuth的用途
Spring Cloud Sleuth 为服务之间调用提供链路追踪。通过 Sleuth 可以很清楚的了解到一个服务请求经过了哪些服务，每个服务处理花费了多长。从而让我们可以很方便的理清各微服务间的调用关系。此外 Sleuth 可以帮助我们：

1. 耗时分析：通过 Sleuth 可以很方便的了解到每个采样请求的耗时，从而分析出哪些服务调用比较耗时；
2. 可视化错误：对于程序未捕捉的异常，可以通过集成 Zipkin 服务界面上看到；
3. 链路优化：对于调用比较频繁的服务，可以针对这些服务实施一些优化措施。

1.2 Zipkin

Zipkin 是 Twitter 的一个开源项目，它基于 Google Dapper 实现，它致力于收集服务的定时数据，以解决微服务架构中的延迟问题，包括数据的收集、存储、查找和展现。
我们可以使用它来收集各个服务器上请求链路的跟踪数据，并通过它提供的 REST API 接口来辅助我们查询跟踪数据以实现对分布式系统的监控程序，从而及时地发现系统中出现的延迟升高问题并找出系统性能瓶颈的根源。除了面向开发的 API 接口之外，它也提供了方便的 UI 组件来帮助我们直观的搜索跟踪信息和分析请求链路明细，比如：可以查询某段时间内各用户请求的处理时间等。

Zipkin 提供了可插拔数据存储方式：In-Memory、MySql、Cassandra 以及 Elasticsearch。生产上推荐使用Elasticsearch。

1.2.1 核心组件
它主要由 4 个核心组件构成：

1. Collector：收集器组件，它主要用于处理从外部系统发送过来的跟踪信息，将这些信息转换为 Zipkin 内部处理的 Span 格式，以支持后续的存储、分析、展示等功能。
2. Storage：存储组件，它主要对处理收集器接收到的跟踪信息，默认会将这些信息存储在内存中，我们也可以修改此存储策略，通过使用其他存储组件将跟踪信息存储到数据库中。
3. RESTful API：API 组件，它主要用来提供外部访问接口。比如给客户端展示跟踪信息，或是外接系统访问以实现监控等。
4. Web UI：UI 组件，基于 API 组件实现的上层应用。通过 UI 组件用户可以方便而有直观地查询和分析跟踪信息。

1.3 Spring Cloud Sleuth 结合 Zipkin
Spring Cloud Sleuth 可以结合 Zipkin，将信息发送到 Zipkin，利用 Zipkin 的存储来存储信息，利用 Zipkin UI 来展示数据，从而完成从数据收集，到数据存储，最后到数据展示的三部曲。