摘要：分布式链路追踪现状分布式链路追踪的技术有很多，有开源的也有闭源的。个推的实践个推的微服务是基于和进行部署的，每个微服务对应于中的一组。整体的架构如下图所示个推基于的分布式链路追踪系统的整体架构其中，也容器化部署在集群中，简化了的搭建和部署。
作者：个推应用平台基础架构高级研发工程师 阿飞
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/archi...）
其中：
• 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/archi...）
以上是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://www.ucloud.cn/yun/104272.html
摘要：一方面，网关是个推微服务体系对外的唯一入口另一方面，网关中实现了很多后端服务的共性需求，避免了重复建设。个推微服务网关的设计与实现个推微服务主要是基于和进行实践的。下图是个推微服务体系的架构图。 作者：个推应用平台基础架构高级研发工程师 阿飞 在微服务架构中，不同的微服务可以有不同的网络地址，各个微服务之间通过互相调用完成用户请求，客户端可能通过调用N个微服务的接口完成一个用户请求。因...
摘要：个推针对服务场景，基于和搭建了微服务框架，提高了开发效率。三容器化在微服务落地实践时我们选择了，下面将详细介绍个推基于的实践。 2016年伊始Docker无比兴盛，如今Kubernetes万人瞩目。在这个无比需要创新与速度的时代，由容器、微服务、DevOps构成的云原生席卷整个IT界。个推针对Web服务场景，基于OpenResty和Node.js搭建了微服务框架，提高了开发效率。在微服...
摘要：个推针对服务场景，基于和搭建了微服务框架，提高了开发效率。三容器化在微服务落地实践时我们选择了，下面将详细介绍个推基于的实践。 2016年伊始Docker无比兴盛，如今Kubernetes万人瞩目。在这个无比需要创新与速度的时代，由容器、微服务、DevOps构成的云原生席卷整个IT界。个推针对Web服务场景，基于OpenResty和Node.js搭建了微服务框架，提高了开发效率。在微服...
摘要：一个客户端请求从发出到被响应经历了哪些组件哪些微服务请求总时长每个组件所花时长等信息我们有必要了解和收集，以帮助我们定位性能瓶颈进行性能调优，因此监控整个微服务架构的调用链十分有必要，本文将阐述如何使用搭建微服务调用链追踪中心。 showImg(https://segmentfault.com/img/remote/1460000014553707); 概述 一个完整的微服务系统包含...
摘要：服务提供者提供一个接口，服务消费者通过消费服务。服务提供者服务提供者，对外提供一个，并向服务注册中心注册，这部分内容，不再讲述，见源码。 微服务架构是一个分布式架构，微服务系统按业务划分服务单元，一个微服务系统往往有很多个服务单元。由于服务单元数量众多，业务的复杂性较高，如果出现了错误和异常，很难去定位。主要体现在一个请求可能需要调用很多个服务，而内部服务的调用复杂性决定了问题难以定位...
阅读 2686·2021-11-24 09:39
阅读 990·2021-11-02 14:38
阅读 3812·2021-09-10 11:26
阅读 2595·2021-08-25 09:40
阅读 2149·2019-08-30 15:54
阅读 358·2019-08-30 10:56
阅读 2504·2019-08-26 12:14
阅读 3057·2019-08-26 12:13
