适用读者：想"不改代码就拿到链路+指标+拓扑"的人；要在 Zipkin 与 SkyWalking 之间做选择的人。
前置：S16-J02、S15（Docker/容器编排）。
覆盖旧文：A-560 → 178 点（SkyWalking 五大能力、核心架构、Java Agent、OAP、UI、数据流）。
扩展点：E-S16-007（P95 与均值的选择）。
上一篇：S16-J02 · 接入实战：Spring Boot 3 + Micrometer Tracing + Zipkin
下一篇：S16-J04 · 排障实战。
1. 一句话结论
SkyWalking 的卖点是"零代码侵入 + 多信号合一"（链路、拓扑、指标、日志、profiling）。零侵入不是免费的：它把成本从"写代码"转移到了"字节码增强的兼容性与性能开销"上。
| 能力 | 解决的问题 | 数据来源 |
|---|---|---|
| 链路追踪 | 一次请求经过谁 | Agent 拦截框架调用 |
| 服务拓扑 | 谁依赖谁、调用量多少 | 链路聚合 |
| Metrics | 延迟/吞吐/错误率（含 P95） | 链路 + JVM 指标 |
| Logs | 日志与链路关联 | 日志框架插件 |
| Profiling | 方法级热点 | 按需采样线程栈 |
2. 架构：三段式数据流
业务进程（Java Agent，字节码增强）
│ gRPC/HTTP 上报（segment/trace）
▼
OAP Server（聚合、分析、告警）
│
├── 存储（默认 H2，生产用 Elasticsearch / BanyanDB）
▼
UI（拓扑图、链路查询、指标面板）
| 组件 | 职责 | 关键配置 |
|---|---|---|
| Agent | 在应用内织入拦截器，生成 span/segment | agent.service_name、collector.backend_service |
| OAP | 接收、聚合、告警规则计算 | 存储选择、集群模式 |
| UI | 查询与展示 | 默认 8080 |
Judge：Agent 的 service_name 决定拓扑上的节点名；命名不一致（order-service vs order_service）会让拓扑分裂成两个节点——这是最常见的"图不对"原因。
3. 快速跑起来（docker-compose，2026-11 实测）
# docker-compose.yml
services:
oap:
image: apache/skywalking-oap-server:10.4.0
environment:
SW_STORAGE: elasticsearch
SW_STORAGE_ES_CLUSTER_NODES: es:9200
ports: ["11800:11800", "12800:12800"]
ui:
image: apache/skywalking-ui:10.4.0
environment:
SW_OAP_ADDRESS: http://oap:12800
ports: ["8080:8080"]
es:
image: docker.elastic.co/elasticsearch/elasticsearch:8.15.3
environment:
discovery.type: single-node
xpack.security.enabled: "false"
ports: ["9200:9200"]
# 业务进程挂 Agent（不改一行代码）
java -javaagent:/opt/skywalking-agent/skywalking-agent.jar \
-Dskywalking.agent.service_name=order-service \
-Dskywalking.collector.backend_service=127.0.0.1:11800 \
-jar order-service.jar
预期结果：UI http://localhost:8080 → General Service → order-service 出现；发起一次请求后，拓扑图出现 order-service → mysql 的边。
4. P95 与均值的选择（E-S16-007）
原文专门讲了 P95：均值会被长尾拉平，P95 才反映"大多数用户有多慢"。
| 指标 | 含义 | 什么时候看 |
|---|---|---|
| 均值 | 全部请求的算术平均 | ❌ 少看：一条 30s 的慢请求能把均值抬高，也能被大量快请求稀释 |
| P95 | 95% 的请求快于该值 | ✅ 用户体验的主指标 |
| P99 | 尾部延迟 | ✅ 容量与超时设置 |
| 最大值 | 单点极值 | 排障时看，不做 SLO |
判据：给接口定 SLO 时用 P95 + P99；只报均值等于隐藏了 5% 的用户体验。
5. 零侵入的代价（必须写清）
| 代价 | 具体表现 | 缓解 |
|---|---|---|
| 字节码增强兼容性 | 与某些框架/自定义类加载器冲突（如老版本 Dubbo、热部署） | 锁定 Agent 版本、灰度接入、保留开关 |
| 性能开销 | 常见 1–5% CPU/延迟增加（随拦截点数量上升） | 关闭不需要的插件、采样 |
| 启动变慢 | Agent 预加载插件 | 按需启用 plugin |
| 版本绑定 | Agent 版本需与 OAP 匹配（跨大版本可能不兼容） | 升级按"Agent→OAP→UI"顺序，先预发 |
| 数据量 | 全量 trace 存储成本高 | 采样 + 存储保留期（A01） |
判据：接入前后各跑一次压测，P95 增幅超过 5% 就要重新评估接入范围（只对核心服务开启）。
6. 与 Zipkin 的定位差异（为 A01 的选择做铺垫）
| 维度 | Zipkin | SkyWalking |
|---|---|---|
| 定位 | 纯链路追踪后端 | APM（链路+指标+拓扑+日志+profiling） |
| 接入方式 | 代码/依赖（Micrometer） | Agent（零代码）+ 也支持 OTel |
| 拓扑图 | ❌ 无 | ✅ 原生 |
| 存储 | 内存/ES/Cassandra | ES/BanyanDB/H2 |
| 运维复杂度 | 低 | 中（OAP + 存储 + UI） |
| 适合 | 中小规模、学习、纯追踪需求 | 中大型微服务、需要统一 APM |
一句话：只要"这次请求慢在哪"→ Zipkin；要"系统整体在发生什么"→ SkyWalking。
7. 常见误区
| 误区 | 纠正 |
|---|---|
| "零侵入=零成本" | 成本从代码转到运行时与运维（§5） |
| "Agent 装上就什么都有" | 需要匹配插件；自研 RPC/私有协议默认不识别 |
| "拓扑图能自动画对" | 依赖 service_name 一致与调用可识别（§2） |
| "SkyWalking 可以替代日志" | 日志仍是细节证据；SkyWalking 的 Logs 能力是"关联"，不是"替代" |
8. 自测
- 你的服务在拓扑图上是几个节点？多于实际服务数 →
service_name不一致。 - 接入 Agent 前后 P95 差多少？没测过 → 这就是接入评审缺的一项。
- 你的 SLO 写的是均值还是 P95？
9. 下一篇
S16-J04 · 排障实战：从告警到根因的四步 —— 指标、链路、日志、代码四条证据怎么排优先级，以及"先复现再修"的操作顺序。