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

标签: zipkin 分布 实践 | 发表时间:2019-05-30 19:18 | 作者:jack
出处:https://www.diycode.cc/


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

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做二次开发,提供更为友好的界面。

相关 [zipkin 分布 实践] 推荐:

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

- - DiyCode - 致力于构建开发工程师高端交流分享社区社区
作者:个推应用平台基础架构高级研发工程师 阿飞. 随着微服务架构的流行,系统变得越来越复杂,单体的系统被拆成很多个模块,各个模块通过轻量级的通信协议进行通讯,相互协作,共同实现系统功能. 单体架构时,一个请求的调用链路很清晰,一般由负载均衡器将用户请求转发到后端服务,由后端服务进行业务处理,需要的数据从外部的存储中获取,处理完请求后,再经由负载均衡器返回给用户.

分布式链路追踪系统 Zipkin 埋点库 Brave 使用入门

- - 叉叉哥的BLOG
微服务架构下,服务之间的关系错综复杂. 从调用一个 HTTP API 到最终返回结果,中间可能发生了多个服务间的调用. 而这些被调用的服务,可能部署在不同的服务器上,由不同的团队开发,甚至可能使用了不同的编程语言. 在这样的环境中,排查性能问题或者定位故障就很麻烦. Zipkin 是一个分布式链路追踪系统(distributed tracing system).

分布式计算开源框架Hadoop入门实践

- - ITeye博客
一、分布式计算开源框架Hadoop实践. 在 SIP项目设计的过程中,对于它庞大的日志在开始时就考虑使用任务分解的多线程处理模式来分析统计,在我从前写的文章《Tiger Concurrent Practice --日志分析并行分解设计与实现》中有所提到. 但是由于统计的内容暂时还是十分简单,所以就采用Memcache作为计数器,结合MySQL就完成了访问 控制以及统计的工作.

分布式会话跟踪系统架构设计与实践

- - 美团点评技术团队
本文整理自美团点评技术沙龙第08期:大规模集群的服务治理设计与实践. 美团点评技术沙龙由美团点评技术团队主办,每月一期. 每期沙龙邀请美团点评及其它互联网公司的技术专家分享来自一线的实践经验,覆盖各主要技术领域. 目前沙龙会分别在北京、上海和厦门等地举行,要参加下一次最新沙龙活动. 赶快关注微信公众号“美团点评技术团队”.

分布式开放消息系统(RocketMQ)的原理与实践

- - 编程语言 - ITeye博客
备注:1.如果您此前未接触过RocketMQ,请先阅读附录部分,以便了解RocketMQ的整体架构和相关术语2.文中的MQServer与Broker表示同一概念.   分布式消息系统作为实现分布式系统可扩展、可伸缩性的关键组件,需要具有高吞吐量、高可用等特点. 而谈到消息系统的设计,就回避不了两个问题:  .

分布式事务框架seata落地实践

- - 有道技术沙龙博客
seata是阿里巴巴研发的一套开源分布式事务框架,提供了AT、TCC、SAGA 和 XA 几种事务模式. 本文以精品课项目组的物流后台服务为例,介绍seata框架落地的过程,遇到的问题以及解决方案. 有道精品课教务系统是基于springcloud的分布式集群服务. 在实际业务中,存在许多分布式事务场景.

《分布式Java应用:基础与实践》的封面和目录

- 亦农 - BlueDavy之技术blog
第1章 分布式Java应用. 1.1 基于消息方式实现系统间的通信. 1.1.1 基于Java自身技术实现消息方式的系统间通信. 1.1.2 基于开源框架实现消息方式的系统间通信. 1.2 基于远程调用方式实现系统间的通信. 1.2.1 基于Java自身技术实现远程调用方式的系统间通信.

网易分布式数据库多活架构的演进与实践

- -
大家好,今天给大家分享一些网易近几年在数据库多活方向上的工作. 我将简单介绍下为什么我们要做数据库多活,再从三个阶段介绍网易在数据库多活上做的工作. 数据库多活的目标包括“容灾”和“提升处理能力”两方面. 容灾可以简单理解为当系统由于外部或内部原因出现部分不可用时,仍然能在短时间内恢复可用. 而容灾最常用的手段即是备份,在数据库领域不仅需要对计算能力做备份也要对数据做备份.

分布式大数据多维分析(OLAP)引擎:Apache Kylin 在百度地图的实践

- - leejun2005的个人页面
百度地图开放平台业务部数据智能组主要负责百度地图内部相关业务的大数据计算分析,处理日常百亿级规模数据,为不同业务提供单条SQL毫秒级响应的OLAP多维分析查询服务. 对于Apache Kylin在实际生产环境中的应用,在国内,百度地图数据智能组是最早的一批实践者之一. Apache Kylin在2014年11月开源,当时,我们团队正需要搭建一套完整的大数据OLAP分析计算平台,用来提供百亿行级数据单条SQL毫秒到秒级的多维分析查询服务,在技术选型过程中,我们参考了Apache Drill、Presto、Impala、Spark SQL、Apache Kylin等.

微博广告 Hubble 系统:秒级大规模分布式智能监控平台架构实践

- - IT瘾-dev
关键词:微博广告 Hubble 监控平台 D+ 大数据 机器学习 LSTM Tensorflow. Hubble(哈勃,其含义是数据如浩瀚宇宙之大,Hubble 如太空望远镜,能窥见璀璨的星辰,发现数据的真正价值)平台定位为 微博广告智能全景监控、数据透视和商业洞察. 计算广告系统是集智能流量分发、投放、结算、CTR 预估、客户关系管理等为一体的大型互联网业务系统.