Spring Boot+Spring Cloud基础入门（九）服务链路追踪——Spring Cloud Sleuth

服务链路追踪

---

微服务架构上通过业务来划分服务的，通过REST调用，对外暴露的一个接口，可能需要很多个服务协同才能完成这个接口功能，如果链路上任何一个服务出现问题或者网络超时，都会形成导致接口调用失败。随着业务的不断扩张，服务之间互相调用会越来越复杂。

随着服务的越来越多，对调用链的分析会越来越复杂。它们之间的调用关系也许如下：

关键型术语

• Span：基本工作单元，例如，在一个新建的span中发送一个RPC等同于发送一个回应请求给RPC，span通过一个64位ID唯一标识，trace以另一个64位ID表示，span还有其他数据信息，比如摘要、时间戳事件、关键值注释(tags)、span的ID、以及进度ID(通常是IP地址)
  span在不断的启动和停止，同时记录了时间信息，当你创建了一个span，你必须在未来的某个时刻停止它。
• Trace：一系列spans组成的一个树状结构，例如，如果你正在跑一个分布式大数据工程，你可能需要创建一个trace。
• Annotation：用来及时记录一个事件的存在，一些核心annotations用来定义一个请求的开始和结束
• cs - Client Sent ：客户端发起一个请求，这个annotion描述了这个span的开始
• sr - Server Received ：服务端获得请求并准备开始处理它，如果将其sr减去cs时间戳便可得到网络延迟
• ss - Server Sent ：注解表明请求处理的完成(当请求返回客户端)，如果ss减去sr时间戳便可得到服务端需要的处理请求时间
• cr - Client Received ：表明span的结束，客户端成功接收到服务端的回复，如果cr减去cs时间戳便可得到客户端从服务端获取回复的所有所需时间

将Span和Trace在一个系统中使用Zipkin注解的过程图形化：

以上内容转自：https://blog.youkuaiyun.com/forezp/article/details/70162074

---

Zipkin

Zipkin分布式跟踪系统；它可以帮助收集时间数据，解决在microservice架构下的延迟问题；它管理这些数据的收集和查找；Zipkin的设计是基于谷歌的Google Dapper论文。

每个应用程序向Zipkin报告定时数据，Zipkin UI呈现了一个依赖图表来展示多少跟踪请求经过了每个应用程序；如果想解决延迟问题，可以过滤或者排序所有的跟踪请求，并且可以查看每个跟踪请求占总跟踪时间的百分比。

随着业务越来越复杂，系统也随之进行各种拆分，特别是随着微服务架构和容器技术的兴起，看似简单的一个应用，后台可能有几十个甚至几百个服务在支撑；一个前端的请求可能需要多次的服务调用最后才能完成；当请求变慢或者不可用时，我们无法得知是哪个后台服务引起的，这时就需要解决如何快速定位服务故障点，Zipkin分布式跟踪系统就能很好的解决这样的问题。

---

下载Zipkin

在目前的新版本中，Zipkin已独立成一个jar包，我们只需要下载它（文末有下载链接），用‘java -jar zipkin.jar’命令去运行它就好了，运行成功，我们访问http://localhost:9411/zipkin/ 注意这里最后一定要有‘/’不然会报404，或者你可以直接访问http://localhost:9411 出现如下界面，就表示，你的Zipkin服务启动成功了。

---

创建两个相互调用程序

只有在对外暴露的接口被调用时，Zipkin才会收集数据，这就是为什么叫服务追踪了。
创建两个新Model，我将他们命名为Service-Hey，Service-Hello。两个项目的pom.xml文件的依赖一致，我就只贴出Service-Hey的pom.xml文件了。

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"