分布式追踪（Distributed Tracing）：Jaeger, Zipkin 的应用 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

好的，各位朋友，欢迎来到今天的“分布式追踪：Jaeger, Zipkin 的应用”脱口秀！我是你们的老朋友，程序界的段子手，今天就带大家一起扒一扒这俩分布式追踪界的“扛把子”——Jaeger 和 Zipkin，看看它们是如何在微服务这片汪洋大海中，帮我们精准定位“沉船”的。🌊

别担心，今天咱们不讲枯燥的理论，就聊聊实际应用，保证大家听完能笑着回去，还能顺手解决几个线上 Bug！😎

开场白：微服务时代的烦恼

话说，自从我们拥抱了微服务架构，系统变得像一棵枝繁叶茂的大树，每个枝干都是一个独立的服务。这棵树茁壮成长，功能越来越强大，但问题也随之而来：

调用链太长： 一个请求可能要经过十几个甚至几十个服务，哪个环节出了问题，简直像大海捞针！
性能瓶颈难寻： 系统响应慢，到底是哪个服务拖了后腿？CPU 飙升？数据库慢查询？傻傻分不清楚！
问题排查困难： 线上出现 Bug，日志散落在各个服务里，要拼凑出一个完整的请求链路，简直比福尔摩斯破案还难！🤯

面对这些问题，我们程序员只能默默流泪，加班到天亮，头发掉了一把又一把。难道就没有什么神器，能帮我们摆脱这种困境吗？

救星登场：分布式追踪

别绝望，少年！分布式追踪技术就是来拯救我们的！它就像一个“请求追踪器”，能记录下每个请求在各个服务之间的流转路径、耗时，以及各种关键信息，最终汇聚成一张清晰的“调用链地图”。有了这张地图，我们就能：

快速定位问题： 哪个服务响应慢，一目了然！
分析性能瓶颈： 找出耗时最长的环节，针对性优化！
还原请求链路： 追踪请求的完整路径，轻松排查 Bug！

简单来说，分布式追踪就像给每个请求都装上了一个 GPS，无论它跑到哪里，我们都能精准定位！🛰️

主角亮相：Jaeger vs. Zipkin

在分布式追踪领域，Jaeger 和 Zipkin 绝对是两位“大佬”。它们都是开源的分布式追踪系统，功能强大，社区活跃，深受广大程序员的喜爱。那么，它们之间有什么区别呢？我们来简单对比一下：

特性	Jaeger	Zipkin
出身	Uber 出品，根正苗红！	Twitter 出品，血统纯正！
架构	采用 gRPC 作为内部通信协议，性能更高。	采用 Thrift 作为内部通信协议，相对成熟。
存储	支持 Cassandra, Elasticsearch, Kafka, Memory 等多种存储方式，灵活性更高。	支持 Cassandra, Elasticsearch, MySQL, PostgreSQL 等多种存储方式，选择丰富。
采样	支持多种采样策略，包括概率采样、速率限制采样、自适应采样等，可以根据实际情况灵活配置。	支持概率采样、速率限制采样等，相对简单。
UI	UI 界面简洁美观，功能强大，支持链路分析、服务依赖关系分析、性能分析等。	UI 界面相对简单，但功能也足够使用。
适用场景	适合对性能要求较高，需要灵活采样策略，以及需要深度链路分析的场景。	适合对性能要求不高，需要快速搭建，以及对 UI 界面要求不高的场景。
总结	Jaeger 就像一位“高富帅”，性能好，功能强，但配置也相对复杂。	Zipkin 就像一位“经济适用男”，够用就好，配置简单，容易上手。

总的来说，Jaeger 更适合大型、复杂的微服务系统，而 Zipkin 则更适合小型、简单的微服务系统。当然，选择哪个，最终还是要根据你的实际需求来决定。就像找对象一样，适合自己的才是最好的！😉

实战演练：Jaeger 的应用

接下来，我们就以 Jaeger 为例，来演示一下如何在实际项目中应用分布式追踪。

1. 引入依赖

首先，我们需要在项目中引入 Jaeger 的相关依赖。以 Spring Boot 项目为例，可以在 pom.xml 文件中添加以下依赖：

<dependency>
    <groupId>io.opentracing.contrib</groupId>
    <artifactId>opentracing-spring-jaeger-starter</artifactId>
    <version>3.3.1</version>
</dependency>

2. 配置 Jaeger

然后，我们需要在 application.properties 或 application.yml 文件中配置 Jaeger 的相关参数：

jaeger:
  service-name: your-service-name # 服务名称，用于在 Jaeger UI 中区分不同的服务
  sampler:
    type: probabilistic # 采样类型，这里选择概率采样
    param: 0.1 # 采样率，这里设置为 0.1，表示采样 10% 的请求
  reporter:
    log-spans: true # 是否将 Span 信息输出到日志
    sender:
      host: localhost # Jaeger Agent 的主机地址
      port: 6831 # Jaeger Agent 的端口号

3. 埋点

接下来，我们需要在代码中进行埋点，也就是在关键的代码段中添加 Span，用于记录请求的耗时和相关信息。

可以使用 Tracer 对象来创建 Span：

@Autowired
private Tracer tracer;

public void doSomething() {
    Span span = tracer.buildSpan("doSomething").start();
    try {
        // 执行业务逻辑
        Thread.sleep(100);
        span.log("doing something...");
    } catch (Exception e) {
        span.log(e.getMessage());
    } finally {
        span.finish();
    }
}

当然，手动埋点比较繁琐，我们可以使用一些自动埋点的工具，比如 Spring Cloud Sleuth，它可以自动为 Spring MVC 的 Controller、RestTemplate、Feign Client 等添加 Span。

4. 启动 Jaeger Agent

在运行应用程序之前，我们需要先启动 Jaeger Agent。Jaeger Agent 是一个轻量级的守护进程，负责接收应用程序发送的 Span 数据，并将它们转发到 Jaeger Collector。

可以从 Jaeger 官网下载 Jaeger Agent 的二进制文件，然后运行以下命令启动它：

./jaeger-agent --config-file=jaeger-agent.yml

5. 运行应用程序

现在，我们可以运行应用程序，并发送一些请求。Jaeger Agent 会接收到这些请求的 Span 数据，并将它们转发到 Jaeger Collector。

6. 查看 Jaeger UI

最后，我们可以打开 Jaeger UI，查看请求的调用链。默认情况下，Jaeger UI 的地址是 http://localhost:16686。

在 Jaeger UI 中，我们可以看到每个请求的完整路径、耗时，以及各个服务的依赖关系。通过分析这些数据，我们可以快速定位问题，分析性能瓶颈，并还原请求链路。

进阶技巧：自定义 Span

除了自动埋点之外，我们还可以自定义 Span，用于记录一些特定的信息。比如，我们可以将用户 ID、订单 ID 等信息添加到 Span 中，方便我们进行更深入的分析。

可以使用 Span.setTag() 方法来添加自定义 Tag：

Span span = tracer.buildSpan("processOrder").start();
try {
    // 执行业务逻辑
    span.setTag("user.id", userId);
    span.setTag("order.id", orderId);
} finally {
    span.finish();
}

实战演练：Zipkin 的应用

Zipkin 的应用与 Jaeger 类似，主要区别在于配置和依赖方面。

1. 引入依赖

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-zipkin</artifactId>
</dependency>

2. 配置 Zipkin

spring:
  zipkin:
    base-url: http://localhost:9411
    enabled: true
    sampler:
      percentage: 0.1

3. 启动 Zipkin Server

Zipkin Server 可以通过 Docker 启动：

docker run -d -p 9411:9411 openzipkin/zipkin

4. 运行应用程序

运行应用程序，并发送请求。

5. 查看 Zipkin UI

打开 Zipkin UI，默认地址是 http://localhost:9411，查看调用链信息。

总结：选择适合自己的追踪方案

Jaeger 和 Zipkin 都是优秀的分布式追踪系统，它们各有优缺点，适用于不同的场景。

如果你的系统比较复杂，对性能要求较高，需要灵活的采样策略，以及深度链路分析，那么 Jaeger 可能是更好的选择。
如果你的系统比较简单，对性能要求不高，需要快速搭建，以及对 UI 界面要求不高，那么 Zipkin 可能是更好的选择。

当然，最好的方式是亲自尝试一下，看看哪个更适合你的项目。就像买鞋一样，只有穿上脚才知道合不合适！👟

分布式追踪的最佳实践

最后，我们再来聊聊分布式追踪的最佳实践：

选择合适的采样率： 采样率太低，可能无法覆盖所有请求；采样率太高，会增加系统的负担。需要根据实际情况进行权衡。
添加有意义的 Tag： Tag 可以帮助我们更好地分析请求，定位问题。尽量添加一些有意义的 Tag，比如用户 ID、订单 ID、请求参数等。
使用统一的 Span ID： 在多个服务之间传递 Span ID，可以保证请求的完整链路。可以使用一些 Trace ID 生成器，比如 UUID。
监控分布式追踪系统： 监控 Jaeger 或 Zipkin 的性能，可以及时发现问题，保证系统的稳定运行。

尾声：拥抱分布式追踪，告别加班！

各位朋友，今天的“分布式追踪：Jaeger, Zipkin 的应用”脱口秀就到这里了。希望通过今天的分享，大家能够对分布式追踪技术有更深入的了解，并在实际项目中应用起来。

记住，拥抱分布式追踪，告别加班！让我们一起成为高效、快乐的程序员！🎉

感谢大家的收听，我们下次再见！👋

发表回复 取消回复

发表回复取消回复