zipkin链路追踪_分布式链路追踪方案

背景

为了应对各种复杂的业务，特别是疫情爆发以来，音视频需求裂变式的剧增，企业服务(SaaS+PaaS)开始采用敏捷开发、持续集成等开发方式。系统架构也从单机大型软件演化成微服务架构。微服务构建在不同的软件集上，这些软件模块可能是由不同团队开发的，可能使用不同的编程语言来实现，还可能发布在多台服务器上。因此，如果一个服务出现问题，可能导致几十个应用都出现服务异常。

分布式追踪系统可以记录请求范围内的信息，例如一次远程方法调用的执行过程和耗时，是我们排查系统问题和系统性能的重要工具。

本文框架概览

1、OpenTracing语义标准介绍 2、调用链(Trace) 3、追踪系统原理架构图(基于推特开源组件Zipkin) 4、分布式链路追踪方案两种方案介绍

01 — OpenTracing语义标准介绍

OpenTracing是一个跨编程语言的标准。通过提供平台无关、厂商无关的API，使得开发人员能够方便的添加(或更换)追踪系统的实现。OpenTracing正在为全球的分布式追踪，提供统一的概念和数据标准。

02 — 调用链(Trace)

在广义上，一个调用链代表一个事务或者流程在(分布式)系统中的执行过程。在 OpenTracing 标准中，调用链(Trace)是多个 Span 组成的一个有向无环图(Directed Acyclic Graph，简称 DAG)，每一个 Span 代表调用链中被命名并计时的连续性执行片段。

下图是一个分布式调用的例子：客户端发起请求，请求首先到达负载均衡器，接着经过认证服务、计费服务，然后请求资源，最后返回结果。

03 — 追踪系统原理架构图(基于推特开源组件Zipkin)

  Zipkin 是一款开源的分布式实时数据追踪系统(Distributed Tracking System)，由 Twitter 公司开发和贡献。其主要功能是聚合来自各个异构系统的实时监控数据，每个服务向zipkin报告计时数据，zipkin会根据调用关系通过Zipkin UI生成依赖关系图。           

  例子：

1、一个来自用户的请求，请求先达到前端A(如前端界面)，然后通过远程调用，达到系统的中间件B、C(如负载均衡、网关等)，最后达到后端服务D、E，后端经过一系列的业务逻辑计算最后将数据返回给用户。对于这样一个请求，经历了这么多个服务，怎么样将它的请求过程的数据记录下来呢？这就需要用到服务链路追踪。

基本原理是在服务调用的请求和响应中加入ID，标明上下游请求的关系。利用这些信息，可以可视化地分析服务调用链路和服务间的依赖关系。

有4个组件组成：

   - collector：   一旦跟踪数据到达Zipkin collector守护进程，它将被验证，存储和索引，以供Zipkin收集器查找

    - storage：    默认的存储方式为in-memory，除Cassandra之外，还支持ElasticSearch和MySQL

     - search： 一旦数据被存储和索引，我们需要一种方法来提取它。查询守护进程提供了一个简单的JSON API来查找和检索跟踪，主要给Web UI使用

    - web UI： 创建了一个GUI，为查看痕迹提供了一个很好的界面；Web UI提供了一种基于服务，时间和注释查看跟踪的方法。

04 — 分布式链路追踪方案两种方案介绍

  (1)、采用阿里云日志服务

     直接把埋点日志发送到阿里云日志上报接口，后面的分析、可视化统统交给阿里云来实现，这是相对快速接入的方案。

   (2)、自己搭建跟踪分析平台

  自建需要解决上面阿里云干的所有活，相对时间成本较大，接入成本较高。

方案对比

     (1)、使用阿里云分布式请求跟踪分析服务

           1、只需要把业务程序埋点日志发送到指定日志收集接口

           2、不用关心数据分析和存储

           3、提供请求链路查询和指标分析、报警

           4、服务只需支付日志存储费用成本，没有日志不收费

     (2)、自建系统

           1、需要搭建日志收集和存储服务集群

           2、根据需要可能需要数据分析资源、报警

           3、使用成本、维护成本较高

---

公众号：PM天秤座的楼外楼

行业：B端产品经理(SaaS+PaaS)

兴趣爱好：喜欢摄影和户外溜达，跑马溜溜户外领队一枚，从你的全世界路过，然后，陪你路过全世界；

【产品专题】产品运营的点点滴滴

【产品研发的爱恨情仇】

【旅游专题】陪你路过全世界