分布式链路追踪的利器——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做二次开发,提供更为友好的界面。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
thikphp 控制器
控制器定义 类名和文件名一样, 渲染输出 渲染输出使用return输出 <?php namespace app\admin\controller; use app\admin\model\User; class Index { public function Index(){ $data = array( 'ming' => 'ming', 'ming' => 'xiao' ); return json($data); } } 此时页面渲染出json文件 不能在控制器中中断代码。。使用halt输出 <?php namespace app\admin\controller; use app\admin\model\User; class Index { public function Index(){ $data = array( 'ming' => 'ming', 'ming' => 'xiao' ); halt("输出测试"); return json($data); } } 使用halt 输出 多级控制器 多级控制器 多级控制器直接在命名空间中使...
- 下一篇
如何做好性能压测(一)| 压测环境的设计和搭建
性能压测,是保障服务可用性和稳定性过程中,不可或缺的一环,但是有关性能压测的体系化分享并不多。从本期开始,我们将推出《Performance Test Together》(简称PTT)的系列专题分享,从性能压测的设计、实现、执行、监控、问题定位和分析、应用场景等多个纬度对性能压测的全过程进行拆解,以帮助大家构建完整的性能压测的理论体系,并提供有例可依的实战经验。 第一期:《压测环境的设计和搭建》,专题出品人| 阿里巴巴 PTS 团队 一般来说,保证执行性能压测的环境和生产环境高度一致是执行一次有效性能压测的首要原则。有时候,即算是压测环境和生产环境有很细微的差别,都有可能导致整个压测活动评测出来的结果不准确。 性能环境要考虑的要素 1. 系统逻辑架构 系统逻辑架构,即组成系统的组建,应用之间的结构,交互关系的抽象。最简单最基本的就是三层架构
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- CentOS6,CentOS7官方镜像安装Oracle11G
- CentOS关闭SELinux安全模块
- CentOS7设置SWAP分区,小内存服务器的救世主
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- Windows10,CentOS7,CentOS8安装Nodejs环境
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- CentOS7,CentOS8安装Elasticsearch6.8.6
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长