转载

32、Spring Cloud 服务跟踪总结

上两篇讲解了zipkin，这篇总结一下。其实Spring Cloud实施分布式跟踪解决方案所用的技术不仅仅是zipkin。在spring官网：

http://spring.io/projects/spr...

有这么一段话：

翻译过来：

Spring Cloud Sleuth是Spring Cloud实施分布式跟踪解决方案，大量借用Dapper，Zipkin和HTrace。对于大多数用户来说，侦探应该是隐形的，并且所有与外部系统的交互都应该自动进行检测。您可以简单地在日志中捕获数据，也可以将数据发送到远程收集器服务。

Spring Cloud Sleuth借用了Dapper的术语：

跨度（Span）：基本的工作单位。例如，发送一个RPC是一个新的跨度，就像向RPC发送响应一样。跨度由跨度的唯一64位ID和跨度所包含的另一个 64位ID标识。Spans还具有其他数据，例如描述，时间戳事件，键值注释（标记），导致它们的跨度的ID以及进程ID（通常为IP地址）。跨度启动和停止，并跟踪他们的时间信息。一旦你创建了一个跨度，你必须在将来某个时候停止它。开始追踪的初始跨度被称为 root span。该跨度的span id的值等于trace id。

痕迹（Trace）：一组形成树状结构的跨度。例如，如果您正在运行分布式大数据存储，则跟踪可能由放入请求组成。

标注（Annotation）：用于及时记录事件的存在。用于定义请求开始和结束的一些核心注释是：

cs - 客户端发送 - 客户端发出请求。这个注释描述了跨度的开始。

sr - 服务器已收到 - 服务器端收到请求并开始处理。如果从这个时间戳中减去cs时间戳，将会收到网络延迟。

ss - 服务器发送 - 在请求处理完成时（当响应被发送回客户端时）注释。如果从这个时间戳中减去sr时间戳，将会收到服务器端处理请求所需的时间。

cr - 客户端收到 - 表示跨度结束。客户端已经成功接收到服务器端的响应。如果从这个时间戳中减去cs时间戳，那么将会收到客户端接收服务器响应所需的全部时间。

Span和Trace在系统中与Zipkin Annotation一起显示的可视化示例：

（ https://github.com/spring-clo... ）

32、Spring Cloud 服务跟踪总结

1、依赖说明

从中央仓库 https://mvnrepository.com可以... ：spring-cloud-starter-zipkin、spring-cloud-starter-sleuth、spring-cloud-sleuth-zipkin，他们只有有什么关系呢？

32、Spring Cloud 服务跟踪总结

从pom.xml的引用关系可以看到spring-cloud-starter-zipkin包含了spring-cloud-starter-sleuth和spring-cloud-sleuth-zipkin，就是所引入spring-cloud-starter-zipkin就等于引用了spring-cloud-starter-sleuth和spring-cloud-sleuth-zipkin

2、配置说明

Zipkin和Sleuth配置类分别是：

Zipkin： org.springframework.cloud.sleuth.zipkin2.ZipkinProperties

Sleuth： org.springframework.cloud.sleuth.autoconfig.SleuthProperties

从这两个类就可以知道Zipkin和Sleuth分别有哪些配置项

3、分布式服务跟踪系统原理

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

阿里云的一些服务可以类比，比如你需要收集一台云主机的IO情况，CPU使用率、磁盘使用情况等；就需要在我们的云主机安装一个代理agent（类比Zipkin Client），这个代理agent的作用就是收集当前主机的数据，然后上送到管理控制台（类比Zipkin Server）

原文 https://segmentfault.com/a/1190000022463140

正文到此结束