分布式追踪系统zipkin介绍

本文涉及的产品
应用实时监控服务-可观测链路OpenTelemetry版,每月50GB免费额度
简介: 分布式追踪系统zipkin介绍

在前一期我们简单的介绍了作为分布式追踪系统的zipkin,并以一个demo简单演示了zipkin的使用,本文我们来从整体介绍一下zipkin的技术架构,以期能够更好的理解和使用zipkin。

一、理论基础

zipkin的理论基础是Google在2010年发表的论文《Dapper,a Large-Scale Distributed Systems Tracing Infrastructure》,这篇论文的原型是Google开源的Dapper链路追踪组件,这篇文章在业内链路追踪领域可谓是最经典的理论指导了,具有非常大的学习参考意义,建议有时间的朋友可以好好读一读。

基于链路追踪的一些理论基础,市场上出现了很多优秀的链路追踪组件,除了Google Dapper,如本文的主角Twitter Zipkin,阿里的EagleEye,华为(apache)的SkyWalking等。

这些链路追踪组件的出现有一个共同的原因:现代微服务框架的盛行,导致服务件调用问题排查的困难。

二、架构组成

回到本文的主角zipkin,一起来剖析一下zipkin的架构。如下图所示,zipkin包含4个组件,分别负责不同的功能:

网络异常,图片无法展示
|

1、collector

zipkin collector是zipkin的一个常驻进程组件,负责提供对外部的接口用以收集、校验和存储、索引追踪数据。

2、storage

存储模块,真正服务zipkin收集到的追踪数据的存储,zipkin默认存储在内存中,目前主要支持Cassandra、Elasticsearch和MySQL,对于这些存储源的支持都是可插拔的。

3、search

search组件提供的是查询服务,追踪数据被存储和索引以后就需要提供对外的查询服务,zipkin提供的JSON API用于数据检索。

4、web UI

zipkin提供了简洁而又直观的web UI用于进行数据的检索和调用链路展示,可以通过trace ID以及其他的条件来过滤查询,在页面上展示调用链路上各个节点所消耗的时间,方便用于判断性能瓶颈。

以上可以看到,其实zipkin的架构组成是比较简单的,部署亦并不复杂。架构简单、部署方便、存储插拔可选、UI简洁高效,这也是会被广泛应用的原因。

二、数据收集流程

在zipkin中每一次请求链路的追踪都是一个Trace,通过一个trace ID来标志。每个Trace可以拆分为有若干个存在依赖关系的Span,在微服务的架构下,一般请求会涉及到多个服务之间的调用或者是服务与中间件之间的交互,这里的每次请求调用就可以理解为一个Span,因此Span是一个树形的结构,每个Span都记录了相关的信息,使用一个64位的ID对一个Span进行标志。

Span通常包含其他的信息,如时间戳、parent id、annotation等信息。

  • Trace
    Span的集合,表示一次调用链路,使用traceId唯一标志。
  • Annotation
    记录请求特定事件信息,例如记录链路上各节点的时间,一般有以下几个分类:
    1、cs(Client Start):客户端发起了请求
    2、sr(Server Receive):服务端收到了请求
    3、ss(Server Send):服务端返回处理结果给客户端
    4、cr(Client Received):客户端收到服务端的响应

数据来源通常称为reporter,一般来说reporter由应用程序集成zipkin提供的客户端包来实现,数据的发送是轻量和异步的,不会阻塞应用程序的运行,对应用程序的负载很小。

在普通的请求传递时zipkin不会发送独立的请求收集详细的数据,而是在请求头中添加一些参数,例如,下图所示,添加trace请求头:

X-B3-TraceId: aa

X-B3-SpanId: 6b

在最终收到响应之后,异步的发送span详情到zipkin collector,由于是异步的,不会导致原业务代码的延迟。

三、流行的客户端组件

zipkin支持多语言和多场景,官方有很多流行的语言支持,例如:java语言中的brave,JavaScript语言中的zipkin-js。

社区也提供了很多的支持,例如Go语言的go-zipkin,Python语言的py_zipkin,Scala语言的kamon-zipkin等等,zipkin有非常好的社区支持生态。

四、使用brave向zipkin上报数据

业界针对常见的java应用程序框架提供了开源的分布式追踪组件brave,brave提供了面向Standard Servlet、Spring MVC、Http Client、JAX RS、Jersey、MySQL等接口集成能力,通过简单的配置就可以完成向zipkin上报数据的功能,无需对代码有过多的侵入。

同时zipkin提供了扩展的能力,当标准的功能无法满足需要时,可以通过接口进行扩展。

默认情况下,Brave将收集到的数据打印在日志中,当需要向zipkin报告数据时,需要引入zipkin 的Reporter,Reporter会将数据异步发送到zipkin Collector。

五、增加Log4j支持

appender.console.layout.pattern=%d{ABSOLUTE}[%X{traceId}/%X{spanId}] %-5p[%t]%C{2}{%F:%L}-%m%n
LocalSpanAPI.start("localA")'...LocalSpanAPI.finish();


相关实践学习
基于OpenTelemetry构建全链路追踪与监控
本实验将带领您快速上手可观测链路OpenTelemetry版,包括部署并接入多语言应用、体验TraceId自动注入至日志以实现调用链与日志的关联查询、以及切换调用链透传协议以满足全链路打通的需求。
分布式链路追踪Skywalking
Skywalking是一个基于分布式跟踪的应用程序性能监控系统,用于从服务和云原生等基础设施中收集、分析、聚合以及可视化数据,提供了一种简便的方式来清晰地观测分布式系统,具有分布式追踪、性能指标分析、应用和服务依赖分析等功能。 分布式追踪系统发展很快,种类繁多,给我们带来很大的方便。但在数据采集过程中,有时需要侵入用户代码,并且不同系统的 API 并不兼容,这就导致了如果希望切换追踪系统,往往会带来较大改动。OpenTracing为了解决不同的分布式追踪系统 API 不兼容的问题,诞生了 OpenTracing 规范。OpenTracing 是一个轻量级的标准化层,它位于应用程序/类库和追踪或日志分析程序之间。Skywalking基于OpenTracing规范开发,具有性能好,支持多语言探针,无侵入性等优势,可以帮助我们准确快速的定位到线上故障和性能瓶颈。 在本套课程中,我们将全面的讲解Skywalking相关的知识。从APM系统、分布式调用链等基础概念的学习加深对Skywalking的理解,从0开始搭建一套完整的Skywalking环境,学会对各类应用进行监控,学习Skywalking常用插件。Skywalking原理章节中,将会对Skywalking使用的agent探针技术进行深度剖析,除此之外还会对OpenTracing规范作整体上的介绍。通过对本套课程的学习,不止能学会如何使用Skywalking,还将对其底层原理和分布式架构有更深的理解。本课程由黑马程序员提供。
相关文章
|
14天前
|
机器学习/深度学习 存储 运维
分布式机器学习系统:设计原理、优化策略与实践经验
本文详细探讨了分布式机器学习系统的发展现状与挑战,重点分析了数据并行、模型并行等核心训练范式,以及参数服务器、优化器等关键组件的设计与实现。文章还深入讨论了混合精度训练、梯度累积、ZeRO优化器等高级特性,旨在提供一套全面的技术解决方案,以应对超大规模模型训练中的计算、存储及通信挑战。
45 4
|
1月前
|
存储 运维 负载均衡
构建高可用性GraphRAG系统:分布式部署与容错机制
【10月更文挑战第28天】作为一名数据科学家和系统架构师,我在构建和维护大规模分布式系统方面有着丰富的经验。最近,我负责了一个基于GraphRAG(Graph Retrieval-Augmented Generation)模型的项目,该模型用于构建一个高可用性的问答系统。在这个过程中,我深刻体会到分布式部署和容错机制的重要性。本文将详细介绍如何在生产环境中构建一个高可用性的GraphRAG系统,包括分布式部署方案、负载均衡、故障检测与恢复机制等方面的内容。
104 4
构建高可用性GraphRAG系统:分布式部署与容错机制
|
20天前
|
机器学习/深度学习 人工智能 分布式计算
【AI系统】分布式通信与 NVLink
进入大模型时代后,AI的核心转向大模型发展,训练这类模型需克服大量GPU资源及长时间的需求。面对单个GPU内存限制,跨多个GPU的分布式训练成为必要,这涉及到分布式通信和NVLink技术的应用。分布式通信允许多个节点协作完成任务,而NVLink则是一种高速、低延迟的通信技术,用于连接GPU或GPU与其它设备,以实现高性能计算。随着大模型的参数、数据规模扩大及算力需求增长,分布式并行策略,如数据并行和模型并行,变得至关重要。这些策略通过将模型或数据分割在多个GPU上处理,提高了训练效率。此外,NVLink和NVSwitch技术的持续演进,为GPU间的高效通信提供了更强的支持,推动了大模型训练的快
33 0
|
2月前
|
消息中间件 中间件 数据库
NServiceBus:打造企业级服务总线的利器——深度解析这一面向消息中间件如何革新分布式应用开发与提升系统可靠性
【10月更文挑战第9天】NServiceBus 是一个面向消息的中间件,专为构建分布式应用程序设计,特别适用于企业级服务总线(ESB)。它通过消息队列实现服务间的解耦,提高系统的可扩展性和容错性。在 .NET 生态中,NServiceBus 提供了强大的功能,支持多种传输方式如 RabbitMQ 和 Azure Service Bus。通过异步消息传递模式,各组件可以独立运作,即使某部分出现故障也不会影响整体系统。 示例代码展示了如何使用 NServiceBus 发送和接收消息,简化了系统的设计和维护。
59 3
|
2月前
|
存储 开发框架 .NET
C#语言如何搭建分布式文件存储系统
C#语言如何搭建分布式文件存储系统
78 2
|
2月前
|
消息中间件 存储 监控
消息队列系统中的确认机制在分布式系统中如何实现?
消息队列系统中的确认机制在分布式系统中如何实现?
|
2月前
|
存储 分布式计算 监控
C# 创建一个分布式文件存储系统需要怎么设计??
C# 创建一个分布式文件存储系统需要怎么设计??
41 0
|
2月前
|
NoSQL Java Redis
太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?
Redis分布式锁在高并发场景下是重要的技术手段,但其实现过程中常遇到五大深坑:**原子性问题**、**连接耗尽问题**、**锁过期问题**、**锁失效问题**以及**锁分段问题**。这些问题不仅影响系统的稳定性和性能,还可能导致数据不一致。尼恩在实际项目中总结了这些坑,并提供了详细的解决方案,包括使用Lua脚本保证原子性、设置合理的锁过期时间和使用看门狗机制、以及通过锁分段提升性能。这些经验和技巧对面试和实际开发都有很大帮助,值得深入学习和实践。
太惨痛: Redis 分布式锁 5个大坑,又大又深, 如何才能 避开 ?
|
14天前
|
存储 NoSQL Java
使用lock4j-redis-template-spring-boot-starter实现redis分布式锁
通过使用 `lock4j-redis-template-spring-boot-starter`,我们可以轻松实现 Redis 分布式锁,从而解决分布式系统中多个实例并发访问共享资源的问题。合理配置和使用分布式锁,可以有效提高系统的稳定性和数据的一致性。希望本文对你在实际项目中使用 Redis 分布式锁有所帮助。
42 5
|
17天前
|
NoSQL Java 数据处理
基于Redis海量数据场景分布式ID架构实践
【11月更文挑战第30天】在现代分布式系统中,生成全局唯一的ID是一个常见且重要的需求。在微服务架构中,各个服务可能需要生成唯一标识符,如用户ID、订单ID等。传统的自增ID已经无法满足在集群环境下保持唯一性的要求,而分布式ID解决方案能够确保即使在多个实例间也能生成全局唯一的标识符。本文将深入探讨如何利用Redis实现分布式ID生成,并通过Java语言展示多个示例,同时分析每个实践方案的优缺点。
34 8