微服务架构的链路追踪和故障快速排查zipkin(微服务治理)

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
云原生网关 MSE Higress,422元/月
注册配置 MSE Nacos/ZooKeeper,118元/月
简介:

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 配置后有两个表,如图














本文转自wks9751CTO博客,原文链接:http://blog.51cto.com/wks97/2074615 ,如需转载请自行联系原作者



相关实践学习
基于OpenTelemetry构建全链路追踪与监控
本实验将带领您快速上手可观测链路OpenTelemetry版,包括部署并接入多语言应用、体验TraceId自动注入至日志以实现调用链与日志的关联查询、以及切换调用链透传协议以满足全链路打通的需求。
分布式链路追踪Skywalking
Skywalking是一个基于分布式跟踪的应用程序性能监控系统,用于从服务和云原生等基础设施中收集、分析、聚合以及可视化数据,提供了一种简便的方式来清晰地观测分布式系统,具有分布式追踪、性能指标分析、应用和服务依赖分析等功能。 分布式追踪系统发展很快,种类繁多,给我们带来很大的方便。但在数据采集过程中,有时需要侵入用户代码,并且不同系统的 API 并不兼容,这就导致了如果希望切换追踪系统,往往会带来较大改动。OpenTracing为了解决不同的分布式追踪系统 API 不兼容的问题,诞生了 OpenTracing 规范。OpenTracing 是一个轻量级的标准化层,它位于应用程序/类库和追踪或日志分析程序之间。Skywalking基于OpenTracing规范开发,具有性能好,支持多语言探针,无侵入性等优势,可以帮助我们准确快速的定位到线上故障和性能瓶颈。 在本套课程中,我们将全面的讲解Skywalking相关的知识。从APM系统、分布式调用链等基础概念的学习加深对Skywalking的理解,从0开始搭建一套完整的Skywalking环境,学会对各类应用进行监控,学习Skywalking常用插件。Skywalking原理章节中,将会对Skywalking使用的agent探针技术进行深度剖析,除此之外还会对OpenTracing规范作整体上的介绍。通过对本套课程的学习,不止能学会如何使用Skywalking,还将对其底层原理和分布式架构有更深的理解。本课程由黑马程序员提供。
相关文章
|
13天前
|
缓存 负载均衡 JavaScript
探索微服务架构下的API网关模式
【10月更文挑战第37天】在微服务架构的海洋中,API网关犹如一座灯塔,指引着服务的航向。它不仅是客户端请求的集散地,更是后端微服务的守门人。本文将深入探讨API网关的设计哲学、核心功能以及它在微服务生态中扮演的角色,同时通过实际代码示例,揭示如何实现一个高效、可靠的API网关。
|
12天前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
16天前
|
设计模式 Java API
微服务架构演变与架构设计深度解析
【11月更文挑战第14天】在当今的IT行业中,微服务架构已经成为构建大型、复杂系统的重要范式。本文将从微服务架构的背景、业务场景、功能点、底层原理、实战、设计模式等多个方面进行深度解析,并结合京东电商的案例,探讨微服务架构在实际应用中的实施与效果。
65 6
|
16天前
|
设计模式 Java API
微服务架构演变与架构设计深度解析
【11月更文挑战第14天】在当今的IT行业中,微服务架构已经成为构建大型、复杂系统的重要范式。本文将从微服务架构的背景、业务场景、功能点、底层原理、实战、设计模式等多个方面进行深度解析,并结合京东电商的案例,探讨微服务架构在实际应用中的实施与效果。
30 1
|
15天前
|
大数据
【赵渝强老师】大数据主从架构的单点故障
大数据体系架构中,核心组件采用主从架构,存在单点故障问题。为提高系统可用性,需实现高可用(HA)架构,通常借助ZooKeeper来实现。ZooKeeper提供配置维护、分布式同步等功能,确保集群稳定运行。下图展示了基于ZooKeeper的HDFS HA架构。
|
12天前
|
存储 JSON 监控
微服务链路追踪原理,一文搞懂!
本文重点讲解微服务链路追踪(Microservices Distributed Tracing),介绍其原理、架构及工作流程。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
微服务链路追踪原理,一文搞懂!
|
12天前
|
Dubbo Java 应用服务中间件
服务架构的演进:从单体到微服务的探索之旅
随着企业业务的不断拓展和复杂度的提升,对软件系统架构的要求也日益严苛。传统的架构模式在应对现代业务场景时逐渐暴露出诸多局限性,于是服务架构开启了持续演变之路。从单体架构的简易便捷,到分布式架构的模块化解耦,再到微服务架构的精细化管理,企业对技术的选择变得至关重要,尤其是 Spring Cloud 和 Dubbo 等微服务技术的对比和应用,直接影响着项目的成败。 本篇文章会从服务架构的演进开始分析,探索从单体项目到微服务项目的演变过程。然后也会对目前常见的微服务技术进行对比,找到目前市面上所常用的技术给大家进行讲解。
29 1
服务架构的演进:从单体到微服务的探索之旅
|
10天前
|
消息中间件 监控 安全
后端架构演进:从单体到微服务####
在数字化转型的浪潮中,企业应用的后端架构经历了从传统单体架构到现代微服务架构的深刻变革。本文探讨了这一演进过程的背景、驱动力、关键技术及面临的挑战,揭示了如何通过微服务化实现系统的高可用性、扩展性和敏捷开发,同时指出了转型过程中需克服的服务拆分、数据管理、通信机制等难题,为读者提供了一个全面理解后端架构演变路径的视角。 ####
27 8
|
11天前
|
Cloud Native 安全 API
云原生架构下的微服务治理策略与实践####
—透过云原生的棱镜,探索微服务架构下的挑战与应对之道 本文旨在探讨云原生环境下,微服务架构所面临的关键挑战及有效的治理策略。随着云计算技术的深入发展,越来越多的企业选择采用云原生架构来构建和部署其应用程序,以期获得更高的灵活性、可扩展性和效率。然而,微服务架构的复杂性也带来了服务发现、负载均衡、故障恢复等一系列治理难题。本文将深入分析这些问题,并提出一套基于云原生技术栈的微服务治理框架,包括服务网格的应用、API网关的集成、以及动态配置管理等关键方面,旨在为企业实现高效、稳定的微服务架构提供参考路径。 ####
37 5
|
14天前
|
监控 API 微服务
后端技术演进:从单体架构到微服务的转变
随着互联网应用的快速增长和用户需求的不断演化,传统单体架构已难以满足现代软件开发的需求。本文深入探讨了后端技术在面对复杂系统挑战时的演进路径,重点分析了从单体架构向微服务架构转变的过程、原因及优势。通过对比分析,揭示了微服务架构如何提高系统的可扩展性、灵活性和维护效率,同时指出了实施微服务时面临的挑战和最佳实践。
35 7
下一篇
无影云桌面