springCloud二-SkyWalking-安装部署-术语介绍
提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档
文章目录
- 前言
- 1. 链路追踪介绍
- 1.1 什么是链路追踪
- 1.2 链路追踪的作⽤
- 2. 为什么选择SkyWalking
- 2.1 ZipKin
- 2.2 CAT
- 2.3 SkyWalking
- 2.4 对比
- 3. 术语介绍
- 3.1 APM
- 3.2 OAP
- 3.3 Agent
- 3.4 UI
- 3.5 Metrics
- 3.6 Endpoint
- 4. 安装部署
- 4.1 下载安装SkyWalking
- 4.1.1 下载
- 4.2 数据库选型及配置
- 4.2.1 H2
- 4.2.2 Mysql
- 4.2.3 Elasticsearch
- 4.2.3 BanyanDB
- 4.3 修改配置
- 4.3.1 配置探针
- 4.3.2 修改端⼝号(按需)
- 4.3.3 创建数据库
- 4.3.4 修改存储后端为MySQL
- 4.3.5 启动SkyWalking
- 总结
前言
1. 链路追踪介绍
在分布式系统中, ⼀次请求往往会经过多个服务节点. ⽐如⼀次简单的⽤⼾下单请求, 可能涉及⽹关, 商品服务, 库存服务, ⽀付服务、消息队列等多个环节. 这些服务节点可能是不同团队开发, 部署在不同的服务器上, 甚⾄可能使⽤不同的编程语⾔编写. 在这⼀系列的调⽤中, 可能有串⾏的, 也有并⾏的
在分布式系统中, 我们可能会遇到⼀些问题, ⽐如:
- 这个请求经过了哪些服务节点
- 这些服务节点有什么样的依赖关系
- 各个服务接⼝的性能是如何的
- 如何快速的串联整个链路, 并定位问题
这就涉及到了链路追踪.
谁调用了我这个服务—》不清楚的
比较清楚的是我调用了哪个服务
1.1 什么是链路追踪
链路追踪是分布式系统中跟踪请求全流程的技术, 通过记录请求在多个服务间的流转路径, 耗时, 状态等信息, 形成完整的调⽤链视图. 也就是将⼀次分布式请求的调⽤情况集中进⾏展⽰. 其核⼼是通过唯⼀标识( TraceID )串联跨服务的调⽤单元( Span )，并借助上下⽂传递（ Context ）实现链路连续性.
核⼼概念
• Trace：代表⼀次完整的请求处理过程, 从请求到响应结束. 由多个 Span 组成
• TraceID: 每个Trace有⼀个唯⼀的 Trace ID来标识, ⽤于关联跨服务的⽇志和监控数据
• Span：Trace的基本单元. 代表请求在单个服务节点上的处理过程(如下单, ⽀付, 数据库查询等), 包含操作名称, 耗时等数据。
Trace: 整个物流链路
TraceID: 快递单号
Span: 包裹每经过⼀个转运中⼼, 就会⽣成⼀个记录, 记录包裹到达时间, 状态等信息, 所有span通过TraceId关联, 最终形成快递的物流轨迹
1.2 链路追踪的作⽤
-
保障系统可⽤性与稳定性
分布式系统中, 服务依赖的复杂性使得局部故障可能迅速扩散. 链路追踪⼯具会通过实时采集CPU、内存、请求成功率等指标, 可主动发现异常, 并在达到阈值时触发告警. 帮助团队在⽤⼾感知前介⼊处理，避免系统雪崩. -
优化性能与资源利⽤率
链路追踪⼯具通过记录请求的完整调⽤链(Trace), 将每个服务节点的处理耗时可视化. 这种细粒度分析帮助开发者精准识别慢调⽤(如服务 A 的 HTTP 请求耗时占⽐ 80%)并进⾏优化.记录每个节点耗时时间–》可视化–》找出慢调用 -
提升故障排查效率
传统⽇志排查需在多台服务器间⼈⼯拼接线索, 耗时且易遗漏关键信息. 追踪⼯具为每个请求分配唯⼀Trace ID, 将跨服务的⽇志, 错误信息关联为统⼀视图, 帮助快速定位故障节点（如识别数据库查询超时或第三⽅接⼝异常） -
理解服务依赖与拓扑
分布式系统服务依赖关系动态变化, ⼈⼯维护依赖图谱成本⾼, 可以借助链路追踪⼯具⾃动⽣成服务拓扑图, 展⽰服务间调⽤频率与成功率，辅助容量规划与架构治理.
2. 为什么选择SkyWalking
链路追踪这个技术已经⽐较成熟了, 市⾯上也有很多链路追踪的产品, 接下来介绍⼏种业界主流的链路追踪产品
• Zipkin
• CAT
• SkyWalking
2.1 ZipKin
Zipkin 是由Twitter开发并开源的⼀款分布式链路追踪产品, 基于Google的Dapper论⽂设计, 旨在帮助开发者监控和排查微服务架构中的请求链路问题.
开源地址: GitHub - openzipkin/zipkin: Zipkin is a distributed tracing system
开源地址
⽬前GitHub收获17.2K+ Star, 3100+ Forks, 被全球上百家公司采⽤, 覆盖电商, ⾦融, 云计算等多个⾏业.
2.2 CAT
CAT（Central Application Tracking）是⼀个⽐较早的分布式监控产品, 是美团点评在2011年底基于Java 开发的⼀套开源的分布式实时监控系统, ⽬前已经覆盖了美团点评的外卖, 酒旅, 出⾏, ⾦融等核⼼业务线, ⼏乎已经接⼊美团点评的所有核⼼应⽤.
CAT简介
CAT的原型和理念来源于eBay的CAL系统(CAL是eBay平台的⽇志服务, 主要负责存储⽇志数据, 并提供检索, 聚合, 分析等功能), CAT 不仅增强了CAL的系统核⼼模型, 还添加了丰富的报表
CAT⾃从2014年开源, GitHub收获18.9K+ Star, 5400+ Forks, 被 100+公司企业使⽤，其中不乏携程, 陆⾦所, 猎聘⽹, 平安等业内知名公司.
2.3 SkyWalking
Apache SkyWalking 是由个⼈吴晟(华为开发者)于2015年发起的开源应⽤性能监控(APM)系统, 于2017年进⼊ Apache 孵化器, 成为国内⾸个由个⼈主导进⼊ Apache 的开源项⽬, 并于2019年正式毕业成为Apache 顶级项⽬, 标志着其技术成熟度与社区认可度达到新⾼度. 其发展轨迹从个⼈项⽬逐步演变为全球顶级的分布式系统监控解决⽅案，背后离不开开源社区的持续贡献(如华为、阿⾥巴巴等企业的⽀持).
SkyWalking 专为微服务及分布式架构设计, 现已成为全球领先的可观测性解决⽅案. 特点是⽀持多种插件，UI功能较强，接⼊端⽆代码侵⼊. ⽬前GitHub收获24.3 K+ Star, 6600+ Forks, 被全球多家知名企业应⽤于⽣产环境.
SkyWalking官网
2.4 对比
综上:
Zipkin 适合需要快速搭建链路追踪的中⼩型团队, 对深度监控和业务分析⽀持有限
CAT 适合中⼤企业, 对报表以及监控粒度要求较⾼
SkyWalking 综合实⼒较强, ⽆侵⼊, 多语⾔且性能较优, ⾃⾝包含⽐较丰富的报表及告警⽀持, 并且⽀持插件定制开发(难度较⼤)
3. 术语介绍
3.1 APM
APM: Application Performance Monitor, 应⽤性能监控. APM 指通过收集, 分析和可视化应⽤程序的运⾏时数据（如响应时间、吞吐量、错误率等）, 帮助开发者和运维团队优化系统性能的技术体系. 上述CAT 和 SkyWalking 就是APM⼯具
3.2 OAP
OAP: Observability Analysis Platform, 观测分析平台.
SkyWalking的架构通常包括三个主要组件: 探针(Agent), 后端(Backend) 和前端(UI). 其中OAP是后端的重要组成部分, 负责接收、处理、存储来⾃探针的可观测性数据，并⽣成聚合指标.
探针来收集应用程序的数据，给后端，后端来加工进行数据分析，前端来展示
3.3 Agent
Agent: 探针. 轻量级数据采集组件, 通过字节码植⼊技术（Bytecode Instrumentation）⽆侵⼊式收集应⽤程序的运⾏时数据. SkyWalking提供了Java, Python, Go, NodeJS, PHP等语⾔的探针
3.4 UI
UI: 可视化界⾯.
通过 RESTful API 从 OAP 获取数据, ⽀持图表化展⽰与交互式筛选, 提供 Web 控制台，展⽰服务拓扑、调⽤链路、实时指标、告警信息等.
3.5 Metrics
Metrics: 指标, ⽐如服务响应时间, 服务成功率等
3.6 Endpoint
Endpoint: 服务实例中⽤于接收和处理外部请求的具体⼊⼝点，是⽐service更细粒度的监控单元, ⽤于描述服务内部的接⼝或⽅法级别的访问路径.—》可以理解为接口
4. 安装部署
4.1 下载安装SkyWalking
4.1.1 下载
官网下载地址
分别下载：SkyWalking APM（10.2.0） 和 Java Agent（9.4.0）
从8.8.0之后, agent和apm的安装分开了, 需要分开安装apm和agent
APM我们使用的是10.2.0版本
点击tar就可以下载了
我们选择的是java版本的agent，版本的9.4.0
往下滑，这个Archive repository是历史版本的发布
直接点击这个下载
安装好之后，打开apm，打开bin
startup.bat就是WIndows的启动程序
但是双击之后还是不能启动
为什么呢
因为在2025年之前，SkyWalking的默认存储是H2
H2存储其实就是内存模式，就是用内存存储，不需要安装什么东西–》服务重启数据就会丢失
4.2 数据库选型及配置
4.2.1 H2
⾃ 2015 年以来，H2 ⼀直作为 SkyWalking 的默认存储选项, 旨在简化⽤⼾⾸次安装的体验. 其内存模式为⽤⼾提供了⼀种⽆需额外配置即可本地快速上⼿的⽅式, ⾮常适合学习, 但是在⽣产环境⾮常受限,⽐如H2 的内存模式通常会在运⾏⼤约 20 分钟后丢失数据, 更糟糕的是，这种⾏为没有任何预警，导致⽆法⻓期使⽤. 所以官⽅从2025年宣布H2 将不再作为存储选项被⽀持. 取⽽代之的是BanyanDB
2025 年的首次公告：永久移除 H2 存储选项
4.2.2 Mysql
Skywalking⼀直⽀持MySQL为存储选项, MySQL对于中⼩规模的数据友好, 部署和运维成本低, 适合已有MySQL基础设施的团队, 但是分库分表复杂度⾼, ⽆法适应千亿级数据的分布式存储需求. 但对时间序列数据的聚合查询效率远低于 ES, 复杂查询易成为瓶颈. 适合学习和测试环境, 或者数据量极⼩的环境.
4.2.3 Elasticsearch
在2025年之前, ES⼀直作为官⽅推荐的⽣产环境使⽤的存储选项, ES基于倒排索引和分⽚机制, 擅⻓处理海量时序数据的查询与聚合分析, 可通过集群分⽚应对 PB 级数据存储需求. ⽽且社区⽀持⼴泛, 但是ES的运维成本较⾼, 需要独⽴部署ES集群, 对资源消耗⼤, 使得ES的性价⽐不是很⾼.
4.2.3 BanyanDB
BanyanDB脱胎于SkyWalking社区，主要⾯向APM领域, 专为处理 Metrics（指标）、Tracing（追踪）、Logging（⽇志） 三类可观测性数据设计. BanyanDB 专为云原⽣架构设计, 能够处理更⼤的⼯作负载，⽆需担⼼数据丢失,⽽且设置⾮常简单，降低了新⽤⼾的使⽤⻔槛.
作为SkyWalking的原⽣数据库, BanyanDB⽬前还处于⾼速研发的阶段. 随着BanyanDB⼦项⽬的不断发展, SkyWalking官⽅宣布, BanyanDB 0.8已经完全⽣产可⽤, 是⽣产环境的理想选择.
从0到1打造开源项目BanyanDB
所以说BanyanDB这个数据库就是专门用于APM的
考虑到ES和BanyanDB具备⼀定的学习成本, 并且作为存储选项, MySQL与其他存储后端(如Elasticsearch)有⼀致的⾏为, 学习阶段的数据量不是很⼤, 我们优先使⽤MySQL来进⾏讲解
4.3 修改配置
4.3.1 配置探针
SkyWalking启动只和apm有关
但是想要监控应用程序的话，就要启动探针—》agent
我们在apm里面创建文件夹agent
然后把skywalking-agent里面的数据放入apache-skywalking-apm-bin/agent中
4.3.2 修改端⼝号(按需)
SkyWalking UI的默认端⼝号是 8080, 如果和现有进程冲突了, 可以进⾏修改.
修改⽂件: /apache-skywalking-apm-bin/webapp/application.yml
修改为8902
4.3.3 创建数据库
CREATE DATABASE skywalking;
只需要创建数据库就可以了，表不用管,因为我们的SkyWalking会自动帮我们创建的
4.3.4 修改存储后端为MySQL
连接mysql需要在 /apache-skywalking-apm-bin/oap-libs 这个⽬录下放入mysql-connector-java 的包
找到很简单，项目只要引入了mysql，都会有mysql驱动的
比如这个
放入/apache-skywalking-apm-bin/oap-libs
修改存储配置
配置⽂件路径: /apache-skywalking-apm-bin/config/application.yml
找到storage:开头的
默认数据库是banyandb，配置为mysql
storage:selector: ${SW_STORAGE:mysql}
看这个代码
如果使用banyandb的话，那么就去找bydb.yaml，banyandb的配置信息在bydb.yaml里面
如果选择elasticsearch，
那么就在这个文件里面把这些配置好就可以了
如果选择数据库，就在application.yml里面把这些配置好就可以了
storage:mysql:properties:jdbcUrl: ${SW_JDBC_URL:"jdbc:mysql://localhost:3306/skywalking?rewriteBatchedStatements=true&allowMultiQueries=true"}dataSource.user: ${SW_DATA_SOURCE_USER:root}dataSource.password: ${SW_DATA_SOURCE_PASSWORD:123456}dataSource.cachePrepStmts: ${SW_DATA_SOURCE_CACHE_PREP_STMTS:true}dataSource.prepStmtCacheSize: ${SW_DATA_SOURCE_PREP_STMT_CACHE_SQL_SIZE:250}dataSource.prepStmtCacheSqlLimit: ${SW_DATA_SOURCE_PREP_STMT_CACHE_SQL_LIMIT:2048}dataSource.useServerPrepStmts: ${SW_DATA_SOURCE_USE_SERVER_PREP_STMTS:true}metadataQueryMaxSize: ${SW_STORAGE_MYSQL_QUERY_MAX_SIZE:5000}maxSizeOfBatchSql: ${SW_STORAGE_MAX_SIZE_OF_BATCH_SQL:2000}asyncBatchPersistentPoolSize: ${SW_STORAGE_ASYNC_BATCH_PERSISTENT_POOL_SIZE:4}
只需要改数据库名，账户名和密码就可以了
4.3.5 启动SkyWalking
启动⽂件: /apache-skywalking-apm-bin/bin/startup.bat
双击运⾏
这里启动了两个
Skywalking-oap-server 服务(OAP模块的实际运⾏实例)启动后会暴露11800 和12800 两个端⼝
11800: grpc端⼝, 接受SkyWalking Agent 的监控数据—》接收应用程序的数据
12800: REST API端⼝, 提供 RESTful API 服务, 供 SkyWalking UI 或其他外部系统调⽤, ⽤于查询监控数据，，，，ui要从oap拿到数据，调用12800端口号
8902是UI界面的端口号
直接访问http://127.0.0.1:8902/
这样就显示成功了
然后数据库中也生成了很多的表