1. 什么是调用链
一个业务功能可能需要多个服务协作才能实现，一个请求到达服务A，服务A需要依赖服务B，服务B又依赖服务C，甚至C仍需依赖其他服务，形成一个调用链条，即调用链。
2. 为什么要监控调用链
上图传递了一个信息，就是微服务的复杂性
- 出现问题后，定位困难，需要对整个调用链路有个完善的监控
- 链路复杂，需要清晰的链路图谱反映服务之间的依赖、调用关系
- 整体系统性能及运行情况，需要明确的体现，才能根据实际情况调整资源
3. 要监控哪些方面
- 图形化展示整个调用链路
- 系统的性能指标
- 健康状况
- 基础告警
4. 调用链监控的基础原理
在介绍调用链监控工具之前，我们首先需要知道在微服务架构系统中经常会遇到两个问题：
- 跨微服务的API调用发生异常，要求快速定位（比如5分钟以内）出问题出在哪里，该怎么办？
- 跨微服务的API调用发生性 能瓶颈，要求迅速定位（比如5分钟以内）出系统瓶颈，该怎么办？
一般来说要解决这两个问题或者与之类似的问题，就需要用到调用链监控工具。那么调用链监控工具是怎么实现问题的快速定位的呢？这就需要我们理解调用链监控的基础实现原理，我们来看一张图：
图中有两个微服务分别是内容中心和用户中心，其中内容中心的/shares/1接口会调用用户中心的/users/1接口，这里就产生了一个调用链。我们可以将调用的过程分为四个阶段或者说状态，当内容中心发送调用请求时处于“client send”状态，用户中心接收到调用请求时处于“server receive”状态，用户中心处理完请求并返回结果时处于“server send”状态，最后内容中心接收到响应结果时处于“client receive”状态。
假设，调用链流转每个状态时都会向一张数据表里插入一些数据，如下图所示：
表字段说明：
- id：自增id
- span_id：唯一id
- pspan_id：父级span_id
- service_name：服务名称
- api：api路径
- stage：阶段/状态
- timestamp：插入数据时的时间戳
这是一张典型的自表一对多的表结构，根据这张表的数据，就可以实现对以上所提到的两个问题进行快速定位。首先对于第一个问题，可以通过查询表内的数据行数，判断调用链在哪个阶段中断了。例如表中只有uuid1和uuid2两条数据，就可以判断出是user-center的接口出现了问题，没有正常返回结果。再如表中只有uuid1、uuid2及uuid3这三条数据，就可以判断出content-center没有正常接收到user-center返回的结果，以此类推。如此一来，就可以通过表中的数据快速定位出跨微服务的API调用是在哪个阶段发生了异常。
对于第二个问题，可以通过计算timestamp分析哪个调用比较耗时。例如上图中的t2 - t1可以得出请求的发送到请求的接收所消耗的时间，再如t3 - t2可以得出/users/1这个接口的调用耗时，而t4 - t1则可以得出整个调用链的耗时，以此类推。所以当跨微服务的API调用发生性能瓶颈时，就可以通过分析各个调用接口的耗时，快速定位出是哪个微服务接口拖慢了整个调用链耗时。
以上举例简述了实现调用链监控的基础原理，虽然未必所有的调用链监控工具都是这么实现的，但基本都异曲同工，或在其之上进行了一些拓展。所以只要理解了这一部分，在学习各种调用链监控工具时就会比较快上手。
5. Spring Cloud Sleuth简介
Spring Cloud Sleuth实现了一种分布式的服务链路跟踪解决方案，通过使用Sleuth可以让我们快速定位某个服务的问题。简单来说，Sleuth相当于调用链监控工具的客户端，集成在各个微服务上，负责产生调用链监控数据。
官方文档地址如下：
一些概念：
Span（跨度）：Span是基本的工作单元。Span包括一个64位的唯一ID，一个64位trace码，描述信息，时间戳事件，key-value 注解(tags)，span处理者的ID（通常为IP）。
最开始的初始Span称为根span，此span中span id和 trace id值相同。Trance（跟踪）：包含一系列的span，它们组成了一个树型结构
-
Annotation（标注）：用于及时记录存在的事件。常用的Annotation如下：
- CS（Client Sent 客户端发送）：客户端发送一个请求，表示span的开始
- SR（Server Received 服务端接收）：服务端接收请求并开始处理它。(SR - CS)等于网络的延迟
- SS（Server Sent 服务端发送）：服务端处理请求完成，开始返回结束给服务端。(SR - SS)表示服务端处理请求的时间
- CR（Client Received 客户端接收）：客户端完成接受返回结果，此时span结束。(CR - CS)表示客户端接收服务端数据的时间
如果一个服务的调用关系如下：
那么此时将Span和Trace在一个系统中使用Zipkin注解的过程图形化如下：
每个颜色的表明一个span(总计7个spans，从A到G)，每个span有类似的信息
Trace Id = X
Span Id = D
Client Sent
此span表示span的Trance Id是X，Span Id是D，同时它发送一个Client Sent事件
spans 的parent/child关系图形化如下：
6. 整合Spring Cloud Sleuth
了解完基本的一些概念后，我们来在订单服务和商品服务中，集成spring cloud sleuth以及zipkin。在两个服务的pom.xml文件中，增加如下依赖：
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>
为了更详细的查看服务通信时的日志信息，我们可以将Feign和Sleuth的日志级别设置为debug。在两个项目的配置文件中，加入如下内容即可：
logging:
level:
org.springframework.cloud.openfeign: debug
org.springframework.cloud.sleuth: debug
启动订单、商品服务项目，然后访问创建订单的接口，订单服务的控制台会输出一段这样的信息：
[order,6c8ecdeefb0fc723,cc4109a6e8e56d1c,false]
商品服务的控制台也会输出类似的信息，如下：
[product,6c8ecdeefb0fc723,40cdc34e745d59e7,false]
说明：
- product： 看也知道是服务名称
- 6c8ecdeefb0fc723： 是TranceId，一条链路中，只有一个TranceId
- 40cdc34e745d59e7：则是spanId，链路中的基本工作单元id
- false：表示是否将数据输出到其他服务，true则会把信息输出到其他可视化的服务上观察
7. Zipkin搭建与整合
通过Sleuth产生的调用链监控信息，让我们可以得知微服务之间的调用链路，但是监控信息只输出到控制台始终不太方便查看。所以我们需要一个图形化的工具，这时候就轮到zipkin出场了。
Zipkin是一款开源的分布式实时数据追踪系统（Distributed Tracking System），基于 Google Dapper的论文设计而来，由 Twitter 公司开发贡献。其主要功能是聚集来自各个异构系统的实时监控数据。分布式跟踪系统还有其他比较成熟的实现，例如：Naver的Pinpoint、Apache的HTrace、阿里的鹰眼Tracing、京东的Hydra、新浪的Watchman，美团点评的CAT，skywalking等。
zipkin官网地址如下：
ZipKin可以分为两部分，一部分是zipkin server，用来作为数据的采集存储、数据分析与展示；zipkin client是zipkin基于不同的语言及框架封装的一些列客户端工具，这些工具完成了追踪数据的生成与上报功能，架构如下：
Zipkin Server主要包括四个模块：
（1）Collector 接收或收集各应用传输的数据
（2）Storage 存储接受或收集过来的数据，当前支持Memory，MySQL，Cassandra，ElasticSearch等，默认存储在内存中。
（3）API（Query） 负责查询Storage中存储的数据，提供简单的JSON API获取数据，主要提供给web UI使用
（4）Web 提供简单的web界面
ZipKin几个概念
在追踪日志中，有几个基本概念spanId、traceId、parentId
- traceId：用来确定一个追踪链的16字符长度的字符串，在某个追踪链中保持不变。
- spanId：区域Id，在一个追踪链中spanId可能存在多个，每个spanId用于表明在某个服务中的身份，也是16字符长度的字符串。
- parentId：在跨服务调用者的spanId会传递给被调用者，被调用者会将调用者的spanId作为自己的parentId，然后自己再生成spanId。
如下图：
刚发起调用时traceId和spanId是一致，parentId不存在。
被调用者的traceId和调用者的traceId时一致的，被调用者会产生自己的spanId，并且被调用者的parentId是调用者的spanId
接下来我们搭建一个zipkin服务器。
方式1，使用Zipkin官方的Shell下载，使用如下命令可下载最新版本：
[root@01server ~]# curl -sSL https://zipkin.io/quickstart.sh | bash -s
下载下来的文件名为 zipkin.jar
方式2，到Maven中央仓库下载，使用浏览器访问如下地址即可：
https://search.maven.org/remote_content?g=io.zipkin.java&a=zipkin-server&v=LATEST&c=exec
下载下来的文件名为 zipkin-server-{版本号}-exec.jar
由于Zipkin实际是一个Spring Boot项目，所以使用以上两种方式下载的jar包，可以直接使用如下命令启动：
java jar {zipkin jar包路径}
方式3，通过docker安装，命令如下：
[root@01server ~]# docker run -d -p 9411:9411 openzipkin/zipkin
安装好后，使用浏览器访问9411端口，主页面如下所示：
然后在订单服务中将之前的sleuth依赖替换成如下依赖：
<!-- 这个依赖包含了sleuth和zipkin -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>
在配置文件中，增加zipkin相关的配置项。如下：
spring:
...
zipkin:
base-url: http://127.0.0.1:9411/ # zipkin服务器的地址
# 关闭服务发现，否则Spring Cloud会把zipkin的url当做服务名称
discoveryClientEnabled: false
sender:
type: web # 设置使用http的方式传输数据
sleuth:
sampler:
probability: 1 # 设置抽样采集率为100%，默认为0.1，即10%
配置好后重启项目，并访问创建订单接口。下单成功后，到zipkin页面上就可以查看到order服务的链路信息了：
会有红色的信息表示有错误，点击上图中的红色信息后，可以进入到服务链路的查看页面，在这里可以看到整条服务链路，并且可以看到每一个服务调用的耗时，也可以看到是哪一步调用发生了错误：
点击每一行信息都可以查看其详情信息，例如我点击耗时46.236ms的那行信息，其详细信息如下：
8. Zipkin数据持久化
Zipkin默认是将监控数据存储在内存的，如果Zipkin挂掉或重启的话，那么监控数据就会丢失。所以如果想要搭建生产可用的Zipkin，就需要实现监控数据的持久化。而想要实现数据持久化，自然就是得将数据存储至数据库。好在Zipkin支持将数据存储至：
- 内存（默认）
- MySQL
- Elasticsearch
- Cassandra
Zipkin数据持久化相关的官方文档地址如下：
Zipkin支持的这几种存储方式中，内存显然是不适用于生产的，这一点开始也说了。而使用MySQL的话，当数据量大时，查询较为缓慢，也不建议使用。Twitter官方使用的是Cassandra作为Zipkin的存储数据库，但国内大规模用Cassandra的公司较少，而且Cassandra相关文档也不多。
综上，故采用Elasticsearch是个比较好的选择，关于使用Elasticsearch作为Zipkin的存储数据库的官方文档如下：
既然选择Elasticsearch作为Zipkin的存储数据库，那么自然首先需要搭建一个Elasticsearch服务，单节点搭建比较简单，直接到官网下载压缩包，然后使用如下命令解压并启动即可（关于ES的版本选择需参考官方文档，目前Zipkin支持5.x、6.x及7.x）：
[root@01server ~]# tar -zxvf elasticsearch-6.5.3-linux-x86_64.tar.gz # 解压
[root@01server ~]# cd elasticsearch-6.5.3/bin
[root@01server ~/elasticsearch-6.5.3/bin]# ./elasticsearch # 启动
由于Elasticsearch不是本文的重点，这里不做不多的介绍，关于Elasticsearch的集群搭建可以参考如下文章：
- 使用docker安装elasticsearch伪分布式集群以及安装ik中文分词插件
- 搭建ELK日志分析平台（上）—— ELK介绍及搭建 Elasticsearch 分布式集群
- CentOS7 下安装 ElasticSearch 5.x 及填坑
搭建好Elasticsearch后，使用如下命令启动Zipkin，Zipkin就会切换存储类型为Elasticsearch，然后根据指定的连接地址连接Elasticsearch并存储数据：
STORAGE_TYPE=elasticsearch ES_HOSTS=localhost:9200 java -jar zipkin-server-2.11.3-exec.jar
Tips：
-
其中，
STORAGE_TYPE和ES_HOSTS是环境变量，STORAGE_TYPE用于指定Zipkin的存储类型是啥；而ES_HOSTS则用于指定Elasticsearch地址列表，有多个节点时使用逗号（ , ）分隔。
除此之外，还可以指定其他环境变量，参考下表：image
关于其他环境变量，可参考官方文档：
最后可以根据以下测试步骤，自行测试一下Zipkin是否能正常将监控数据持久化存储：
- 往Zipkin中存储一些数据
- 停止Zipkin
- 再次启动Zipkin，查看之前存储的数据是否存在，如果存在说明数据已被持久化
关于依赖关系图的问题
在上一小节中，简单介绍了Zipkin的数据持久化，并整合了Elasticsearch作为Zipkin的存储数据库。但此时会有一个问题，就是Zipkin在整合Elasticsearch后会无法分析服务之间的依赖关系图，因为此时数据都存储到Elasticsearch中了，无法再像之前那样在内存中进行分析。
想要解决这个问题，需要下载并使用Zipkin的一个子项目：
方式1，使用官方的Shell下载，使用如下命令可下载最新版本：
[root@01server ~]# curl -sSL https://zipkin.io/quickstart.sh | bash -s io.zipkin.dependencies:zipkin-dependencies:LATEST zipkin-dependencies.jar
下载下来的文件名为 zipkin-dependencies.jar
方式2，到Maven中央仓库下载，使用浏览器访问如下地址即可：
https://search.maven.org/remote_content?g=io.zipkin.dependencies&a=zipkin-dependencies&v=LATEST
下载下来的文件名为 zipkin-dependencies-{版本号}.jar
下载好后，使用如下命令运行这个jar包即可分析Elasticsearch中存储的数据：
[root@01server ~]# STORAGE_TYPE=elasticsearch ES_HOSTS=localhost:9200 java -jar zipkin-dependencies-2.3.2.jar
该jar包运行结束后，到Zipkin的界面上点开“Dependencies”就可以正常查看到依赖关系图了。
方式3，通过docker下载并运行，命令如下：
[root@01server ~]# docker run --env STORAGE_TYPE=elasticsearch --env ES_HOSTS=192.168.190.129:9200 openzipkin/zipkin-dependencies
Tips：
这个Zipkin Dependencies属于是一个job，不是服务，即不会持续运行，而是每运行一次才分析数据。若想持续运行的话，需要自己写个定时脚本来定时运行这个job
使用Elasticsearch时Zipkin Dependencies支持的环境变量：
Zipkin Dependencies支持的其他环境变量：
Zipkin Dependencies默认分析的是当天的数据，可以通过如下命令让Zipkin Dependencies分析指定日期的数据：
