上一篇【第02篇】APM和可观测性到底是啥——写给所有被这两个词搞懵的开发者
下一篇【第04篇】SkyWalking的三大设计哲学——面向协议、模块化、轻量化

摘要

架构图是技术系统的"地图"，看懂了地图，才不会在探索过程中迷路。SkyWalking的官方架构图看起来方方正正，但里面藏着大量的设计智慧。本篇带你逐层拆解SkyWalking的四大核心组件，理解探针如何收集数据、OAP如何分析处理、存储如何持久化、UI如何展示，以及三大设计原则是如何贯穿整个架构的。

一、一个简化的比喻：医院监控系统

在深入架构细节之前，先用一个比喻建立整体感：

把SkyWalking想象成一套医院的实时健康监控系统：

• 探针（Agent）= 贴在病人身上的传感器（血压计、心率仪、血氧仪）——负责采集数据，不影响病人正常活动
• OAP Server= 医院的监控中心——接收所有传感器数据，分析计算，发现异常
• 存储实现= 病历档案库——持久化保存所有历史数据，供后续查询
• UI模块= 医生工作站的大屏幕——直观展示所有数据，支持医生快速决策

这四个组件协同工作，构成了完整的"病人健康监控系统"，也就是我们的分布式系统APM平台。

二、SkyWalking整体架构图

先上大图，建立整体认知：

┌─────────────────────────────────────────────────────────────────────┐ │ SkyWalking 整体架构 │ │ │ │ ┌─────────────────────────────────────────────────────────────┐ │ │ │ 探针层 (Probes) │ │ │ │ │ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ │ │ Java │ │ .NET │ │ Node.js │ │ Service │ │ │ │ │ │ Agent │ │ Agent │ │ Agent │ │ Mesh │ │ │ │ │ │(JavaAgent│ │ │ │ │ │(Istio/ │ │ │ │ │ │字节码增强)│ │ │ │ │ │ Envoy) │ │ │ │ │ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ └───────┼─────────────┼─────────────┼──────────────┼────────┘ │ │ │ gRPC协议上报│ │ │ │ │ ▼ ▼ ▼ ▼ │ │ ┌─────────────────────────────────────────────────────────────┐ │ │ │ OAP Server (分析平台) │ │ │ │ │ │ │ │ ┌────────────┐ ┌────────────┐ ┌───────────────────────┐ │ │ │ │ │ Receiver │ │ 流式计算 │ │ 查询内核 (GraphQL) │ │ │ │ │ │ (数据接收) │→ │ 内核 │→ │ │ │ │ │ │ │ │ │ (OAL计算) │ │ │ │ │ │ │ └────────────┘ └─────┬──────┘ └──────────┬────────────┘ │ │ │ └──────────────────────┬─┘──────────────────────┼─────────────┘ │ │ │ 存储接口 │ 查询接口 │ │ ▼ ▼ │ │ ┌───────────────────────────────┐ ┌───────────────────────────┐ │ │ │ 存储实现层 (Storage) │ │ UI 模块 │ │ │ │ │ │ (RocketBot/SkyWalking UI)│ │ │ │ ┌────┐ ┌──────┐ ┌─────────┐ │ │ │ │ │ │ │ H2 │ │ ES │ │ MySQL/ │ │ │ Dashboard / 拓扑图 / Trace│ │ │ │ │ │ │ │ │ TiDB │ │ │ 告警 / 性能剖析 │ │ │ │ └────┘ └──────┘ └─────────┘ │ │ │ │ │ └───────────────────────────────┘ └───────────────────────────┘ │ └─────────────────────────────────────────────────────────────────────┘

三、第一组件：探针（Probe）

探针是SkyWalking的数据采集层，负责从各种不同的运行环境中收集遥测数据（Telemetry Data）。

探针的类型

SkyWalking支持多种类型的探针，覆盖了现代分布式系统的主要技术栈：

1. 语言探针（Language Agents）

• Java Agent：最成熟、功能最完整的探针，通过JavaAgent机制（字节码增强）实现对应用的无侵入监控
• .NET Agent：由社区贡献，支持.NET Core
• Node.js Agent：支持Node.js应用的追踪
• Go Agent：支持Go语言应用
• PHP Agent：支持PHP应用（通过Swoole等框架）

2. Service Mesh探针

• 通过Istio/Envoy的Telemetry数据接入，无需语言探针
• 适合已经部署了Service Mesh的环境

3. 第三方框架探针

• Nginx Lua探针：监控Nginx层的流量
• 通过插件机制支持各种中间件（Dubbo、Spring MVC、Redis、MySQL等）

Java Agent的工作原理（简介）

Java Agent是SkyWalking最核心的探针实现，它的无侵入性来自于JDK 1.5引入的JavaAgent机制：

// SkyWalking Agent启动入口// 在JVM启动时，通过-javaagent参数触发premain方法publicclassSkyWalkingAgent{publicstaticvoidpremain(Stringarguments,Instrumentationinstrumentation){// 1. 初始化配置// 2. 扫描并加载所有插件定义// 3. 注册ClassFileTransformer，在类加载时动态插入追踪代码instrumentation.addTransformer(newClassEnhancePluginDefine());}}

关键点：应用代码完全不需要修改，只需在启动时加上-javaagent:/path/to/skywalking-agent.jar参数，SkyWalking就会自动监控你的应用。这就是"无侵入"的含义。

探针上报的数据

探针向OAP Server上报三类数据：

1. 注册信息：服务注册（服务名、实例信息）
2. Tracing数据：TraceSegment（调用链路片段）
3. Metrics数据（某些版本通过OAL计算生成）

上报协议使用gRPC，这也是SkyWalking面向协议设计的体现。

四、第二组件：OAP Server（观测分析平台）

OAP是SkyWalking的大脑，全称Observability Analysis Platform（可观测性分析平台）。它是整个系统最复杂的组件，内部由三大子模块构成：

子模块1：Receiver（数据接收层）

Receiver负责接收各种探针上报的数据。由于SkyWalking面向协议设计，Receiver可以接收多种格式的数据：

子模块2：流式计算内核（OAL引擎）

这是OAP最精华的部分。接收到的原始Trace数据，需要被聚合计算成各种指标：

• 某个服务的平均响应时间
• 某个接口的P99延迟
• 某个服务实例的错误率
• 服务间的调用拓扑关系

这些计算不能用关系数据库做，因为数据量太大。SkyWalking设计了专有的OAL（Observability Analysis Language），这是一种编译型DSL脚本语言，用来定义如何对原始数据进行流式聚合计算。（第七模块会详细讲）

OAP内部数据流 原始Trace → Receiver → OAL引擎 → Metrics结果 │ ├→ 服务指标 (响应时间/错误率) ├→ 实例指标 ├→ Endpoint指标 └→ 服务间拓扑关系

子模块3：查询内核（GraphQL API）

OAP对外提供GraphQL协议的查询接口，UI模块通过这个接口获取所有数据。

为什么选GraphQL而不是RESTful？官方给出了明确的理由：

考虑到更好的扩展性、更加灵活的组合查询模式，选择了GraphQL。GraphQL的预定义格式和多种查询组合使用，为UI和第三方系统提供了良好的集成能力。

GraphQL允许客户端精确地声明需要什么数据，避免了RESTful API的Over-fetching和Under-fetching问题，非常适合OAP这种数据多维度、查询模式复杂的场景。

五、第三组件：存储实现（Storage）

存储层负责持久化OAP处理后的所有数据。SkyWalking的一个核心优势是存储可插拔——通过统一的存储接口，支持多种存储后端：

┌──────────────────────────────────────────────────────────────┐ │ SkyWalking 存储选型对比 │ ├──────────────┬──────────┬────────────┬──────────────────────┤ │ 存储类型 │ 适用场景 │ 数据规模 │ 备注 │ ├──────────────┼──────────┼────────────┼──────────────────────┤ │ H2 (内置) │ 开发测试 │ 小，不持久 │ 默认配置，重启丢数据 │ ├──────────────┼──────────┼────────────┼──────────────────────┤ │ Elasticsearch│ 生产首选 │ 大 │ 官方推荐，性能最优 │ ├──────────────┼──────────┼────────────┼──────────────────────┤ │ MySQL │ 中小规模 │ 中 │ DBA熟悉，运维简单 │ ├──────────────┼──────────┼────────────┼──────────────────────┤ │ TiDB │ 中大规模 │ 大 │ MySQL兼容，分布式 │ ├──────────────┼──────────┼────────────┼──────────────────────┤ │ InfluxDB │ 时序数据 │ 中 │ 专注指标存储 │ └──────────────┴──────────┴────────────┴──────────────────────┘

存储层的可插拔设计，让SkyWalking不依赖任何大数据技术栈，这是它区别于Pinpoint（强依赖HBase）的根本所在。

六、第四组件：UI模块

UI模块是面向运维人员和开发人员的可视化界面，通过GraphQL协议从OAP查询数据，提供以下核心视图：

1. Dashboard（仪表板）：展示服务/实例/Endpoint的实时性能指标
2. Topology（拓扑图）：服务间调用关系的有向图，直观展示系统架构
3. Trace视图：Span瀑布图，展示单次请求的完整调用链路
4. 告警面板：显示触发的告警规则和历史告警
5. 性能剖析：代码级别的性能热点分析（SkyWalking 7+）

历史上，SkyWalking的UI经历了几次更替：

• 5.x版本：原始UI（功能简单）
• 6.0.0-GA后：切换为RocketBot UI（Vue.js实现，功能大幅增强）
• 9.x版本：全新设计的SkyWalking UI（现代化设计，更好的交互体验）

七、三大设计原则快速预览

四大组件是架构的"骨"，三大设计原则是架构的"魂"：

┌─────────────────────────────────────────────────────────────┐ │ SkyWalking 三大设计原则 │ │ │ │ ┌───────────────┐ │ │ │ 面向协议设计 │ → 探针协议、查询协议全部预先定义 │ │ │ │ 多语言探针基于同一协议互通 │ │ └───────────────┘ │ │ │ │ ┌───────────────┐ │ │ │ 模块化设计 │ → Module + Provider 的可插拔架构 │ │ │ │ 每个功能都可以替换、扩展 │ │ └───────────────┘ │ │ │ │ ┌───────────────┐ │ │ │ 轻量化设计 │ → 不依赖大数据技术栈 │ │ │ │ 自研轻量级流计算框架 │ │ └───────────────┘ │ └─────────────────────────────────────────────────────────────┘

每一条设计原则背后都有深刻的工程考量，下一篇会逐一展开。

本篇小结

SkyWalking的架构清晰地分为四层：

• 探针层：多语言无侵入数据采集
• OAP层：接收 → 流式计算 → 存储 + 对外查询
• 存储层：可插拔，支持ES/MySQL/TiDB等多种后端
• UI层：GraphQL驱动的可视化界面

三大设计原则（面向协议/模块化/轻量化）贯穿所有组件设计决策，是理解SkyWalking的核心钥匙。

下一篇我们深入三大设计哲学，看看每一条背后的具体工程决策和权衡取舍。

上一篇【第02篇】APM和可观测性到底是啥——写给所有被这两个词搞懵的开发者
下一篇【第04篇】SkyWalking的三大设计哲学——面向协议、模块化、轻量化