微服务可观测性研究之distributed tracing–1.综述

最近，boss交给了我一个任务，研究下链路追踪，大半年前研究过这个问题，但是当时因为手头上有很多别的工作，加上对scala和play framework框架（我司核心系统采用play框架研发的）不太熟悉，所以这个问题研究了一半没有继续下去了。最近，boss把我从业务系统中解放出来，专门研究比较底层偏架构方面的工作，第一个任务就是继续研究之前暂停的分布式微服务链路追踪。

分布式系统中，微服务的可观测性是很重要的指标之一，在对bug追踪和性能问题定位等方面发挥了不可替代的作用。我司主要是to b 业务，对于客户现场的信息收集极其重要，借助于微服务可观测性技术可以解决这个难题。

可观测性主要分为三个部分：logging，tracing，metrics。本文是可观测性系列文章的第一篇，主要是tracing部分的综述。后续还有对metrics和logging部分的研究。

文章目录

微服务可观测性研究之distributed tracing--1.综述
前言
一、分布式链路追踪是什么？
二、常见方案
- 1. 原理
- 2. OpenTracing
- 3. OpenCensus
- 4. OpenTelemetry
总结
文章参考

前言

链路追踪(Distributed Tracing)　一词最早出现于谷歌发布的论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》中,这篇论文对于实现链路追踪,对于后来出现的 Jaeger、Zipkin 等开源分布式追踪项目设计理念仍有很深的影响。

一、分布式链路追踪是什么？

微服务架构是一个分布式的架构,会有很多个不同的服务。不同的服务之前相互调用,如果出现了错误由于一个请求经过了 N 个服务。随着业务的增加越来越多的服务之间的调用，如果没有一个工具去记录调用链，解决问题的时候会毫无头绪，无从下手。所以需要有一个工具能够清楚的了解一个请求经过了哪些服务,顺序是如何,从而能够轻易的定位问题。

分布式跟踪（也称为分布式请求跟踪）是一种用于分析和监控应用程序的方法，尤其是使用微服务架构构建的应用程序。分布式跟踪有助于精确定位故障发生的位置以及导致性能差的原因。所以是微服务可观测性指标中的重要的一环。

从谷歌发布 Dapper 后，分布式链路追踪工具越来越多，以下简单列举了一些常用的链路追踪系统

Skywalking
阿里鹰眼
大众点评 CAT
Twitter Zipkin
Naver pinpoint
Uber Jaeger

随着链路追踪工具越来越多，开源领域主要分为两派，一派是以 CNCF技术委员会为主的 OpenTracing 的规范，例如 jaeger zipkin 都是遵循了OpenTracing 的规范。而另一派则是谷歌作为发起者的 OpenCensus，而且谷歌本身还是最早提出链路追踪概念的公司，后期连微软也加入了 OpenCensus

从上图可以看出，这两个方案不管是从技术角度思考，还是从用户角度考虑，都半斤八两。技术领域，方案太多会带来很大的成本，那么统一这两个方案就成了迫在眉睫的事情，opentelemetry大一统方案横空出世了。

本文先大概介绍这三个方案。

二、常见方案

1. 原理

数据模型

概述：
链路追踪中的 Trace（调用链）通过归属于此调用链的 Span 来隐性的定义。
特别说明，一条 Trace（调用链）可以被认为是一个由多个 Span 组成的有向无环图（DAG图），Span 与 Span 的关系被命名为 References。

例如：下面的示例 Trace 就是由8个 Span 组成：

有些时候，使用下面这种，基于时间轴的时序图可以更好的展现 Trace（调用链）：

从概述中我们可以看到，一次请求的链路追踪过程，包含了服务 -> 服务、服务 -> 中间件、服务 -> 存储、函数 -> 函数间的完整的调用关系。可以给我们带来直观上的请求过程的详细情况，比如某个服务出现问题，那么整个链路就会断掉、某个服务性能出现性能瓶颈，也会反应在链路的时间线上。这样可以让我们快速定位问题、回溯问题、解决问题。
链路追踪的详细原理在谷歌的论文描述的很详细。本文给出外链，有兴趣的读者可以了解一下详细的原理：原来10张图就可以搞懂分布式链路追踪系统原理

2. OpenTracing

OpenTracing是一种规范，目前已经进入cncf，是cncf第三个项目，第一个是Kubernetes，第二个是Prometheus，可见CNCF对OpenTracing背后可观察性的重视。比如大名鼎鼎的Zipkin、Jaeger都遵循OpenTracing协议。OpenTracing制定了一套平台无关、厂商无关的Trace协议，使得开发人员能够方便的添加或更换分布式追踪系统的实现。 OpenTracing 是一个轻量级的标准化层，它位于应用程序/类库和追踪或日志分析程序之间。

OpenTracing 的优势
OpenTracing 已进入 CNCF，正在为全球的分布式追踪，提供统一的概念和数据标准。
OpenTracing 通过提供平台无关、厂商无关的 API，使得开发人员能够方便的添加（或更换）追踪系统的实现。

3. OpenCensus

大家可能会想，既然有了`OpenTracing`，`OpenCensus`又来凑什么热闹？对不起，你要知道`OpenCensus`的发起者可是谷歌，也就是最早提出Tracing概念的公司，而`OpenCensus`也就是Google Dapper的社区版。OpenCensus和OpenTracing最大的不同在于除了Tracing外，它还把Metrics也包括进来，这样也可以在OpenCensus上做基础的指标监控；还一点不同是OpenCensus并不是单纯的规范制定，他还把包括数据采集的Agent、Collector一股脑都搞了。OpenCensus也有众多的追随者，最近最大的新闻就是微软也宣布加入，OpenCensus可谓是如虎添翼。也就是说，这两者在tracing的原理上是一致的，都是基于谷歌的tracing来实现的，但是，opencensus包含了更多的基本功能，比如metrics，数据采集的模块等。因此，opencensus更像是一种大而全的框架，而opentracing只是定义了一种追踪的规范。

4. OpenTelemetry

有了`OpenTracing`和`OpenCensus`，都各自有优劣，那么统一就势在必行。为此，Opentelemetry 横空出世，它出现的第一宗旨是：兼容OpenTracing和OpenCensus。对于使用OpenTracing或OpenCensus的应用不需要重新改动就可以接入OpenTelemetry。本系列后续会对opentelemetry做详细的介绍，本篇就不详细介绍了。有兴趣的同学可以看后面的文章。

总结

在分布式系统中，微服务的治理是个很重要的研究课题。以我司为例，to b的业务，私有化离线的环境，如果用户在使用系统的过程中出现了任何的问题，如果没有tracing，metrics，logging等当时的现场信息，就很难对问题进行回溯分析。那么引入可观测性系统就显得尤为重要。本系列后续会详细讲解我司在tob场景链路追踪的实践。

文章参考

开放分布式追踪（OpenTracing）入门与 Jaeger 实现

OpenTelemetry-可观察性的新时代