首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
V2EX  ›  问与答

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

  •  1
     
  •   getui · 192 天前 · 571 次点击
    这是一个创建于 192 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

    4 回复  |  直到 2019-06-10 20:16:10 +08:00
        1
    fingers   192 天前
    板块都发错了
        2
    FingerLiu   191 天前
    板块都发错了
        3
    getui   181 天前
    @fingers 谢谢提醒,已改
        4
    getui   181 天前
    @FingerLiu 谢谢提醒,已改
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   817 人在线   最高记录 5043   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 21ms · UTC 20:08 · PVG 04:08 · LAX 12:08 · JFK 15:08
    ♥ Do have faith in what you're doing.