深入理解 SkyWalking 的架构与数据处理机制。

下面我们来系统性地解析 SkyWalking 的整体架构，重点聚焦其核心组件 OAP（Observability Analysis Platform）Server 如何接收、处理、存储和提供可观测性数据。

---

🧱 SkyWalking 架构原理解析：OAP 如何处理数据？

🎯 目标：理解从“Agent 上报”到“UI 展示”全过程的数据流转与处理逻辑。

---

一、SkyWalking 整体架构图（核心组件）

+----------------+     gRPC/HTTP     +---------------------+
|                | ----------------> |                     |
|   Agent        |                   |    OAP Server       |
| (Data Collector)| <--------------- | (Analysis & Storage)|
|                |     Query API     |                     |
+----------------+                   +----------+----------+
                                                |
                                                | JDBC / REST
                                                v
                                      +---------------------+
                                      |    Storage Backend  |
                                      | (Elasticsearch, etc)|
                                      +----------+----------+
                                                 |
                                                 | Query
                                                 v
                                      +---------------------+
                                      |        UI           |
                                      | (Web Console)       |
                                      +---------------------+

核心组件说明：

组件	职责
Agent	部署在应用端，采集链路、指标、JVM 等数据，通过 gRPC 上报 OAP
OAP Server	核心后端，负责数据接收、分析、聚合、存储、查询服务
Storage	存储层，保存指标、链路、日志等数据（支持多种后端）
UI	前端控制台，向 OAP 发起查询请求，展示 Dashboard、Trace、Logs 等

✅ 所有数据流动都围绕 OAP 展开 —— 它是 SkyWalking 的“大脑”。

---

二、OAP Server 是什么？

OAP（Observability Analysis Platform）Server 是 SkyWalking 的服务端核心引擎，它不是一个单一服务，而是一个模块化、插件化、可扩展的微内核架构系统。

它的主要职责：

1. 接收来自 Agent 的原始数据（gRPC）
2. 对数据进行分析、聚合、降采样
3. 将处理后的数据写入存储
4. 提供 GraphQL API 供 UI 查询

---

三、OAP 如何处理数据？—— 四大核心流程

我们以一条 链路数据（Trace） 为例，讲解 OAP 的完整处理链路：

🔁 流程 1：数据接收（Receiver）

• Agent 通过 gRPC 协议 将数据发送到 OAP 的 receiver 模块。
• 常见 Receiver：
  • receiver-trace：接收链路数据（OpenInflux, Jaeger, SkyWalking native）
  • receiver-metrics：接收指标数据（JVM、服务指标）
  • receiver-logging：接收日志数据（v8+）
  • receiver-register：接收服务/实例注册信息

📦 数据格式：Protocol Buffer（高效序列化）

// 示例：Segment（调用链片段）
message Segment {
  string traceId = 1;
  repeated Span spans = 2;
  string service = 3;
  string serviceInstance = 4;
}

---

🔍 流程 2：数据处理与分析（Analyzer）

这是 OAP 的“智能中枢”，负责将原始数据转化为可查询的聚合指标。

关键处理任务：

处理模块	功能
Trace Analysis	将多个 Segment 拼接成完整 Trace，生成 Span 关系
Topology Builder	分析调用关系，构建服务依赖拓扑图
Metric Aggregation	聚合 QPS、响应时间、错误率等指标（按分钟/小时）
Source Receiver	将原始事件（如服务注册）转化为“源数据”用于拓扑
Meter System	支持 Prometheus 风格的指标采集（v9+）

⚙️ 所有分析逻辑基于 数据流管道（Pipeline） 模型，模块之间松耦合。

---

💾 流程 3：数据存储（Storage）

OAP 将处理后的数据写入外部存储系统，支持多种后端：

存储类型	支持情况	特点
Elasticsearch 6/7/8	✅ 推荐	高性能、支持全文检索、适合日志
MySQL / TiDB	✅	易于管理，适合中小规模
InfluxDB	✅	时序数据优化，适合指标
TiKV	✅	分布式 KV，高可用
H2 / Memory	❌ 不推荐用于生产	仅用于测试

存储的数据类型：

数据类型	存储表/索引示例
调用链（Trace）	skywalking_trace_segment*（ES Index）
拓扑数据	service_relation_server_side*
指标数据	meter_service_*, jvm_*
告警记录	event*
日志数据	skywalking_logging*

📌 注意：OAP 不持久化原始数据，而是存储“聚合结果”和“可查询结构”，保证查询效率。

---

📡 流程 4：数据查询（Query）

UI 或外部系统通过 GraphQL API 向 OAP 发起查询请求。

示例：UI 查询“最近 10 分钟的服务响应时间”

{
  getServiceMetrics(
    service: "order-service"
    metricName: "service_resp_time"
    duration: { start: "2025-04-05T10:00:00", end: "2025-04-05T10:10:00" }
  ) {
    values {
      timestamp
      value
    }
  }
}

• OAP 接收到请求 → 从 Storage 读取数据 → 聚合返回 JSON
• UI 使用返回数据绘制图表

✅ OAP 提供统一的 GraphQL 查询接口，屏蔽底层存储差异。

---

四、关键设计思想

设计	说明
插件化架构	所有模块（Receiver、Storage、Analysis）均可插拔，便于扩展
无状态 OAP	OAP Server 本身不存储状态，可水平扩展
多租户支持	通过 namespace 隔离不同团队/项目的监控数据
高吞吐低延迟	使用 gRPC + Protobuf + 异步处理，支持高并发上报
流式处理模型	数据像流水线一样经过多个处理器，职责清晰

---

五、数据生命周期示例（一次完整流程）

1. 应用启动 → SkyWalking Agent 加载
2. 用户发起请求 → Agent 生成 Span 和 Segment
3. Agent 通过 gRPC 发送 Segment 到 OAP 的 receiver-trace
4. OAP 解析 Segment：
   - 提取调用关系 → 更新拓扑
   - 聚合指标（QPS、P99）→ 写入 meter 表
   - 存储调用链片段 → 写入 trace index
5. UI 查询：
   - 请求“服务列表” → OAP 从 DB 读取注册服务
   - 请求“响应时间趋势” → OAP 从 ES 读取聚合指标
   - 请求“调用链” → OAP 按 traceId 查询所有 Segment
6. 用户在 UI 上看到 Dashboard、Trace、Topology

---

六、OAP 高可用部署模式

                 +----------------+
                 |   Load Balancer|
                 +-------+--------+
                         |
            +------------+------------+
            |                         |
    +-------v--------+      +---------v-------+
    |   OAP Server 1   |      |   OAP Server 2   |
    +------------------+      +------------------+
            |                         |
            +------------+------------+
                         |
                 +-------v--------+
                 |   Shared Storage |
                 | (Elasticsearch) |
                 +-----------------+

• 多个 OAP 实例共享同一个存储
• Agent 可配置多个 OAP 地址实现负载均衡和容灾

---

✅ 总结：OAP 数据处理口诀

“一收（Receiver）二析（Analyzer）三存（Storage）四查（Query）”

OAP 是 SkyWalking 的“中枢神经”，它把分散的观测数据，变成可理解、可查询、可告警的系统视图。