个推基于 Zipkin 的分布式链路追踪实践


作者:个推应用平台基础架构高级研发工程师 阿飞

01业务背景

随着微服务架构的流行,系统变得越来越复杂,单体的系统被拆成很多个模块,各个模块通过轻量级的通信协议进行通讯,相互协作,共同实现系统功能。

单体架构时,一个请求的调用链路很清晰,一般由负载均衡器将用户请求转发到后端服务,由后端服务进行业务处理,需要的数据从外部的存储中获取,处理完请求后,再经由负载均衡器返回给用户。

而在微服务架构中,一个请求往往需要多个模块共同协作处理,不同模块可能还依赖于不同的外部存储,各个模块的实现技术还不尽相同,一个请求是如何在整个系统不同模块间进行流转,整个调用链上的各个模块之间的调用关系如何,每个微服务处理的时间长短,处理的结果是否正确,很难去进行追踪,而这些信息对于整个系统运维、性能分析、故障追踪都特别有帮助,也正因为此,才有了各种分布式链路追踪的技术。

02分布式链路追踪现状

分布式链路追踪的技术有很多,有开源的也有闭源的。开源的有Jaeger、PinPoint、Zipkin、SkyWalking、CAT等,闭源的有Google Dapper、淘宝的鹰眼Tracing、新浪的Watchman、美团的MTrace等。CNCF(Cloud Native Computing Foundation)为了解决业界分布式追踪系统跨平台兼容性问题,设计了trace的标准,提出了分布式跟踪系统产品的统一范式-OpenTracing,Zipkin也部分支持OpenTracing标准。

03选择Zipkin的原因

在实践的过程中,基于以下原因选择了Zipkin来进行链路追踪:
? 开源,社区活跃
? 支持多种语言,Nodejs,Lua,Java都有开源实现,而我们的服务主要是这三种语言实现的
? 提供查询API,方便二次开发

04Zipkin的架构介绍

Zipkin的整体架构如下图所示:


Zipkin的整体架构
(引用自Zipkin官网:https://zipkin.io/pages/architecture.html

其中:
? Instrumented client和Instrumented server需要集成在分布式系统的具体服务中,采集跟踪信息,调用Transport,把跟踪信息发送给Zipkin的Server。
? Transport是Zipkin对外提供的接口,支持HTTP、Kafka、Scribe等通信方式。
? Zipkin即Zipkin server,主要包括四个模块:
Collector: 用于接收各个应用服务传输的追踪信息;
Storage:Zipkin的后端存储,支持In-Memory、MySql、Elasticsearch和Cassandra;
API:提供对外的查询接口;
UI:提供对外的Web界面。

Http Tracing的时序图
(引用自Zipkin官网:https://zipkin.io/pages/architecture.html

以上是Http Tracing的时序图,用户的请求/foo首先被Trace Instrumentationlan拦截,记录下Tags,时间戳,同时在Header里增加Trace信息,然后再流转到后端服务进行处理,处理完成后,正常响应,Trace Instrumentationlan拦截响应,记录处理延时后,将Response正常返回给调用方,同时异步地将Trace的Span发送给Zipkin Server。Span中的traceId是在整个调用链路上唯一的ID,用于唯一标识一条调用链。

05个推的Zipkin实践

个推的微服务是基于Kubernetes和Docker进行部署的,每个微服务对应于Kubernetes中的一组Pod。

在整个微服务体系中,API网关是基于Openresty开发的,主要使用Lua进行开发;后端服务主要使用Node.js和Java进行开发实现。在对接Zipkin时,不同的微服务采用不同的方式进行实现。

API网关主要通过增加网关插件(主要参考了Kong的Zipkin插件实现)来实现与Zipkin的对接;Node.js实现的服务主要使用了中间件实现与Zipkin的对接;Java服务使用了spring-cloud-sleuth来与Zipkin对接。 整体的架构如下图所示:

个推基于Zipkin的分布式链路追踪系统的整体架构

其中,Zipkin也容器化部署在Kubernetes集群中,简化了Zipkin的搭建和部署。如下图所示,通过Zipkin可以很方便地追踪请求的调用链路,整个调用链上各个服务的处理耗时,响应状态,服务间的调用关系都可以方便地在Zipkin中进行查询。Zipkin对于分析整个系统的性能瓶颈,定位故障也都有很大的帮助。

Zipkin的Web界面

06总结

Zipkin作为一个分布式链路追踪系统,有着应用侵入较小、社区活跃度较高、支持多种语言等优势,一般基于开源的实现稍做修改就可以实现与Zipkin的对接。因此个推在微服务架构中也引入了Zipkin,用Zipkin来追踪微服务的调用关系,对微服务进行性能分析和故障诊断。未来,个推会基于Zipkin做二次开发,提供更为友好的界面。

原文地址:https://blog.51cto.com/13031991/2402914

时间: 2024-10-12 12:33:07

个推基于 Zipkin 的分布式链路追踪实践的相关文章

Laravel + go-micro + grpc 实践基于 Zipkin 的分布式链路追踪系统 摘自https://mp.weixin.qq.com/s/JkLMNabnYbod-b4syMB3Hw?

分布式调用链跟踪系统,属于监控系统的一类.系统架构逐步演进时,后期形态往往是一个平台由很多不同的服务.组件构成,用户请求过来后,可能会经过其中多个服务,如图 不过,出问题时往往很难排查,如整个请求变慢.偶尔报错.不可用等,我们很难得知具体是由哪一个或哪些服务引起的,通常开发同学都会互相甩锅,最后不得不花大量时间人肉 tracing 项目初期时,可以简单处理,通过生成唯一 request_id ,在各个方法记录日志,方便排查问题.中后期系统拆分为各个子服务时,要么继续推进原有的 request_i

基于zipkin分布式链路追踪系统预研第一篇

分布式服务追踪系统起源于Google的论文“Dapper, a Large-Scale Distributed Systems Tracing Infrastructure”(译文可参考此处),Twitter的zipkin是基于此论文上线较早的分布式链路追踪系统了,而且由于开源快速被各社区所研究,也诞生了很多的版本. 在这里也是对zipkin进行研究,先贴出Twitter zipkin结构图. 结构比较简单,大概流程为: Trace数据的收集至Scribe(Facebook开源的日志传输通路)或

zipkin分布式链路追踪系统

基于zipkin分布式链路追踪系统预研第一篇 分布式服务追踪系统起源于Google的论文“Dapper, a Large-Scale Distributed Systems Tracing Infrastructure”(译文可参考此处),Twitter的zipkin是基于此论文上线较早的分布式链路追踪系统了,而且由于开源快速被各社区所研究,也诞生了很多的版本. 在这里也是对zipkin进行研究,先贴出Twitter zipkin结构图. 结构比较简单,大概流程为: Trace数据的收集至Scr

分布式链路追踪系统预研第二篇

本文为博主原创文章,未经博主允许不得转载. 在上篇随笔后,分布式链路在缓慢推进.一直没什么兴致写,zipkin使用elasticsearch作为数据完全是可行的.但是揉合这两者,就存在两种方案: 第一种,保持zipkin,替换掉存储.即保持zipkin架构,替换掉默认数据存储,改用elasticsearch作为存储.这完全是可行的,但是做出来的也仅仅是一个分布式链路追踪系统.zipkin官方有相应的多数据源的实现源码,有兴趣大家可以自行去git上看. 由于我们想要的不只是分布式链路追踪系统,我们

聊聊分布式链路追踪

原文链接:http://lidawn.github.io/2018/12/26/distribute-tracing/ 起因 最近一直在做分布式链路追踪的调研和实践,整理一下其中的知识点. 什么是链路追踪 分布式系统变得日趋复杂,越来越多的组件开始走向分布式化,如微服务.分布式数据库.分布式缓存等,使得后台服务构成了一种复杂的分布式网络.在服务能力提升的同时,复杂的网络结构也使问题定位更加困难.在一个请求在经过诸多服务过程中,出现了某一个调用失败的情况,查询具体的异常由哪一个服务引起的就变得十分

跟我学SpringCloud | 第十一篇:使用Spring Cloud Sleuth和Zipkin进行分布式链路跟踪

SpringCloud系列教程 | 第十一篇:使用Spring Cloud Sleuth和Zipkin进行分布式链路跟踪 Springboot: 2.1.6.RELEASE SpringCloud: Greenwich.SR1 如无特殊说明,本系列教程全采用以上版本 在分布式服务架构中,需要对分布式服务进行治理--在分布式服务协同向用户提供服务时,每个请求都被哪些服务处理?在遇到问题时,在调用哪个服务上发生了问题?在分析性能时,调用各个服务都花了多长时间?哪些调用可以并行执行?-- 为此,分布式

spring cloud 入门系列八:使用spring cloud sleuth整合zipkin进行服务链路追踪

好久没有写博客了,主要是最近有些忙,今天忙里偷闲来一篇. =======我是华丽的分割线========== 微服务架构是一种分布式架构,微服务系统按照业务划分服务单元,一个微服务往往会有很多个服务单元,一个请求往往会有很多个单元参与,一旦请求出现异常,想要去定位问题点真心不容易,因此需要有个东西去跟踪请求链路,记录一个请求都调用了哪些服务单元,调用顺序是怎么样的以及在各个服务单元处理的时间长短.常见的服务链路追踪组件有google的dapper.twitter的zipkin.阿里的鹰眼等,它们

分布式链路追踪(Sleuth、Zipkin)

技术背景 在微服务架构中,随着业务发展,系统拆分导致系统调用链路愈发复杂,一个看似简单的前端请求可能最终需要调用很多次后端服务才能完成,那么当整个请求出现问题时,我们很难得知到底是哪个服务出了问题导致的,这时就需要解决一个问题,如何快速定位服务故障点,于是,分布式系统调用链追踪技术就此诞生了. ZipKin Zipkin 是一个由Twitter公司提供并开放源代码分布式的跟踪系统,它可以帮助收集服务的时间数据,以解决微服务架构中的延迟问题,包括数据的收集.存储.查找和展现. 每个服务向zipki

基于 SkyWalking 实现服务链路追踪

SkyWalking简介 SkyWalking是一个开源的观测平台,用于从服务和云原生等基础设施中收集.分析.聚合以及可视化数据.SkyWalking 提供了一种简便的方式来清晰地观测分布式系统,甚至可以观测横跨不同云的系统.SkyWalking 更像是一种现代的应用程序性能监控(Application Performance Monitoring,即APM)工具,专为云原生,基于容器以及分布式系统而设计 SkyWalking 在逻辑上分为四部分:探针.平台后端.存储和用户界面.其架构图如下: