作者: 个推应用平台基础架构高级研发工程师 阿飞
01 业务背景
随着微服务架构的流行, 系统变得越来越复杂, 单体的系统被拆成很多个模块, 各个模块通过轻量级的通信协议进行通讯, 相互协作, 共同实现系统功能.
单体架构时, 一个请求的调用链路很清晰, 一般由负载均衡器将用户请求转发到后端服务, 由后端服务进行业务处理, 需要的数据从外部的存储中获取, 处理完请求后, 再经由负载均衡器返回给用户.
而在微服务架构中, 一个请求往往需要多个模块共同协作处理, 不同模块可能还依赖于不同的外部存储, 各个模块的实现技术还不尽相同, 一个请求是如何在整个系统不同模块间进行流转, 整个调用链上的各个模块之间的调用关系如何, 每个微服务处理的时间长短, 处理的结果是否正确, 很难去进行追踪, 而这些信息对于整个系统运维, 性能分析, 故障追踪都特别有帮助, 也正因为此, 才有了各种分布式链路追踪的技术.
02 分布式链路追踪现状
分布式链路追踪的技术有很多, 有开源的也有闭源的. 开源的有 Jaeger,PinPoint,Zipkin,SkyWalking,CAT 等, 闭源的有 Google Dapper, 淘宝的鹰眼 Tracing, 新浪的 Watchman, 美团的 MTrace 等. CNCF(Cloud Native Computing Foundation)为了解决业界分布式追踪系统跨平台兼容性问题, 设计了 trace 的标准, 提出了分布式跟踪系统产品的统一范式 - OpenTracing,Zipkin 也部分支持 OpenTracing 标准.
03 选择 Zipkin 的原因
在实践的过程中, 基于以下原因选择了 Zipkin 来进行链路追踪:
? 开源, 社区活跃
? 支持多种语言, Node.JS,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 做二次开发, 提供更为友好的界面.
来源: http://www.bubuko.com/infodetail-3077554.html