分布式追踪可以通过对微服务调用链的跟踪，构建一个从服务请求开始到各个微服务(不局限于微服务，像数据库、MQ等也可以)交互的全部调用过程的视图。用户可以从中了解到诸如应用调用的时延，网络调用（HTTP，RPC）的生命周期，系统的性能瓶颈等信息。

Zipkin

下面是官网给出的Zipkin的UI图，一个是追踪接口调用过程链路的，一个是系统依赖统计的。

然后是具体的架构图

transport：数据传输，最主要的三种数据传输方式是HTTP、Kafka和Scribe（Facebook开源的日志收集系统）
collector：收集器：一旦跟踪数据到达Zipkin收集器，Zipkin收集器就会对其进行验证、存储和索引
storage：数据存储，除了Cassandra（一套开源分布式NoSQL数据库系统），还原生支持ElasticSearch 和 MySQL
search：一旦数据被存储和索引，我们需要一种方法来提取它。查询守护进程提供了一个简单的JSON API来查找和检索跟踪。此API的主要使用者是Web UI。
web UI：web UI提供了一种基于服务、时间和注释查看跟踪的方法。

接入方式

Java微服务一般使用引入Spring Cloud Sleuth的方式，对代码侵入性小

先看架构图

Probes：探针。收集数据，包括各种格式的指标、跟踪、日志和事件（SkyWalking, Zipkin, OpenTelemetry, Prometheus, Zabbix, etc.）
Platform backend：支持数据聚合、分析和流式处理（包括跟踪、指标、日志和事件）。担任聚合者角色、接收者角色或两者兼有
Storage：通过开放式/可插入式接口存储SkyWalking数据。您可以选择现有的实现，如ElasticSearch、H2、MySQL、TiDB、BanyanDB，也可以实现自己的
UI：UI是一个高度可定制的基于web的界面，允许SkyWalking最终用户可视化和管理SkyWalking数据

在SkyWalking中，探针是指集成到目标系统中的代理或SDK库，负责收集遥测数据，包括跟踪和指标。根据目标系统技术堆栈的不同，探针执行此类任务的方式截然不同。但最终，它们都朝着相同的目标努力——收集和重新格式化数据，然后将其发送到后端。主要有以下四种典型的探针类型：

基于语言的本地代理（Language based native agent）：这些代理运行在目标服务中，例如用户代码的一部分。例如，SkyWalking Java代理使用-javaagent命令行参数在运行时操纵代码，其中操纵意味着更改和注入用户的代码。另一个例子是SkyWalking代理，它利用Golang编译机制在编译时编织代码。对于一些静态编译语言，如C++，手动库是唯一的选择。
服务网格探针（Service Mesh probes）：服务网格探针从sidecar、服务网格中的控制平面或代理收集数据。在过去，代理只是作为整个集群的入口，但有了服务网格和sidecar，我们现在可以执行可观测性功能。
第三方库（3rd-party instrument library）：SkyWalking接受许多广泛使用的仪器库数据格式。SkyWalking社区与Zipkin社区有着密切的联系，它可以作为v1和v2 Zipkin踪迹的替代服务器。此外，支持gRPC中的OTEL跟踪格式，并在SkyWalking中转换为Zipkin格式。
eBPF agent（eBPF是一个能够在内核运行沙箱程序的技术，提供了一种在内核事件和用户程序事件发生时安全注入代码的机制，使得非内核开发人员也可以对内核进行控制）：eBPF代理收集指标并分析由Linux内核的eBPF技术提供支持的目标服务。

官方UI

SkyWalking自9.4.0起提供PromQL服务，自9.6.0起提供LogQL服务。也可以选择Grafana或Loki作为SkyWalking UI。具体配置方式见官网：skywalking.apache.org/docs/main/n…

采用java探针，字节码增强，对代码无侵入。配置方式可参考官网：skywalking.apache.org/docs/skywal…