分布式链路追踪的技术选型介绍

发表于 阅读次数： 评论数： 本文字数： 4.4k 阅读时长 ≈ 4 分钟

Jaeger

  • 简介：
    • Jaeger 是 Uber 开源的分布式追踪系统，具备强大的追踪、监控和故障诊断功能。它是 CNCF 的项目之一，得到了广泛的社区支持。
  • 特点：
    • 高性能：Jaeger 专为大规模分布式系统设计，适合高并发、大规模系统。
    • 丰富的功能：支持多种存储后端（如 Elasticsearch、Cassandra），具备查询、可视化、错误诊断等多种强大功能。
    • 支持 OpenTracing：与 OpenTracing 标准完全兼容，可与多种语言和平台进行集成。
    • 扩展性：支持多种采样策略和链路追踪数据的丰富查询。
  • 适用场景：
    • 适合大型分布式系统，尤其是要求在高性能、高并发的场景下表现优异。
    • 适合系统需要和其他平台或语言进行互操作，且希望遵循 OpenTracing 标准的场景。

Zipkin

  • 简介：
    • Zipkin 是 Twitter 开源的一个分布式链路追踪系统，最早集成在 Spring Cloud Sleuth 中，可以用于收集时序数据并可视化微服务调用链路。
  • 特点：
    • 轻量级：它的架构相对简单，容易部署，尤其适合中小规模系统。
    • 集成度高：Spring Cloud Sleuth 对 Zipkin 的支持非常完善，集成简单，提供了现成的解决方案。
    • 查询功能：支持可视化链路展示，方便查看微服务调用的延时、失败等信息。
    • 插件化支持：可以支持不同的存储后端，比如 MySQL、Elasticsearch 等。
  • 适用场景：
    • 适合中小型项目（规模不大），且已使用 Spring Cloud 生态技术。

Sleuth

  • 简介：
    • Sleuth 是 Spring Cloud 自带的分布式链路追踪工具，支持自动为 Spring Cloud 的微服务添加 TraceId 和 SpanId。
  • 特点：
    • 深度集成：和 Spring Cloud 生态高度集成，几乎开箱即用，默认使用 Zipkin 来进行数据存储和展示。
    • 自动化：自动为 HTTP 请求、消息队列、数据库操作等关键操作添加追踪信息，无需开发者手动干预。
    • 可扩展性：支持与其他追踪系统（如 Jaeger）的集成，具备较高的扩展性。
  • 适用场景：
    • 适合基于 Spring Cloud 架构的中小型项目团队，尤其是希望利用 Spring 生态快速集成链路追踪的情况。

Pinpoint

  • 简介：
    • Pinpoint 是一款开源的 APM（应用性能管理）工具，主要用于大规模分布式系统的性能监控和故障诊断。它最初由韩国的 Naver 公司开发，现已成为监控 Java 和 PHP 应用的常用工具之一。
  • 特点：
    • 分布式跟踪：支持跟踪分布式系统中不同服务之间的调用关系，提供详细的调用链分析。
    • 实时监控：通过仪表盘实时查看应用的状态，如响应时间、吞吐量、硬件资源使用情况（如 CPU、内存）等。
    • 非侵入式安装：不需要修改现有代码即可集成 Pinpoint，可以通过字节码注入的方式收集数据。
    • 支持多种框架：Pinpoint 支持监控 Java 和 PHP 应用，涵盖常见的 Web 框架、RPC 框架（如 Spring、Dubbo、gRPC）等。
    • 可视化展示：提供拓扑图、调用链视图、热图等丰富的可视化（UI）功能，帮助快速定位性能问题。
    • 告警机制：支持自定义性能阈值，监控超过阈值时发送告警通知。
  • 适用场景：
    • 适用于微服务架构或者大型分布式系统的性能监控，可以追踪多个服务间的调用关系，帮助开发者快速定位系统的性能瓶颈，优化应用性能，并快速定位问题。

OpenTracing

  • 简介：
    • OpenTracing 是一个开源的 API 标准，诞生于 2016 年，旨在为分布式追踪系统提供统一的接口规范。它允许开发者在应用程序代码中无缝插入追踪代码，而无需绑定到特定的追踪工具（如 Jaeger 或 Zipkin）
  • 目标：
    • 提供跨语言的标准 API 来记录分布式系统中的 Trace 和 Span，使得开发者能够通过标准接口与各种追踪实现集成。
  • 局限性：
    • OpenTracing 仅提供了 API 规范，没有包含具体的实现和上下文传播等内容。因此，开发者还需要额外的库或工具来实际记录和处理追踪数据。

OpenCensus

  • 简介：
    • OpenCensus 由 Google 开发，最初作为其内部监控系统的开源版本，旨在解决分布式系统的追踪和度量问题。与 OpenTracing 不同，OpenCensus 不仅提供 API 规范，还包含了用于收集和导出追踪和度量数据的库和实现。
  • 特点：
    • OpenCensus 不仅支持分布式追踪，还提供应用程序级别的度量（Metrics），如请求速率、延迟等。它还包含了一些内置的采集和上下文传播机制。
  • 局限性：
    • OpenCensus 不仅提供了 API，还提供了具体的实现，这与 OpenTracing 产生了竞争关系。
    • OpenCensus 与 OpenTracing 的功能重叠，并且各自采用了不同的 API 规范，导致生态系统中出现了分裂。

OpenTelemetry

  • 简介：
    • OpenTelemetry 是 OpenTracing 和 OpenCensus 的合并项目，由 CNCF 领导。它于 2019 年启动，旨在统一追踪和度量的标准，成为云原生应用的统一遥测（Telemetry）解决方案。
  • 目标：
    • 结合 OpenTracing 的标准化 API 和 OpenCensus 的实现，OpenTelemetry 提供了一个统一的库，支持分布式追踪、度量和日志的收集和导出。
  • 特点：
    • 分布式追踪： 提供类似于 OpenTracing 的 API，用于记录分布式系统中的追踪信息。
    • 度量： 像 OpenCensus 一样，OpenTelemetry 也提供了应用性能度量数据的收集。
    • 日志： 除了追踪和度量，OpenTelemetry 计划支持日志数据的统一收集和处理。
    • 支持多种后端： OpenTelemetry 支持将数据导出到多种后端系统，如 Jaeger、Zipkin、Prometheus 等。
  • 发展现状：
    • OpenTelemetry 是目前 CNCF 重点支持的项目，逐渐成为行业标准，并被广泛应用于云原生应用程序中。

SkyWalking

  • 简介：
    • SkyWalking 是一个非常强大的全栈 APM（应用性能监控）和分布式链路追踪解决方案，而 OpenTracing、OpenCensus、OpenTelemetry 则是更倾向于标准化和 API 的解决方案。
  • 核心功能：
    • 开箱即用：SkyWalking 从数据收集到可视化仪表盘都有现成的功能，尤其适合希望快速搭建一整套 APM 解决方案的团队。
    • 分布式链路追踪：自动追踪微服务之间的调用，记录服务调用链，提供请求延迟、错误率等信息。
    • 性能监控（APM）：提供如响应时间、吞吐量、系统健康状况等性能指标的监控。
    • 服务拓扑图：SkyWalking 生成微服务之间的交互拓扑图，帮助用户快速理解系统的依赖关系。
    • 日志和度量集成：支持集成日志系统（如 ELK）以及度量系统，形成一个全方位的监控平台。
    • 自动探针：通过代理（Agent）自动采集应用程序的 Trace 和 Metrics，无需对代码进行显式修改。
    • 性能和扩展性：支持大规模分布式系统的监控，具备强大的可扩展性，支持高并发的链路追踪数据采集和处理。
  • 适用场景：
    • 多语言支持：SkyWalking 支持多种编程语言和框架，这使得它非常适合多技术栈的团队。
    • 完整的 APM 需求：如果系统不仅需要链路追踪，还需要监控应用性能、日志分析，那么非常适合选择 SkyWalking。
    • 自动化集成：对于已经运行的大规模分布式系统，如果不想在代码中手动添加追踪信息，SkyWalking 的自动探针功能非常适合。

SkyWalking 与 OpenTelemetry 的对比

  • 生态与标准：
    • OpenTelemetry 是 CNCF 的标准项目，提供追踪、度量和日志的统一 API，并且可以与 Jaeger、Prometheus、Zipkin 等工具进行深度集成。
    • SkyWalking 则是一个完整的监控和链路追踪解决方案，不仅仅是一个 API 标准。它提供了完整的前端 UI、数据存储后端，以及自动化的数据收集器。
    • SkyWalking 也兼容 OpenTracing 和 OpenTelemetry API，这意味着可以将 SkyWalking 与其他系统结合使用，甚至可以使用 OpenTelemetry 的 API 通过 SkyWalking 收集和处理数据。
  • 功能差异：
    • 自动化程度：SkyWalking 提供了强大的 自动探针功能，开发者不需要在代码中显式添加追踪代码。这对于已经运行中的大型分布式系统特别有用。而 OpenTelemetry 需要通过 SDK 或 API 来实现追踪（尽管有一些自动化探针，也需要配置）。
    • 全栈 APM：SkyWalking 不仅仅是一个分布式追踪工具，它是一个完整的 APM 解决方案，提供应用性能监控、链路追踪、日志集成等功能。OpenTelemetry 本身只是一个标准和工具库，需要和其他工具（如 Jaeger 或 Prometheus）配合使用才能实现同样的功能。
    • 可视化和存储：SkyWalking 内置了完善的可视化仪表盘和后端存储解决方案（如 Elasticsearch、MySQL 等）。而 OpenTelemetry 没有内置的存储和可视化功能，需要与 Jaeger、Prometheus、Grafana 等工具组合使用。
    • 生态支持：SkyWalking 提供了对多种环境的深度支持，包括 Java、Go、Node.js、PHP 等语言，且支持多种微服务框架（如 Kubernetes、Spring Cloud、Envoy、Istio 等）。

SkyWalking 与 Jaeger、Zipkin 的对比

  • 功能集成度：
    • SkyWalking 是一个集成度更高的系统，除了链路追踪，还包括性能监控、日志管理等功能。
    • Jaeger 和 Zipkin 专注于分布式追踪，它们侧重于提供链路追踪的可视化和数据采集。
  • 可视化体验：
    • SkyWalking 的 UI 更加用户友好，内置了服务拓扑图、依赖分析、告警功能，可以提供更丰富的可视化体验。
    • Jaeger 和 Zipkin 更偏重于单一的追踪功能，可能需要与其他工具组合使用才能达到同样的监控效果。

如何选择 SkyWalking 和 OpenTracing

  • 如果目标是快速构建一个可视化、自动化的监控平台，SkyWalking 是一个非常合适的选择。
  • 如果需要使用行业标准（比如 OpenTracing），且需要与结合其他工具来构建定制化的监控系统，OpenTelemetry 是一个更灵活、标准化的选择。

其他实现方案

分布式链路追踪系统还有其他比较成熟的实现，例如：

  • 京东的 Hydra
  • 美团点评的 CAT
  • 新浪的 Watchman
  • Apache 的 HTrace
  • 阿里巴巴的鹰眼 Tracing

技术方案对比

技术选型总结

  • 如果是中小型项目，且已使用 Spring Cloud 周边生态的技术，建议采用 Sleuth + Zipkin 方案。
  • 如果目标是快速构建一个高性能、可视化、自动化的大型分布式链路追踪平台，Pinpoint 和 SkyWalking 都是一个非常合适的选择。
  • 如果需要使用行业标准（比如 OpenTracing），且需要与结合其他工具来构建定制化的大型分布式链路追踪系统，OpenTelemetry 是一个更灵活、标准化的选择。