【Skywalking从入门到精通】第03篇：SkyWalking架构全景图——四大组件的前世今生

上一篇【第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 AgentsJava Agent最成熟、功能最完整的探针通过JavaAgent机制字节码增强实现对应用的无侵入监控.NET Agent由社区贡献支持.NET CoreNode.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上报三类数据注册信息服务注册服务名、实例信息Tracing数据TraceSegment调用链路片段Metrics数据某些版本通过OAL计算生成上报协议使用gRPC这也是SkyWalking面向协议设计的体现。四、第二组件OAP Server观测分析平台OAP是SkyWalking的大脑全称Observability Analysis Platform可观测性分析平台。它是整个系统最复杂的组件内部由三大子模块构成子模块1Receiver数据接收层Receiver负责接收各种探针上报的数据。由于SkyWalking面向协议设计Receiver可以接收多种格式的数据Receiver类型处理的数据gRPC ReceiverJava/多语言探针的gRPC上报数据HTTP ReceiverHTTP方式上报的数据可选Kafka Receiver通过Kafka传输的数据可选Istio ReceiverIstio的Mixer/ALS数据Zipkin Receiver兼容Zipkin格式的数据子模块2流式计算内核OAL引擎这是OAP最精华的部分。接收到的原始Trace数据需要被聚合计算成各种指标某个服务的平均响应时间某个接口的P99延迟某个服务实例的错误率服务间的调用拓扑关系这些计算不能用关系数据库做因为数据量太大。SkyWalking设计了专有的OALObservability Analysis Language这是一种编译型DSL脚本语言用来定义如何对原始数据进行流式聚合计算。第七模块会详细讲OAP内部数据流 原始Trace → Receiver → OAL引擎 → Metrics结果 │ ├→ 服务指标 (响应时间/错误率) ├→ 实例指标 ├→ Endpoint指标 └→ 服务间拓扑关系子模块3查询内核GraphQL APIOAP对外提供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查询数据提供以下核心视图Dashboard仪表板展示服务/实例/Endpoint的实时性能指标Topology拓扑图服务间调用关系的有向图直观展示系统架构Trace视图Span瀑布图展示单次请求的完整调用链路告警面板显示触发的告警规则和历史告警性能剖析代码级别的性能热点分析SkyWalking 7历史上SkyWalking的UI经历了几次更替5.x版本原始UI功能简单6.0.0-GA后切换为RocketBot UIVue.js实现功能大幅增强9.x版本全新设计的SkyWalking UI现代化设计更好的交互体验七、三大设计原则快速预览四大组件是架构的骨三大设计原则是架构的魂┌─────────────────────────────────────────────────────────────┐ │ SkyWalking 三大设计原则 │ │ │ │ ┌───────────────┐ │ │ │ 面向协议设计 │ → 探针协议、查询协议全部预先定义 │ │ │ │ 多语言探针基于同一协议互通 │ │ └───────────────┘ │ │ │ │ ┌───────────────┐ │ │ │ 模块化设计 │ → Module Provider 的可插拔架构 │ │ │ │ 每个功能都可以替换、扩展 │ │ └───────────────┘ │ │ │ │ ┌───────────────┐ │ │ │ 轻量化设计 │ → 不依赖大数据技术栈 │ │ │ │ 自研轻量级流计算框架 │ │ └───────────────┘ │ └─────────────────────────────────────────────────────────────┘每一条设计原则背后都有深刻的工程考量下一篇会逐一展开。本篇小结SkyWalking的架构清晰地分为四层探针层多语言无侵入数据采集OAP层接收 → 流式计算 → 存储 对外查询存储层可插拔支持ES/MySQL/TiDB等多种后端UI层GraphQL驱动的可视化界面三大设计原则面向协议/模块化/轻量化贯穿所有组件设计决策是理解SkyWalking的核心钥匙。下一篇我们深入三大设计哲学看看每一条背后的具体工程决策和权衡取舍。上一篇【第02篇】APM和可观测性到底是啥——写给所有被这两个词搞懵的开发者下一篇【第04篇】SkyWalking的三大设计哲学——面向协议、模块化、轻量化