1. SkyWalking 总体架构概览
2. Agent 组件：无侵入探针
3. OAP 组件：后端分析平台
4. Storage 组件：存储选型
5. UI 组件：可视化界面
6. 数据流转全流程
7. 大模型场景下架构选型建议

1. SkyWalking 总体架构概览

Apache SkyWalking 采用经典的「采集—分析—存储—展示」四层架构，由四个核心组件构成：**Agent（探针）、OAP（Observability Analysis Platform，后端分析平台）、Storage（存储）、UI（界面）**。理解这四个组件的分工与协作，是后续一切排障与优化的基础。

业务应用 (JVM)
   │ 无侵入字节码增强
   ▼
[ SkyWalking Agent ]  ──gRPC/HTTP──▶  [ OAP Server ]
                                         │ 聚合/分析/OAL
                                         ▼
                                    [ Storage ]
                                         ▲
                                         │ 查询
                                    [ SkyWalking UI ]
 

1.1 设计哲学

SkyWalking 的核心设计哲学是**「无侵入采集 + 中心化分析」**：

• **无侵入**：通过 Java Agent 在字节码层面完成埋点，业务代码零改动。
• **中心化**：所有分析、聚合、指标计算都在 OAP 完成，减轻业务进程负担。
• **可插拔**：存储、告警、协议均可替换，适配不同规模与云环境。

2. Agent 组件：无侵入探针

Agent 是挂载在每个业务 JVM 上的探针，它是数据的"源头"。

2.1 职责

• **字节码增强**：在类加载时织入埋点逻辑，自动捕获 HTTP、RPC、SQL、MQ 等调用。
• **上下文传播**：在跨线程、跨进程调用间传递 TraceId / SpanId。
• **数据上报**：将 TraceSegment 通过 gRPC 批量上报给 OAP。

2.2 关键目录结构

skywalking-agent/
├── skywalking-agent.jar        # 核心 Agent
├── config/agent.config         # Agent 配置
├── plugins/                    # 内置插件（自动增强）
├── optional-plugins/           # 可选插件（需手动启用）
├── activations/                # 特定框架激活器
└── bootstrap-plugins/          # 引导期插件
 

2.3 启动方式

java -javaagent:/path/to/skywalking-agent.jar \
     -Dskywalking.agent.service_name=chat-service \
     -Dskywalking.collector.backend_service=oap:11800 \
     -jar your-app.jar
 

> 注意：Agent 本身是单实例加载，`-javaagent` 只能指定一次；多 Agent 会冲突。

3. OAP 组件：后端分析平台

OAP 是整个系统的大脑，负责接收、聚合、分析并对外提供查询。

3.1 模块构成

模块	作用
---	---
Receiver	接收 Agent 上报的 Trace/Metrics/JVM 数据
Analysis Core	流处理聚合，构建拓扑、指标
OAL Engine	用 OAL 语法生成指标
Storage Module	写入/读取存储
Query Module	提供 GraphQL 接口给 UI
Alarm Module	基于规则触发告警

3.2 OAL 可观测性分析语言

OAL 是 SkyWalking 的声明式指标语言，让你用接近 SQL 的语法定义聚合指标，无需写 Java：

# 计算服务 P99 时延
service_resp_time_percentile = from(Service.latency).percentile(10,50,90,95,99)
# 计算大模型 Exit Span 的平均首字时延
llm_ttft = from(ExitSpan.tag("llm.ttft.ms")).longAvg()
# 每秒请求数
service_cpm = from(Service.*).cpm()
 

3.3 集群与角色

OAP 支持两种角色：

• **Mixed（混合）**：单机同时承担接收与分析（适合中小规模）。
• **Aggregator（聚合）**：分离 Receiver 与 Aggregator，适合大规模生产。

4. Storage 组件：存储选型

Storage 负责持久化 Trace、Metrics、拓扑等数据。SkyWalking 的存储是**可插拔**的。

4.1 主流选型对比

存储	优点	缺点	适用场景
---	---	---	---
H2	零部署、开箱即用	单机、易丢数据	本地体验/测试
Elasticsearch	查询快、水平扩展	资源占用高	生产首选（大数据量）
MySQL	易维护	写入性能瓶颈	中小规模
PostgreSQL	稳定	同 MySQL	中小规模
BanyanDB	原生时序优化	较新	新项目/国产化

4.2 生产推荐

storage:
  selector: ${SW_STORAGE:elasticsearch}
  elasticsearch:
    namespace: ${SW_NAMESPACE:sw}
    clusterNodes: ${SW_STORAGE_ES_CLUSTER_NODES:oap-es:9200}
    indexShardsNumber: ${SW_STORAGE_ES_INDEX_SHARDS_NUMBER:3}
    superDatasetIndexShardsFactor: ${SW_STORAGE_ES_SUPER_DATASET_INDEX_SHARDS_FACTOR:5}
 

> 实战踩坑：ES 索引会随时间膨胀，务必配置 ILM（索引生命周期管理）做冷热分离与自动删除，否则磁盘会被历史 Trace 撑爆。

5. UI 组件：可视化界面

UI 是 SkyWalking 的 Web 控制台，基于前端单页应用，通过 GraphQL 查询 OAP。

5.1 核心视图

• **拓扑图（Topology）**：自动绘制的服务依赖与实时流量/时延。
• **追踪（Trace）**：某次请求完整的 Span 树与火焰图。
• **服务/实例/端点指标**：QPS、时延、SLA、JVM。
• **性能剖析（Profiling）**：线程级 CPU 火焰图。
• **告警（Alarm）**：规则命中列表与 Webhook 推送。

5.2 大模型排障的关键入口

在 UI 的「追踪」页可按 `llm.model`、`llm.cost.usd` 等 Tag 过滤，快速定位"最贵/最慢"的大模型调用。

6. 数据流转全流程

一次请求的完整数据流如下：

1. 请求进入 chat-service，Agent 创建 EntrySpan
2. 调用 vector-db，Agent 创建 ExitSpan 并注入上下文
3. 调用远端 LLM，Agent 创建 ExitSpan(tag: llm.ttft.ms)
4. 各 Span 组成 TraceSegment，Agent 批量 gRPC 上报 OAP
5. OAP 聚合：生成拓扑边、计算 OAL 指标
6. OAP 写入 Storage
7. UI 通过 GraphQL 查询并渲染拓扑/追踪
 

图 figure_02_2 用时序图更直观地展示了这一步步的协作。

7. 大模型场景下架构选型建议

7.1 部署形态

• **Agent 侧**：每个 JVM 进程一个 Agent，统一通过配置中心下发 `agent.config`。
• **OAP 侧**：生产建议独立部署 2~3 个 OAP 节点做高可用；数据量大时分离 Receiver/Aggregator。
• **Storage 侧**：首选 Elasticsearch 集群，配合 ILM；国产化可考虑 BanyanDB。

7.2 性能与隔离

# OAP 调优要点
core:
  default:
    restHost: 0.0.0.0
    restPort: 12800
    gRPCHost: 0.0.0.0
    gRPCPort: 11800
receiver-trace:
  default:
    sampleRate: ${SW_TRACE_SAMPLE_RATE:10000}   # 万分之一单位，10000=100%
    slowTraceThreshold: ${SW_SLOW_TRACE_THRESHOLD:8000}  # 慢链路阈值(ms)
 

> 最佳实践：生产环境对高频普通接口可**采样**（sampleRate < 10000）以降本；但对大模型调用（慢且贵）应**强制全采**，避免漏掉关键链路。

小结

本篇我们剖析了 SkyWalking 四大组件的职责与协作：Agent 负责无侵入采集，OAP 负责中心化分析与 OAL 指标，Storage 可插拔持久化，UI 提供拓扑与追踪视图。理解这套数据流，是后续动手接入与排障的前提。下一篇我们将深入 Agent 的字节码增强原理。