1. OpenTracing术语

OpenTracing调用链跟踪系统的一个事实标准，它制定了调用链跟踪的基本流程和基本的数据结构，同时也提供了各个语言的实现。

SpanContext：一个类似于MDC（Slfj)或者ThreadLocal的组件，负责整个调用链数据采集过程中的上下文保持和传递，支持跨进程间的传递。
Trace：一次调用的完整记录
- Span：一次调用中的某个节点/步骤，类似于一层堆栈信息，Trace是由多个Span组成，Span和Span之间也有父子或者并列的关系来标志这个节点/步骤在整个调用中的位置。
  - Tag：节点/步骤中的关键信息。
  - Log：节点/步骤中的详细记录，例如异常时的异常堆栈。
- Baggage：和SpanContext一样并不属于数据结构而是一种机制，主要用于跨Span或者跨实例的上下文传递，Baggage的数据更多是用于运行时，而不会进行持久化。

注：在Dapper中Span还有另外一种数据结构Annotation。它允许用户通过一个简单的API定义带时间戳的任意内容。

下图展示了Span和Trace在链路追踪系统中的关系：

下图展示了Span的父子关系：

2. Zipkin VS SkyWalking

Zipkin VS SkyWalking

Architecture

Architecture

不清楚zipkin的上报方式是http还是kafka。

Zpkin的Brave上手难度要比SkyWalking的agent难度小很多，如果你有二次开发需求，这是一个值得考虑的问题。

微服务监控一般包含三个部分Tracing、Metrics、Logging。他们的关系如下图

我们经常把Zipkin和SkyWalking放在一起比较，但是通过上面的对比我们发现其实Zipkin和SkyWaling的定位是完全不同的，Zipkin的定位是只是Tracing，SkyWalking的是定位是完整的APM。所以如果你想引入APM他们是没有什么对比性的。

如果你所在的公司已经有了Metrics（一般是Prometheus等），Logging（ELK日志采集）。那么我的建议是你可以不使用SkyWalking。如果没有那么使用SkyWalking是一个不错的选择。
如果你们只有Java一种语言，SkyWalking基于字节码增强的探针，确实会有接入成本的优势。但是在多语言场景下。例如Go语言，其实还是需要手动埋点的。
Zipkin和SkyWalking上报数据的方式有很大不同，这点需要注意下。但是SkyWalking在8.1.0版本之后也支持通过kafka上报数据了。关于使用mq上报数据还是grpc上报数据并没有一个明确的标准。SkyWalking的作者在这里说明了下为什么使用grpc而不是mq的原因。

Why doesn't SkyWalking involve MQ in the architecture

参考文章：