背景

微服务架构是一个分布式架构，它按业务划分服务单元，一个分布式系统往往有很多个服务单元。由于服务单元数量众多，业务的复杂性，如果出现了错误和异常，很难去定位。主要体现在，一个请求可能需要调用很多个服务，而内部服务的调用复杂性，决定了问题难以定位。

所以微服务架构中，必须实现分布式链路追踪，去跟进一个请求到底有哪些服务参与，参与的顺序又是怎样的，从而达到每个请求的步骤清晰可见，出了问题，很快定位。

它可以在复杂的服务调用中定位问题，还可以在新人加入后台团队之后，让其清楚地知道自己所负责的服务在哪一环。

除此之外，如果某个接口突然耗时增加，也不必再逐个服务查询耗时情况，我们可以直观地分析出服务的性能瓶颈，方便在流量激增的情况下精准合理地扩容。

技术选型

框架 SkyWalking Zipkin Jaeger
开发团队 华为 社区 Uber
OpenTracing 支持 支持 支持
语言支持 Java、NET Core、NodeJS 、PHP Go，Java，Ruby，C++，Python（Progress） Python，Go，Node，Java，C++，C#，PHP，Ruby
存储 ES、H2、Mysql、TIDB、Sharding sphere 内存、Cassandra、Elasticsearch 内存、Cassandra、Elasticsearch
Span 传输 gRPC HTTP，KAFKA UTP，HTTP
易用性 简单易接入 少数语言支持差，如Python 接入简单，各种语言SDK丰富
业务代码侵入性 低 中 中

由于SkyWalking主要是Java社区的中间件，首先淘汰。Jaeger出现的更晚，更新，有动态采样的机制较Zipkin更先进，动态采样0.1表示10条链路概率上只采一条数据上报，因此优先选用Jaeger。

概念梳理

  1. Tracing: 一整条链路叫tracing,一个tracing跨多个服务进程，里面会包含一个唯一requestid。会跨越多个SPAN。

  2. SPAN,在一个Tracing中的每一次RPC调用称为SPAN。包括进程内部的需要追踪调用和跨进程的RPC，进程内部的调用最终使用Context(Golang),跨进程的SPAN通过HTTP head信息串联到一个Tracing。

基于Jaeger原理架构图

jaeger原理架构图

整个系统由以下几个中间件构成：

Component Description
Jaeger Client Jaeger Client SDK
Jaeger Agent 负责和客户端通信，收集 Client 数据
Jaeger Collector 收集 Jaeger Agent 数据进行聚合汇总，有 pull/push 两种方式
DB Storage Collector 需要存储后端，Collector 拿到的数据将存在 Elasticsearch 或 Cassandra。
Spark jobs 用于生成拓扑图 UI 数据
Jaeger Query Service & UI 负责从 Storage 查询数据并提供 API 和 UI

应用

基于go-zero框架和其他框架分别实现了jaeger的demo，链接如下：https://github.com/OverCookkk/go_jaeger_demo