Zipkin分布式任务追踪

zipkin简介

　　Zipkin 是一款开源的分布式实时数据追踪系统，由基于 Google Dapper 的论文设计而来，由 Twitter 公司提供开源实现，主要功能是聚集来自各个异构系统的实时监控数据，和微服务架构下的接口直接的调用链路和系统延时问题。

　　Zipkin 提供了自己的UI，应用将自己的监控数据报告给zipkin，由Zipkin 汇集并提供关联图展示，Zipkin可以追踪请求调用链路。Zipkin 以 Trace 的结构表示一次请求的追踪，又把每个Trace拆分为若干个有依赖关系的 Span，在微服务架构中，一次用户的请求可能会被后台的若干个服务处理，这完整的一次用户请求可以一条调用链路Trace，每个调用处理请求的服务可以理解为一个Span(如API服务)，这个服务也可能继续调用其他的服务，因此形成一个Span的树形结构，以体现服务间的调用关系。

　　Zipkin 的用户界面除了可以查看 Span 的依赖关系之外，还以瀑布图的形式显示了每个 Span 的耗时情况，可以一目了然的看到各个服务的性能状况。打开每个 Span，还有更详细的数据以键值对的形式呈现，而且这些数据可以在装备应用的时候自行添加。
　　spring Cloud Sleuth是对Zipkin的一个封装，对于Span、Trace等信息的生成、接入HTTP Request，以及向Zipkin Server发送采集信息等全部自动完成。

Spring Cloud Sleuth的简介
　　以下是Spring Cloud Sleuth的概念图

　　在Spring Cloud Sleuth的封装中，Zipkin分为两端，一个是Zipkin服务端，一个是Zipkin客户端，客户端也就是微服务的应用,客户端会配置服务端的url地址，一旦发生服务间的调用的时候，会被配置在微服务里面的Sleuth的监听器监听，并生成相应的 Trace 和 Span 信息写进http报文头里面，并同时向Zipkin服务端上传这些信息，如图所示。

　　主要方式有两种，一种是消息总线的方式如RabbitMq发送，还有一种是http报文的方式发送，向 Zipkin 服务端发送gzip的数据包，服务端接收到gzip的数据包进行解析，根据每个调用链路汇总成调用链路的信息，这里注意，每个 Zipkin Client 里面如果设置了登录验证，并不会影响Zipkin Server的信息收集，因为 Client 端会自动上传gzip的数据包给 Server 端，而无需 Server 端去调用 Client 端的接口去统计信息，Client 端在生成 Trace 统计信息的同时，如果配置了 MDC 或者在 logback 日志中集成了日志收集工具 logstash，则可以在 Client 端的控制台读到这些 Trace 和 Span 的信息，对每个 Span 的信息都会有对应的 Annotation 进行声明。

Span 的 Annotation 信息
这些 Annotation 分为四种类型：
1. cs : Client Sent，这个标识着 Span的开始。
2. sr : Server Received，这个标识着服务端接收到客户端发送请求的信息。Sleuth还可以根据 cs 和 sr 的时间戳来计算服务调用的延时。
3. ss : Server Sent，这个标识表示服务端接收到客户端后要返回 response 信息。
4. cr : Client Received，这个标识表示客户端收到服务端返回的 response 信息。

这几个注解反应了一次完整的服务间调用的信息，这些注解结合 Span id 信息可以从不同的应用汇总成调用链路的 Trace 信息，也就是说一次 Trace 的信息如果经过了 A 应用、B 应用，那么 Sleuth 会从 A 应用汇总对B应用调用产生的注解信息 Client Sent 和 Client Received，再从 B 应用汇总对 A 应用调用产生的 Server Received 和 Server Sent，A 应用根据自己调用信息组装成 Span 和携带相应的 Annotation 以gzip包的方式通过http发送给 Zipkin Server，B 应用像 A 应用一样也会组装这些信息给 Zipkin Server，Zipkin Server会根据 A 应用和 B 应用的信息汇总成统计信息展示在 Zipkin UI上。

Span的生命周期
1. start：开始对Span命名和记录开始时间戳
2. close：结束时记录结束时间戳并检查属性 exportable 然后汇总给 Zipkin，然后移除出当前的线程。
3. continue：为 Span 新建实例并拷贝继续进行的 Span
4. detach：Span 没有 stop 或者 close，仅仅是移出当前的线程。
5. create with explicit parent：在另外的一个线程重新创建一个 Span 并且明确它的 parent。

Span 的存储方式
在 Zipkin Server里面有很多种存储方式，但是比较主流的有这两种：
1. 放在内存中存储。
2. 放在mysql中存储。
放在内存中的随着服务端的启动会出清空历史数据，如果想持久化保留这些数据，可以选择 mysql 的方式存储。
mysql配置方式参考：Stack Overflow 网友提供的参考方案
mysql 配置后有两个表，如图

Zipkin分布式任务追踪相关推荐

部署Zipkin分布式性能追踪日志系统的操作记录
Zipkin是Twitter的一个开源项目,是一个致力于收集Twitter所有服务的监控数据的分布式跟踪系统,它提供了收集数据,和查询数据两大接口服务. 部署Zipkin环境的操作记录: 部署Zipk ...
想了解Sleuth+zipkin分布式请求链路追踪，来看看这篇文章吧！
目录下载zipkin的jar包,运行微服务配置引入pom yml配置访问结果: 在微服务框架中,一个由客户端发起的请求在后端系统中会经过多个不同的服务节点调用来协同产生最后的请求结果,每一个前 ...
SpringBoot+SpringSecurity+JWT实现认证和授权
SprinBoot 系列文章: Spring Boot入门之Hello Spring Boot SpringBoot 配置多个JdbcTemplate SpringBoot 整合Mybatis CAS ...
Spring Cloud 分布式链路跟踪 Sleuth + Zipkin + Elasticsearch
2019独角兽企业重金招聘Python工程师标准>>> 随着业务越来越复杂,系统也随之进行各种拆分,特别是随着微服务架构的兴起,看似一个简单的应用,后台可能很多服务在支撑:一个请求可 ...
【Spring Cloud Alibaba 温故而知新】（五）SpringCloud Sleuth + Zipkin：分布式日志追踪
目录 8.1.1 SpringCloud Sleuth 是什么 SpringCloud Sleuth 必知必会 SpringCloud Sleuth 实现的功能是:它会自动为当前应用构建起各通信通道的 ...
微服务治理之分布式链路追踪--3.zipkin实战
微服务治理之分布式链路追踪–3.zipkin实战本节是基于zipkin分布式追踪系统搭建,因为对 scala 和 play framework 2 框架不熟悉,所以,没有采用opentelemetr ...
Spring微服务实战第9章使用Spring Cloud Sleuth和Zipkin进行分布式跟踪
文章目录第9章使用Spring Cloud Sleuth和Zipkin进行分布式跟踪 9.1 Spring Cloud Sleuth与关联ID 9.1.1 将Spring Cloud Sleuth ...
java B2B2C 多租户电子商城系统-Spring Cloud Zipkin
Zipkin是什么 Zipkin分布式跟踪系统:它可以帮助收集时间数据,解决在microservice架构下的延迟问题:它管理这些数据的收集和查找:Zipkin的设计是基于谷歌的Google Dapp ...
链路追踪之zipkin
微服务架构是一个分布式架构,它按业务划分服务单元,一个分布式系统往往有很多个服务单元.由于服务单元数量众多,业务的复杂性,如果出现了错误和异常,很难去定位.主要体现在,一个请求可能需要调用很多个服务, ...

Zipkin分布式任务追踪

Zipkin分布式任务追踪相关推荐

最新文章

热门文章