简介本资源是一个面向Java后端开发者与分布式系统运维人员的Spring Boot集成SkyWalking实战演示项目旨在解决微服务环境下链路追踪、性能监控与问题定位等核心痛点。项目完整呈现Trace、Span、Logs、Tags等SkyWalking核心概念的落地实践涵盖请求注入、跨服务传递、UI可视化配置等关键环节适合具备Spring Boot基础的中初级开发者快速上手APM监控体系。压缩包共13个文件包含2个核心Java启动类、2份Markdown说明文档含架构图与操作指南、6张关键界面截图如拓扑图、调用链、性能剖析页、1个pom.xml依赖配置、1个application.properties配置文件及1份LICENSE协议整体体积仅537KB轻量易部署。目前已有189人学习下载读者可直接导入IDE运行通过真实HTTP请求触发完整调用链直观掌握分布式追踪数据采集、上报与可视化分析全流程。1. 项目缘起为什么我们需要一个“演示项目”在微服务架构大行其道的今天一个服务背后可能牵扯着几十上百个模块一次用户请求的路径就像穿过一片茂密的森林你很难看清它究竟经过了哪些树木又在哪棵树下停留了太久。这就是分布式系统下的“可观测性”难题。作为开发者我们经常遇到这样的场景生产环境某个接口突然变慢从日志里看每个服务似乎都“岁月静好”但用户端就是卡顿。这时候传统的日志监控就显得力不从心你需要的是一个能绘制出完整请求链路、并能精准定位到瓶颈节点的“上帝视角”工具。SkyWalking 正是这样一个强大的 APM应用性能监控工具。它通过无侵入的探针技术自动收集、聚合和分析跨服务的调用链路、性能指标并以直观的拓扑图形式呈现。然而对于很多刚接触 SkyWalking 的开发者来说最大的障碍往往不是工具本身而是“如何把它跑起来”。官方文档虽然详尽但面对一个全新的技术栈从零开始搭建一个包含 SkyWalking Agent 的 Spring Boot 应用并配置好 Collector、UI再到最终看到一条完整的追踪链路这个过程充满了各种“小坑”。比如Agent 的启动参数怎么加依赖的 Jar 包版本如何匹配服务注册后发现 UI 上没数据怎么办因此一个开箱即用、配置完备的Spring Boot SkyWalking 演示项目的价值就凸显出来了。它不是一个复杂的业务系统而是一个精心设计的“脚手架”或“试验田”。它的核心目标只有一个让你在最短的时间内亲眼看到 SkyWalking 是如何工作的并理解其核心概念。你不需要从零开始构建业务逻辑只需要关注 SkyWalking 的集成与效果验证。这个.zip压缩包就是这样一个“快速启动包”它封装了环境、代码和配置让你能绕过繁琐的初始化步骤直接进入核心的观察与学习阶段。2. 演示项目核心内容拆解包里到底有什么一个合格的 SkyWalking 演示项目.zip文件其内容结构应该清晰、完整并且具备良好的可扩展性。它不仅仅是一堆代码的堆砌更是一个最佳实践的样板。下面我们来拆解一个典型演示项目应该包含的核心模块。2.1 项目骨架多模块的 Spring Boot 应用为了模拟真实的微服务调用场景演示项目通常会采用多模块的 Maven 或 Gradle 结构。一个最小化的演示可能包含两个服务一个上游服务如user-service和一个下游服务如order-service通过 HTTP 或 Feign 客户端进行调用。skywalking-demo/ ├── pom.xml (父工程统一管理依赖和插件) ├── user-service/ (用户服务模块) │ ├── src/ │ ├── pom.xml │ └── skywalking-agent/ (可选存放Agent文件) ├── order-service/ (订单服务模块) │ ├── src/ │ ├── pom.xml │ └── skywalking-agent/ └── README.md (项目说明、快速启动指南)为什么选择多模块单模块应用无法体现 SkyWalking 最核心的“分布式链路追踪”能力。通过两个独立部署的服务间调用才能生成跨越进程边界的 Trace追踪和 Span跨度从而在 SkyWalking UI 上展示出完整的调用链。这是理解 SkyWalking 价值的第一步。2.2 关键代码如何“制造”一条可追踪的链路演示项目的业务逻辑极其简单其核心目的是“制造”出清晰的调用关系以便观察。在user-service中通常会有一个 Controller例如UserController它提供一个接口比如/user/{id}/orders用于查询某个用户的订单列表。这个接口的实现会通过RestTemplate或OpenFeign去调用order-service的接口。// UserController.java RestController RequestMapping(/user) public class UserController { Autowired private OrderServiceClient orderServiceClient; // Feign客户端 GetMapping(/{userId}/orders) public ResponseEntityListOrder getUserOrders(PathVariable Long userId) { // 模拟一些本地处理生成一个本地Span log.info(查询用户 {} 的订单, userId); // 关键发起一个远程HTTP调用这将自动生成一个Exit Span出口跨度 ListOrder orders orderServiceClient.getOrdersByUserId(userId); return ResponseEntity.ok(orders); } }在order-service中对应的OrderController提供一个/orders接口处理来自上游的请求并可能模拟一次数据库查询通过 MyBatis 或 JPA。// OrderController.java RestController RequestMapping(/orders) public class OrderController { Autowired private OrderMapper orderMapper; GetMapping public ResponseEntityListOrder getOrdersByUserId(RequestParam Long userId) { // 这里会生成一个Entry Span入口跨度并与user-service传来的Trace上下文关联 log.info(接收查询用户 {} 订单的请求, userId); // 模拟数据库查询这会生成一个Local Span本地跨度 ListOrder orders orderMapper.selectByUserId(userId); // 为了演示更丰富的链路可以再模拟一个内部方法调用或睡眠 simulateProcessing(); return ResponseEntity.ok(orders); } private void simulateProcessing() { try { Thread.sleep(100); // 模拟耗时操作 } catch (InterruptedException e) { Thread.currentThread().interrupt(); } } }代码设计的意图这段简单的代码刻意构造了HTTP调用 - 数据库查询 - 内部方法的调用层次。这样在 SkyWalking 的追踪视图中你会看到一个清晰的树状结构一个 Trace 包含多个 SpanSpan 之间有父子关系并且每个 Span 都带有耗时信息。你能一眼看出时间主要消耗在哪个环节比如是网络调用慢还是数据库查询慢。2.3 灵魂配置SkyWalking Agent 的集成这是整个演示项目的核心。Spring Boot 应用本身并不感知 SkyWalking所有魔法都来自于一个独立的 Java Agent。演示项目需要提供清晰的 Agent 配置指南。Agent 文件准备项目zip包内可能会直接包含一个特定版本的skywalking-agent目录或者在其README.md中给出明确的下载链接。重要的是版本匹配例如 Spring Boot 2.x 应用通常对应 SkyWalking Java Agent 8.x 版本。启动脚本是关键你需要修改服务的启动命令无论是在 IDE 中还是命令行添加-javaagent参数。一个典型的启动脚本示例如下# 对于 user-service java -javaagent:/path/to/your/skywalking-agent/skywalking-agent.jar \ -Dskywalking.agent.service_nameuser-service-demo \ -Dskywalking.collector.backend_servicelocalhost:11800 \ -jar user-service/target/user-service-0.0.1-SNAPSHOT.jar # 对于 order-service java -javaagent:/path/to/your/skywalking-agent/skywalking-agent.jar \ -Dskywalking.agent.service_nameorder-service-demo \ -Dskywalking.collector.backend_servicelocalhost:11800 \ -jar order-service/target/order-service-0.0.1-SNAPSHOT.jar配置参数解读-javaagent指定 Agent Jar 包的绝对路径。这是启用 APM 功能的开关。-Dskywalking.agent.service_name定义该应用在 SkyWalking 中的服务名称。这是你在拓扑图上看到的节点名称务必为每个服务设置唯一且有意义的名字。-Dskywalking.collector.backend_service指向 SkyWalking OAPObservability Analysis Platform服务器的地址和 gRPC 端口默认11800。这意味着你的应用产生的追踪数据将被发送到这里进行存储和分析。注意很多初学者会忘记配置-javaagent参数导致应用启动正常但 SkyWalking UI 上始终看不到任何数据。请务必仔细检查启动命令。在 IDE如 IDEA中运行需要在Run/Debug Configuration的VM options里添加这些参数。2.4 基础设施一键启动的 Docker Compose为了让体验更丝滑一个优秀的演示项目往往会附带一个docker-compose.yml文件。这个文件的作用是一键拉起 SkyWalking 的后端服务包括SkyWalking OAP Server负责接收、聚合、分析从各个 Agent 上报的遥测数据。SkyWalking UI提供图形化界面用于查看拓扑图、链路追踪、性能指标等。存储后端通常是 Elasticsearch用于持久化存储所有数据。# docker-compose.yml 示例 version: 3.8 services: elasticsearch: image: docker.elastic.co/elasticsearch/elasticsearch:7.10.2 container_name: sw-es restart: always ports: - 9200:9200 environment: - discovery.typesingle-node - ES_JAVA_OPTS-Xms512m -Xmx512m - xpack.security.enabledfalse oap: image: apache/skywalking-oap-server:9.2.0 container_name: sw-oap depends_on: - elasticsearch restart: always ports: - 11800:11800 # gRPC端口用于接收Agent数据 - 12800:12800 # HTTP端口用于接收UI查询 environment: - SW_STORAGEelasticsearch - SW_STORAGE_ES_CLUSTER_NODESelasticsearch:9200 ui: image: apache/skywalking-ui:9.2.0 container_name: sw-ui depends_on: - oap restart: always ports: - 8080:8080 environment: - SW_OAP_ADDRESSoap:12800使用方式非常简单在项目根目录下执行docker-compose up -d等待片刻后访问http://localhost:8080就能看到 SkyWalking 的监控界面了。这避免了手动搭建 Elasticsearch 和配置 SkyWalking 的复杂过程让你能专注于应用和 Agent 的交互。3. 从启动到观测一次完整的追踪之旅现在假设你已经解压了.zip包配置好了 Agent并用 Docker Compose 启动了后端。接下来让我们走一遍从启动应用到在 UI 上看到数据的完整流程并理解其中每个环节的意义。3.1 启动服务并生成流量首先按照README.md的指引分别启动user-service和order-service。确保它们的 Agent 配置都指向了正确的 OAP 地址localhost:11800。服务启动后我们需要制造一些“流量”。最简单的方法就是使用curl命令或者 Postman 调用user-service的接口curl http://localhost:8081/user/123/orders多调用几次这个接口以便产生足够的数据供 SkyWalking 分析和展示。你也可以尝试在调用之间加入不同的延迟或者模拟错误的请求比如传一个不存在的 userId看看 SkyWalking 如何记录错误信息。3.2 登录 SkyWalking UI 并查看拓扑图打开浏览器访问http://localhost:8080即 Docker Compose 中 UI 服务的映射端口。首次进入你会看到一个干净的仪表盘。点击左侧菜单的“拓扑”。如果一切配置正确你应该能看到一个类似下图的拓扑结构[Browser] -- [user-service-demo] -- [order-service-demo]节点每个圆圈或方块代表一个你定义的服务service_name。颜色和大小可能反映其健康状态或流量。边箭头代表服务间的调用关系线条的粗细可能反映流量大小。仪表盘拓扑图上方或侧边通常有全局的请求量、成功率、响应时间等指标。这个拓扑图的价值在于它让你瞬间理解了系统的整体架构和依赖关系。对于一个新接手的复杂系统这个视图比任何文档都更直观。3.3 深入剖析查看追踪Trace详情拓扑图展示了“谁调用了谁”但具体一次调用发生了什么需要看追踪详情。点击user-service-demo和order-service-demo之间的连线或者在左侧菜单进入“追踪”页面。在追踪页面你可以设置查询条件如服务名、端点、时间范围然后会列出一系列追踪记录。点击其中一条你会进入详情视图。这里展示的就是我们之前通过代码构造的那条完整链路Trace ID: xxxxxxxx (全局唯一) Duration: 150ms (总耗时) --- Span 1: [Entry] GET:/user/{userId}/orders (user-service-demo) |-- Duration: 150ms |-- Tags: http.methodGET, http.status_code200 | |-- Span 2: [Exit] GET:http://order-service/orders (user-service-demo - order-service-demo) | |-- Duration: 120ms (网络调用下游处理总时间) | |-- Tags: peerorder-service-demo:8082, http.methodGET | | | |-- Span 3: [Entry] GET:/orders (order-service-demo) | | |-- Duration: 119ms | | |-- Tags: http.methodGET | | | | | |-- Span 4: [Local] simulateProcessing (order-service-demo) | | | |-- Duration: 100ms (模拟的耗时操作) | | | | | |-- Span 5: [Local] Database/MyBatis/selectByUserId (order-service-demo) | | |-- Duration: 15ms | | |-- Tags: db.statementSELECT * FROM orders WHERE user_id?如何解读这个视图层级关系清晰的缩进展示了 Span 的父子关系。Span 1是根 Span它调用了Span 2而Span 2对应下游服务的Span 3依此类推。耗时分析每个 Span 都有独立的耗时。你可以一眼看出总耗时 150ms 中有 120ms 花在了user-service调用order-service这个环节上。而在这 120ms 里又有 100ms 是order-service内部simulateProcessing方法消耗的。瓶颈定位瞬间完成。标签Tags包含了丰富的上下文信息如 HTTP 方法、状态码、数据库语句、对端地址等。这对于问题排查至关重要。日志Logs如果代码中通过 SkyWalking 的 API 打印了日志它们会附着在对应的 Span 上实现了链路与日志的关联。3.4 性能指标与告警初探除了链路追踪SkyWalking 还自动收集了大量性能指标。在“仪表盘”或各个服务的详情页你可以看到服务指标平均响应时间Avg Response Time、每分钟请求数CPM、成功率Success Rate等。实例指标JVM 内存使用率、GC 次数、CPU 使用率、线程状态等。端点指标某个特定 API 接口如/user/{id}/orders的响应时间分布慢、中、快、SLA服务等级协议等。你可以基于这些指标设置告警规则。例如当order-service的平均响应时间在 5 分钟内持续超过 500ms 时自动发送邮件或钉钉通知。虽然演示项目可能不包含告警配置但了解这个能力很重要它是 APM 工具从“事后排查”走向“事前预警”的关键。4. 超越演示将经验迁移到真实项目通过运行这个演示项目你已经直观地感受到了 SkyWalking 的核心能力。接下来我们要思考如何将这些经验应用到真实的 Spring Boot 项目中。这里有几个关键的实践点和避坑指南。4.1 Agent 的部署模式选择演示项目通常使用“Sidecar”模式即在每个应用启动命令中单独挂载 Agent。在生产环境中你有更多选择Sidecar 模式推荐每个应用实例独立配置 Agent。灵活性最高可以针对不同服务设置不同的采样率、插件配置等。适合容器化部署Kubernetes可以将 Agent 作为 Init Container 或直接打包进基础镜像。Java 启动参数全局配置在 Tomcat 或 JDK 的启动脚本中配置-javaagent对所有部署在该容器的应用生效。管理简单但缺乏灵活性。通过探针字节码增强工具如 ByteBuddy动态接入更高级的用法适合对启动参数有严格控制的云环境。实操建议对于微服务项目坚持使用 Sidecar 模式。在 Dockerfile 中将下载和配置 Agent 的步骤固化确保环境一致性。4.2 插件配置与自定义追踪SkyWalking Agent 通过一系列插件来支持不同的框架如 Spring MVC、Dubbo、Redis、MySQL、MyBatis 等。在skywalking-agent/config目录下的agent.config文件中可以启用或禁用插件。常见配置项agent.service_name服务名建议使用${SW_AGENT_NAME:your-service-name}格式支持环境变量注入便于在 Kubernetes 中配置。collector.backend_serviceOAP 集群地址。logging.levelAgent 自身日志级别排查问题时可以设为DEBUG。plugin.*.各种插件的开关例如plugin.mybatis.trace_sql_parameterstrue可以开启 MyBatis SQL 参数的记录注意隐私和安全。自定义追踪对于业务中非常重要的方法你可以使用 SkyWalking 的Trace注解或TraceContextAPI 进行手动埋点将其作为一个独立的 Local Span 展示在链路中。import org.apache.skywalking.apm.toolkit.trace.Trace; // ... Service public class ImportantService { Trace // 添加此注解该方法会在链路中显示为一个Span public void criticalBusinessLogic() { // ... 业务逻辑 } }4.3 生产环境考量与性能影响很多人会担心 Agent 的性能开销。SkyWalking 的 Agent 采用字节码增强技术在类加载时植入采集逻辑其开销主要来自CPU序列化数据和上报数据消耗少量 CPU。在采样率设置为 100%默认时对于超高 QPS 的服务可能有可感知的影响。可以通过降低采样率如设置agent.sample_n_per_3_secs-1并配置采样规则来平衡。内存Agent 本身占用约 20-50MB 的堆外内存。对于现代应用来说这个开销通常可以接受。网络 I/O数据上报到 OAP 会产生网络流量。确保 OAP 服务与应用部署在同一个可用区以减少延迟。性能调优建议采样率对于核心交易链路保持高采样率对于非核心或流量巨大的链路如健康检查、监控心跳可以降低采样率。缓冲区调整buffer相关配置控制内存中缓存的 Span 数量防止内存溢出。异步上报确保使用 gRPC 的异步上报模式避免阻塞业务线程。4.4 常见问题排查指南即使按照演示项目一步步来你也可能会遇到问题。这里列出几个高频问题问题一SkyWalking UI 上什么数据都没有。检查点1应用启动日志中是否有 SkyWalking Agent 相关的日志如 “SkyWalking agent started…”如果没有说明-javaagent参数未生效。检查点2OAP 服务是否健康运行docker-compose logs oap查看日志确认其成功连接了 Elasticsearch。检查点3Agent 配置的backend_service地址和端口是否正确能否从应用所在网络访问到 OAP 的 gRPC 端口默认11800可以用telnet命令测试。检查点4是否有网络策略或防火墙规则阻止了上报问题二有拓扑图但看不到详细的追踪信息。检查点1调用是否真的发生了确保你的测试请求触发了服务间的远程调用。检查点2追踪的采样率是否被修改过检查agent.config中的采样配置。检查点3调用链路是否过于简单或耗时极短SkyWalking 默认会过滤掉一些非常短的 Trace。可以尝试在代码中增加Thread.sleep来模拟耗时。问题三追踪信息中看不到 SQL 语句或 Redis 命令。检查点1对应的插件是否启用检查agent.config中plugin.mysql、plugin.redis等是否为true。检查点2使用的数据库驱动或客户端版本是否在插件支持范围内查看 SkyWalking 官方文档的插件支持列表。检查点3对于 MyBatis如果需要记录 SQL 参数需额外设置plugin.mybatis.trace_sql_parameterstrue。运行这个演示项目的最大收获不仅仅是学会了如何配置一个工具更是建立了一种“可观测性”的思维模式。下次当你面对一个线上性能问题时你的第一反应不再是盲目地翻看日志而是会思考“我能否通过链路追踪快速定位到是哪个服务、哪个方法、哪条 SQL 出了问题” 这个.zip包就像是一把钥匙为你打开了分布式系统监控的大门。在实际项目中你可以根据这个样板逐步将 SkyWalking 集成到你的开发、测试乃至生产环境中让它成为你保障系统稳定性的得力助手。本文还有配套的精品资源点击获取 Spring Boot集成SkyWalking演示项目：快速上手分布式链路追踪
简介本资源是一个面向Java后端开发者与分布式系统运维人员的Spring Boot集成SkyWalking实战演示项目旨在解决微服务环境下链路追踪、性能监控与问题定位等核心痛点。项目完整呈现Trace、Span、Logs、Tags等SkyWalking核心概念的落地实践涵盖请求注入、跨服务传递、UI可视化配置等关键环节适合具备Spring Boot基础的中初级开发者快速上手APM监控体系。压缩包共13个文件包含2个核心Java启动类、2份Markdown说明文档含架构图与操作指南、6张关键界面截图如拓扑图、调用链、性能剖析页、1个pom.xml依赖配置、1个application.properties配置文件及1份LICENSE协议整体体积仅537KB轻量易部署。目前已有189人学习下载读者可直接导入IDE运行通过真实HTTP请求触发完整调用链直观掌握分布式追踪数据采集、上报与可视化分析全流程。1. 项目缘起为什么我们需要一个“演示项目”在微服务架构大行其道的今天一个服务背后可能牵扯着几十上百个模块一次用户请求的路径就像穿过一片茂密的森林你很难看清它究竟经过了哪些树木又在哪棵树下停留了太久。这就是分布式系统下的“可观测性”难题。作为开发者我们经常遇到这样的场景生产环境某个接口突然变慢从日志里看每个服务似乎都“岁月静好”但用户端就是卡顿。这时候传统的日志监控就显得力不从心你需要的是一个能绘制出完整请求链路、并能精准定位到瓶颈节点的“上帝视角”工具。SkyWalking 正是这样一个强大的 APM应用性能监控工具。它通过无侵入的探针技术自动收集、聚合和分析跨服务的调用链路、性能指标并以直观的拓扑图形式呈现。然而对于很多刚接触 SkyWalking 的开发者来说最大的障碍往往不是工具本身而是“如何把它跑起来”。官方文档虽然详尽但面对一个全新的技术栈从零开始搭建一个包含 SkyWalking Agent 的 Spring Boot 应用并配置好 Collector、UI再到最终看到一条完整的追踪链路这个过程充满了各种“小坑”。比如Agent 的启动参数怎么加依赖的 Jar 包版本如何匹配服务注册后发现 UI 上没数据怎么办因此一个开箱即用、配置完备的Spring Boot SkyWalking 演示项目的价值就凸显出来了。它不是一个复杂的业务系统而是一个精心设计的“脚手架”或“试验田”。它的核心目标只有一个让你在最短的时间内亲眼看到 SkyWalking 是如何工作的并理解其核心概念。你不需要从零开始构建业务逻辑只需要关注 SkyWalking 的集成与效果验证。这个.zip压缩包就是这样一个“快速启动包”它封装了环境、代码和配置让你能绕过繁琐的初始化步骤直接进入核心的观察与学习阶段。2. 演示项目核心内容拆解包里到底有什么一个合格的 SkyWalking 演示项目.zip文件其内容结构应该清晰、完整并且具备良好的可扩展性。它不仅仅是一堆代码的堆砌更是一个最佳实践的样板。下面我们来拆解一个典型演示项目应该包含的核心模块。2.1 项目骨架多模块的 Spring Boot 应用为了模拟真实的微服务调用场景演示项目通常会采用多模块的 Maven 或 Gradle 结构。一个最小化的演示可能包含两个服务一个上游服务如user-service和一个下游服务如order-service通过 HTTP 或 Feign 客户端进行调用。skywalking-demo/ ├── pom.xml (父工程统一管理依赖和插件) ├── user-service/ (用户服务模块) │ ├── src/ │ ├── pom.xml │ └── skywalking-agent/ (可选存放Agent文件) ├── order-service/ (订单服务模块) │ ├── src/ │ ├── pom.xml │ └── skywalking-agent/ └── README.md (项目说明、快速启动指南)为什么选择多模块单模块应用无法体现 SkyWalking 最核心的“分布式链路追踪”能力。通过两个独立部署的服务间调用才能生成跨越进程边界的 Trace追踪和 Span跨度从而在 SkyWalking UI 上展示出完整的调用链。这是理解 SkyWalking 价值的第一步。2.2 关键代码如何“制造”一条可追踪的链路演示项目的业务逻辑极其简单其核心目的是“制造”出清晰的调用关系以便观察。在user-service中通常会有一个 Controller例如UserController它提供一个接口比如/user/{id}/orders用于查询某个用户的订单列表。这个接口的实现会通过RestTemplate或OpenFeign去调用order-service的接口。// UserController.java RestController RequestMapping(/user) public class UserController { Autowired private OrderServiceClient orderServiceClient; // Feign客户端 GetMapping(/{userId}/orders) public ResponseEntityListOrder getUserOrders(PathVariable Long userId) { // 模拟一些本地处理生成一个本地Span log.info(查询用户 {} 的订单, userId); // 关键发起一个远程HTTP调用这将自动生成一个Exit Span出口跨度 ListOrder orders orderServiceClient.getOrdersByUserId(userId); return ResponseEntity.ok(orders); } }在order-service中对应的OrderController提供一个/orders接口处理来自上游的请求并可能模拟一次数据库查询通过 MyBatis 或 JPA。// OrderController.java RestController RequestMapping(/orders) public class OrderController { Autowired private OrderMapper orderMapper; GetMapping public ResponseEntityListOrder getOrdersByUserId(RequestParam Long userId) { // 这里会生成一个Entry Span入口跨度并与user-service传来的Trace上下文关联 log.info(接收查询用户 {} 订单的请求, userId); // 模拟数据库查询这会生成一个Local Span本地跨度 ListOrder orders orderMapper.selectByUserId(userId); // 为了演示更丰富的链路可以再模拟一个内部方法调用或睡眠 simulateProcessing(); return ResponseEntity.ok(orders); } private void simulateProcessing() { try { Thread.sleep(100); // 模拟耗时操作 } catch (InterruptedException e) { Thread.currentThread().interrupt(); } } }代码设计的意图这段简单的代码刻意构造了HTTP调用 - 数据库查询 - 内部方法的调用层次。这样在 SkyWalking 的追踪视图中你会看到一个清晰的树状结构一个 Trace 包含多个 SpanSpan 之间有父子关系并且每个 Span 都带有耗时信息。你能一眼看出时间主要消耗在哪个环节比如是网络调用慢还是数据库查询慢。2.3 灵魂配置SkyWalking Agent 的集成这是整个演示项目的核心。Spring Boot 应用本身并不感知 SkyWalking所有魔法都来自于一个独立的 Java Agent。演示项目需要提供清晰的 Agent 配置指南。Agent 文件准备项目zip包内可能会直接包含一个特定版本的skywalking-agent目录或者在其README.md中给出明确的下载链接。重要的是版本匹配例如 Spring Boot 2.x 应用通常对应 SkyWalking Java Agent 8.x 版本。启动脚本是关键你需要修改服务的启动命令无论是在 IDE 中还是命令行添加-javaagent参数。一个典型的启动脚本示例如下# 对于 user-service java -javaagent:/path/to/your/skywalking-agent/skywalking-agent.jar \ -Dskywalking.agent.service_nameuser-service-demo \ -Dskywalking.collector.backend_servicelocalhost:11800 \ -jar user-service/target/user-service-0.0.1-SNAPSHOT.jar # 对于 order-service java -javaagent:/path/to/your/skywalking-agent/skywalking-agent.jar \ -Dskywalking.agent.service_nameorder-service-demo \ -Dskywalking.collector.backend_servicelocalhost:11800 \ -jar order-service/target/order-service-0.0.1-SNAPSHOT.jar配置参数解读-javaagent指定 Agent Jar 包的绝对路径。这是启用 APM 功能的开关。-Dskywalking.agent.service_name定义该应用在 SkyWalking 中的服务名称。这是你在拓扑图上看到的节点名称务必为每个服务设置唯一且有意义的名字。-Dskywalking.collector.backend_service指向 SkyWalking OAPObservability Analysis Platform服务器的地址和 gRPC 端口默认11800。这意味着你的应用产生的追踪数据将被发送到这里进行存储和分析。注意很多初学者会忘记配置-javaagent参数导致应用启动正常但 SkyWalking UI 上始终看不到任何数据。请务必仔细检查启动命令。在 IDE如 IDEA中运行需要在Run/Debug Configuration的VM options里添加这些参数。2.4 基础设施一键启动的 Docker Compose为了让体验更丝滑一个优秀的演示项目往往会附带一个docker-compose.yml文件。这个文件的作用是一键拉起 SkyWalking 的后端服务包括SkyWalking OAP Server负责接收、聚合、分析从各个 Agent 上报的遥测数据。SkyWalking UI提供图形化界面用于查看拓扑图、链路追踪、性能指标等。存储后端通常是 Elasticsearch用于持久化存储所有数据。# docker-compose.yml 示例 version: 3.8 services: elasticsearch: image: docker.elastic.co/elasticsearch/elasticsearch:7.10.2 container_name: sw-es restart: always ports: - 9200:9200 environment: - discovery.typesingle-node - ES_JAVA_OPTS-Xms512m -Xmx512m - xpack.security.enabledfalse oap: image: apache/skywalking-oap-server:9.2.0 container_name: sw-oap depends_on: - elasticsearch restart: always ports: - 11800:11800 # gRPC端口用于接收Agent数据 - 12800:12800 # HTTP端口用于接收UI查询 environment: - SW_STORAGEelasticsearch - SW_STORAGE_ES_CLUSTER_NODESelasticsearch:9200 ui: image: apache/skywalking-ui:9.2.0 container_name: sw-ui depends_on: - oap restart: always ports: - 8080:8080 environment: - SW_OAP_ADDRESSoap:12800使用方式非常简单在项目根目录下执行docker-compose up -d等待片刻后访问http://localhost:8080就能看到 SkyWalking 的监控界面了。这避免了手动搭建 Elasticsearch 和配置 SkyWalking 的复杂过程让你能专注于应用和 Agent 的交互。3. 从启动到观测一次完整的追踪之旅现在假设你已经解压了.zip包配置好了 Agent并用 Docker Compose 启动了后端。接下来让我们走一遍从启动应用到在 UI 上看到数据的完整流程并理解其中每个环节的意义。3.1 启动服务并生成流量首先按照README.md的指引分别启动user-service和order-service。确保它们的 Agent 配置都指向了正确的 OAP 地址localhost:11800。服务启动后我们需要制造一些“流量”。最简单的方法就是使用curl命令或者 Postman 调用user-service的接口curl http://localhost:8081/user/123/orders多调用几次这个接口以便产生足够的数据供 SkyWalking 分析和展示。你也可以尝试在调用之间加入不同的延迟或者模拟错误的请求比如传一个不存在的 userId看看 SkyWalking 如何记录错误信息。3.2 登录 SkyWalking UI 并查看拓扑图打开浏览器访问http://localhost:8080即 Docker Compose 中 UI 服务的映射端口。首次进入你会看到一个干净的仪表盘。点击左侧菜单的“拓扑”。如果一切配置正确你应该能看到一个类似下图的拓扑结构[Browser] -- [user-service-demo] -- [order-service-demo]节点每个圆圈或方块代表一个你定义的服务service_name。颜色和大小可能反映其健康状态或流量。边箭头代表服务间的调用关系线条的粗细可能反映流量大小。仪表盘拓扑图上方或侧边通常有全局的请求量、成功率、响应时间等指标。这个拓扑图的价值在于它让你瞬间理解了系统的整体架构和依赖关系。对于一个新接手的复杂系统这个视图比任何文档都更直观。3.3 深入剖析查看追踪Trace详情拓扑图展示了“谁调用了谁”但具体一次调用发生了什么需要看追踪详情。点击user-service-demo和order-service-demo之间的连线或者在左侧菜单进入“追踪”页面。在追踪页面你可以设置查询条件如服务名、端点、时间范围然后会列出一系列追踪记录。点击其中一条你会进入详情视图。这里展示的就是我们之前通过代码构造的那条完整链路Trace ID: xxxxxxxx (全局唯一) Duration: 150ms (总耗时) --- Span 1: [Entry] GET:/user/{userId}/orders (user-service-demo) |-- Duration: 150ms |-- Tags: http.methodGET, http.status_code200 | |-- Span 2: [Exit] GET:http://order-service/orders (user-service-demo - order-service-demo) | |-- Duration: 120ms (网络调用下游处理总时间) | |-- Tags: peerorder-service-demo:8082, http.methodGET | | | |-- Span 3: [Entry] GET:/orders (order-service-demo) | | |-- Duration: 119ms | | |-- Tags: http.methodGET | | | | | |-- Span 4: [Local] simulateProcessing (order-service-demo) | | | |-- Duration: 100ms (模拟的耗时操作) | | | | | |-- Span 5: [Local] Database/MyBatis/selectByUserId (order-service-demo) | | |-- Duration: 15ms | | |-- Tags: db.statementSELECT * FROM orders WHERE user_id?如何解读这个视图层级关系清晰的缩进展示了 Span 的父子关系。Span 1是根 Span它调用了Span 2而Span 2对应下游服务的Span 3依此类推。耗时分析每个 Span 都有独立的耗时。你可以一眼看出总耗时 150ms 中有 120ms 花在了user-service调用order-service这个环节上。而在这 120ms 里又有 100ms 是order-service内部simulateProcessing方法消耗的。瓶颈定位瞬间完成。标签Tags包含了丰富的上下文信息如 HTTP 方法、状态码、数据库语句、对端地址等。这对于问题排查至关重要。日志Logs如果代码中通过 SkyWalking 的 API 打印了日志它们会附着在对应的 Span 上实现了链路与日志的关联。3.4 性能指标与告警初探除了链路追踪SkyWalking 还自动收集了大量性能指标。在“仪表盘”或各个服务的详情页你可以看到服务指标平均响应时间Avg Response Time、每分钟请求数CPM、成功率Success Rate等。实例指标JVM 内存使用率、GC 次数、CPU 使用率、线程状态等。端点指标某个特定 API 接口如/user/{id}/orders的响应时间分布慢、中、快、SLA服务等级协议等。你可以基于这些指标设置告警规则。例如当order-service的平均响应时间在 5 分钟内持续超过 500ms 时自动发送邮件或钉钉通知。虽然演示项目可能不包含告警配置但了解这个能力很重要它是 APM 工具从“事后排查”走向“事前预警”的关键。4. 超越演示将经验迁移到真实项目通过运行这个演示项目你已经直观地感受到了 SkyWalking 的核心能力。接下来我们要思考如何将这些经验应用到真实的 Spring Boot 项目中。这里有几个关键的实践点和避坑指南。4.1 Agent 的部署模式选择演示项目通常使用“Sidecar”模式即在每个应用启动命令中单独挂载 Agent。在生产环境中你有更多选择Sidecar 模式推荐每个应用实例独立配置 Agent。灵活性最高可以针对不同服务设置不同的采样率、插件配置等。适合容器化部署Kubernetes可以将 Agent 作为 Init Container 或直接打包进基础镜像。Java 启动参数全局配置在 Tomcat 或 JDK 的启动脚本中配置-javaagent对所有部署在该容器的应用生效。管理简单但缺乏灵活性。通过探针字节码增强工具如 ByteBuddy动态接入更高级的用法适合对启动参数有严格控制的云环境。实操建议对于微服务项目坚持使用 Sidecar 模式。在 Dockerfile 中将下载和配置 Agent 的步骤固化确保环境一致性。4.2 插件配置与自定义追踪SkyWalking Agent 通过一系列插件来支持不同的框架如 Spring MVC、Dubbo、Redis、MySQL、MyBatis 等。在skywalking-agent/config目录下的agent.config文件中可以启用或禁用插件。常见配置项agent.service_name服务名建议使用${SW_AGENT_NAME:your-service-name}格式支持环境变量注入便于在 Kubernetes 中配置。collector.backend_serviceOAP 集群地址。logging.levelAgent 自身日志级别排查问题时可以设为DEBUG。plugin.*.各种插件的开关例如plugin.mybatis.trace_sql_parameterstrue可以开启 MyBatis SQL 参数的记录注意隐私和安全。自定义追踪对于业务中非常重要的方法你可以使用 SkyWalking 的Trace注解或TraceContextAPI 进行手动埋点将其作为一个独立的 Local Span 展示在链路中。import org.apache.skywalking.apm.toolkit.trace.Trace; // ... Service public class ImportantService { Trace // 添加此注解该方法会在链路中显示为一个Span public void criticalBusinessLogic() { // ... 业务逻辑 } }4.3 生产环境考量与性能影响很多人会担心 Agent 的性能开销。SkyWalking 的 Agent 采用字节码增强技术在类加载时植入采集逻辑其开销主要来自CPU序列化数据和上报数据消耗少量 CPU。在采样率设置为 100%默认时对于超高 QPS 的服务可能有可感知的影响。可以通过降低采样率如设置agent.sample_n_per_3_secs-1并配置采样规则来平衡。内存Agent 本身占用约 20-50MB 的堆外内存。对于现代应用来说这个开销通常可以接受。网络 I/O数据上报到 OAP 会产生网络流量。确保 OAP 服务与应用部署在同一个可用区以减少延迟。性能调优建议采样率对于核心交易链路保持高采样率对于非核心或流量巨大的链路如健康检查、监控心跳可以降低采样率。缓冲区调整buffer相关配置控制内存中缓存的 Span 数量防止内存溢出。异步上报确保使用 gRPC 的异步上报模式避免阻塞业务线程。4.4 常见问题排查指南即使按照演示项目一步步来你也可能会遇到问题。这里列出几个高频问题问题一SkyWalking UI 上什么数据都没有。检查点1应用启动日志中是否有 SkyWalking Agent 相关的日志如 “SkyWalking agent started…”如果没有说明-javaagent参数未生效。检查点2OAP 服务是否健康运行docker-compose logs oap查看日志确认其成功连接了 Elasticsearch。检查点3Agent 配置的backend_service地址和端口是否正确能否从应用所在网络访问到 OAP 的 gRPC 端口默认11800可以用telnet命令测试。检查点4是否有网络策略或防火墙规则阻止了上报问题二有拓扑图但看不到详细的追踪信息。检查点1调用是否真的发生了确保你的测试请求触发了服务间的远程调用。检查点2追踪的采样率是否被修改过检查agent.config中的采样配置。检查点3调用链路是否过于简单或耗时极短SkyWalking 默认会过滤掉一些非常短的 Trace。可以尝试在代码中增加Thread.sleep来模拟耗时。问题三追踪信息中看不到 SQL 语句或 Redis 命令。检查点1对应的插件是否启用检查agent.config中plugin.mysql、plugin.redis等是否为true。检查点2使用的数据库驱动或客户端版本是否在插件支持范围内查看 SkyWalking 官方文档的插件支持列表。检查点3对于 MyBatis如果需要记录 SQL 参数需额外设置plugin.mybatis.trace_sql_parameterstrue。运行这个演示项目的最大收获不仅仅是学会了如何配置一个工具更是建立了一种“可观测性”的思维模式。下次当你面对一个线上性能问题时你的第一反应不再是盲目地翻看日志而是会思考“我能否通过链路追踪快速定位到是哪个服务、哪个方法、哪条 SQL 出了问题” 这个.zip包就像是一把钥匙为你打开了分布式系统监控的大门。在实际项目中你可以根据这个样板逐步将 SkyWalking 集成到你的开发、测试乃至生产环境中让它成为你保障系统稳定性的得力助手。本文还有配套的精品资源点击获取