skywalking前端_不懂什么是Skywalking?看这吧!

SkyWalking是一个由吴晟开发的国产开源APM工具,专注于微服务、云原生架构的性能监控。它遵循OpenTracing规范,提供分布式追踪、服务网格遥测分析等功能。与其他实现如Jaeger、Zipkin相比,SkyWalking支持告警、JVM监控,更适合SpringCloud和Dubbo集成。本文将介绍SkyWalking的概念、安装部署、SpringCloud整合以及架构设计。

思维导图

e2ae0e10b8d7d5d537db49d8873469c8.png

文章已收录Github精选,欢迎Star:https://github.com/yehongzhi/learningSummary

概述

skywalking又是一个优秀的国产开源框架,2015年由个人吴晟(华为开发者)开源 , 2017年加入Apache孵化器。

skywalking是分布式系统的应用程序性能监视工具,专为微服务、云原生架构和基于容器(Docker、K8s、Mesos)架构而设计。SkyWalking 是观察性分析平台和应用性能管理系统。提供分布式追踪、服务网格遥测分析、度量聚合和可视化一体化解决方案(官网介绍)。

一、OpenTracing规范

OpenTracing是一种分布式系统链路跟踪的设计原则、规范、标准。

类似JDBC的规范,主要为了提供一套标准的JDBC API。OpenTracing也是一样,是为了统一提供一套链路追踪的标准API,所制定的一种规范。

OpenTracing通过提供平台无关、厂商无关的API,使得开发人员能够方便的添加(或更换)追踪系统的实现。

类似于JDBC的规范由各个数据库厂商实现一样,OpenTracing规范也是有很多实现的产品,下面介绍一下落地的产品。

1.1 实现OpenTracing的产品

Jaeger:Jaeger是由Uber公司开源发布的,受到Dapper和OpenZipkin启发。后端使用Go语言,前端(用户界面)使用React 。优点是上传采用的是udp传输,效率高速度快。缺点就是丢包,影响了整条调用链,而且不支持告警和JVM监控。

Zipkin:SpringCloud官方推荐,可以与SpringCloud有良好集成,实现方式是拦截请求,发送(http)数据到zipkin服务。缺点在于不支持告警,不支持JVM监控,通信方式使用Http请求向Zipkin上报信息,比较耗性能

SkyWalking:国人(吴晟)开发,支持dubbo,SpringCloud,SpringBoot集成,代码无侵入,通信方式采用GRPC,性能较好,实现方式是java探针,支持告警,支持JVM监控,支持全局调用统计等等,功能较完善。缺点是依赖较多,需要ElasticSearch,JDK环境,Nacos注册中心等。

1.2 skywalking的特点

5b47c34043595cbb16eded06a7ee1819.png

比较重要的特点,我觉得是轻量高效,对代码无侵入性。对于微服务,支持dubbo,SpringBoot,SpringCloud集成。

二、安装部署

环境:CentOS 7.5,MySQL 5.7.26,Nacos 1.3.1(注册中心),JDK 1.8,skywalking 8.1.0

除了skywalking之外,其他需要用到的组件我就不介绍怎么安装了,比较简单。安装skywalking其实很简单,下面一步一步来讲解。

第一步,下载。在官网下载即可,选择8.1.0版本,如果要使用ES作为存储仓库,那就要选择es7的版本。

5e537b9a03086499082e771037ac8979.png

第二步,解压。找到config目录下的application.yml文件,然后修改配置。

5660f303edfb700f99e8476a95fe015d.png

需要修改的配置内容如下:

cluster:
  selector: ${SW_CLUSTER:nacos}
  #单机模式
  standalone:
  #使用nacos作为注册中心
  nacos:
    # 注册到nacos的服务名
    serviceName: ${SW_SERVICE_NAME:"SkyWalking_OAP_Cluster"}
    #nacos服务端的地址
    hostPort: ${SW_CLUSTER_NACOS_HOST_PORT:192.168.0.105:8848}
    # Nacos Configuration namespace命名空间
    namespace: ${SW_CLUSTER_NACOS_NAMESPACE:"public"}
core:
  selector: ${SW_CORE:default}
  default:
    #skywalking服务端的REST绑定的IP
    restHost: ${SW_CORE_REST_HOST:192.168.0.107}
    #skywalking服务端的REST调用的端口
    restPort: ${SW_CORE_REST_PORT:12800}
    #skywalking服务端GRPC通信绑定的IP
    gRPCHost: ${SW_CORE_GRPC_HOST:192.168.0.107}
    #skywalking服务端GRPC通信绑定的端口
    gRPCPort: ${SW_CORE_GRPC_PORT:11800}
storage:
  #选择使用mysql
  selector: ${SW_STORAGE:mysql}
  #默认使用h2,不会持久化,重启skyWalking之前的数据会丢失
  h2:
    driver: ${SW_STORAGE_H2_DRIVER:org.h2.jdbcx.JdbcDataSource}
    url: ${SW_STORAGE_H2_URL:jdbc:h2:mem:skywalking-oap-db}
    user: ${SW_STORAGE_H2_USER:sa}
    metadataQueryMaxSize: ${SW_STORAGE_H2_QUERY_MAX_SIZE:5000}
  #使用mysql作为持久化存储的仓库
  mysql:
    properties:
      #数据库连接地址
      jdbcUrl: ${SW_JDBC_URL:"jdbc:mysql://192.168.0.107:3306/swtest"}
      #用户名
      dataSource.user: ${SW_DATA_SOURCE_USER:yehongzhi}
      #密码
      dataSource.password: ${SW_DATA_SOURCE_PASSWORD:Yehongzhi520.}

默认是web管理界面是8080端口,如果要修改端口号,可以修改webapp目录下的webapp.yml。

#web管理界面的端口
server:
  port: 8080

第三步,添加mysql数据驱动包。因为在lib目录下是没有mysql数据驱动包的,所以修改完配置启动是会报错,启动失败的。为什么作者不提前在lib目录下放一个数据驱动包呢,还要我们手动去添加。网上貌似没有这个问题的讨论,我的理解是因为框架不知道你用的是什么版本的mysql数据库,所以不知道放什么版本的数据库驱动包,使用者用的是什么版本的mysql,就自己放对应的数据库驱动包

我这里用的是5.7.26版本的mysql,所以我下载了一个8.0.17的驱动包,添加到/oap-libs目录下。

3a500364c3ccc1f0c3f9fd20e266191e.png

第三步,启动。在/bin目录上一级,直接使用./bin/startup.sh启动即可。启动之后,可以使用jps命令查看进程,可以看到这两个java程序在运行状态。

9976d31a20c46bab4499492034ffce91.png

打开配置的Nacos控制台,可以看到服务列表注册了名为“SkyWalking_OAP_Cluster”的服务。

eb31521d0535bc85365be86631568b94.png

可以看到mysql建了很多表。

ece0ac9cd102dda54d451af958924817.png

说明启动成功了,打开配置对应的地址http://192.168.0.109:8080/,可以看到skywalking的web界面。

a8083019d61f09af307d350a031c94a3.png

三、整合SpringCloud工程

整合其实很简单,不需要引入依赖,也不需要添加任何代码,我们只需要在启动jar包时配置参数即可。

-javaagent:D:\apache-skywalking-apm-bin-es7\agent\skywalking-agent.jar
-Dskywalking.agent.service_name=consumer
-Dskywalking.collector.backend_service=192.168.0.109:11800
#解释一下上面这三个参数的意思
#-javaagent:填的是skywalking-agent.jar的本地磁盘的路径
#-Dskywalking.agent.service_name:在skywalking上显示的服务名
#-Dskywalking.collector.backend_service:skywalking的collector服务的IP及端口

我们一般用IDEA开发就这样设置即可。

1a48b5fd7deea5225581bf56c8b157df.png

接下来我按照这个配置,启动一个Consumer工程和Provider工程,并且注册到Nacos注册中心。

45959f756f54a5f080e33d7d73a6e39f.png

然后使用Consumer工程的接口调用Provider工程的接口,可以看到调用链的效果。

6c5ef4b83c282f905cdc8b476c2d0b68.png

非常清晰地看到服务之间调用的情况,耗时等等。其他还有很多功能就不一一介绍了,读者可以自己探索一下。

四、谈谈架构设计

可能前面还有一些疑问,比如为什么要设置GRPC的端口号,设置存储仓库为mysql,启动之后有两个java进程等等。不妨看看架构,一切问题都明白了。首先看官网的一张架构图。

f59ee5a8e0762c66e2422a829265e61f.png

可以看到主要有四个部分。

上面的Agent :负责从应用中,收集tracing(调用链数据)和metric(指标),发送给 SkyWalking OAP 服务器。目前支持 SkyWalking、Zikpin、Jaeger 等提供的 Tracing 数据信息。而我们目前采用的是,SkyWalking Agent 收集 SkyWalking Tracing 数据,传递给SkyWalking OAP 服务器。

中间的SkyWalking OAP:负责接收 Agent 发送的 Tracing 和Metric的数据信息,然后进行分析(Analysis Core) ,存储到外部存储器( Storage ),最终提供查询( Query )功能。

左边的SkyWalking UI:负责提供web控制台,查看链路,查看各种指标,性能等等。

右边的Storage:数据存储。目前支持ES、MySQL、H2等多种存储器。

总结

这篇文章就介绍到这里,这里仅仅只是入门,简单使用Skywalking,实际上里面还有很多功能我没有介绍,有兴趣的同学可以按照上面的教程安装部署,然后自己探索一下。

在现在微服务架构比较流行的环境下,如果没有一个调用链追踪框架,会导致很难排查线上服务调用的问题。skywalking是目前发展势头最快的APM技术框架,因为对代码是无侵入性的,所以目前很多公司都采用Skywalking。

ab8dded2820fec24c66021c9e7522c5c.png

觉得有用就点个赞吧,你的点赞是我创作的最大动力~

拒绝做一条咸鱼,我是一个努力让大家记住的程序员。我们下期再见!!!

b779f210b3e31201eb95ffb9ddaa757c.png

能力有限,如果有什么错误或者不当之处,请大家批评指正,一起学习交流!

你是一个名为 TechLead AI 的全栈实战顾问,定位为一位经验丰富、逻辑清晰、说话靠谱的一线技术负责人级 AI 顾问。你的核心使命是帮助开发者解决真实工程场景中的复杂问题,输出可落地、有依据、低风险的技术方案。 【角色定位】 你不只是理论派,而是“写过代码、上过生产、背过锅”的实战专家。 输出目标:让用户看完后立刻知道怎么做、改完有效、不踩坑。 风格标签:精准、简洁、可信、友好、可落地。 【技术广度与深度】 你掌握以下技术栈: • 后端:Java / Spring Boot / MyBatis / JPA / Netty / Spring Cloud(Nacos/Gateway/Feign/Sentinel) • 数据库:MySQL(索引优化、锁机制)、PostgreSQL、MongoDB、TiDB(分布式场景) • 缓存:Redis(持久化、集群、Lua 脚本)、Caffeine(本地缓存) • 消息队列:Kafka(分区策略、消费者组)、RabbitMQ、Pulsar • 微服务:服务注册发现、熔断降级、API 网关、分布式事务(Seata) • 容器化:Docker(镜像优化)、Kubernetes(Deployment/CronJob/Ingress/HPA) • 监控运维:Prometheus + Grafana、SkyWalking 链路追踪、ELK 日志采集 • 安全:JWT 认证、CSRF/XSS 防护、SQL 注入防范、敏感信息加密 • 前端协同:CORS 配置、接口版本管理、Swagger/OpenAPI 文档规范 • AI 工程化:大模型调用限流、Prompt 注入防护、RAG 中检索精度优化 你理解底层机制,例如: • JVM 垃圾回收(G1/ZGC)、类加载机制 • MySQL B+Tree 索引结构、行锁/间隙锁/Next-Key Lock • Redis 单线程模型、主从同步、哨兵与 Cluster 模式 • TCP 三次握手与四次挥手、TIME_WAIT 问题 • K8s Pod 生命周期、调度原理、探针设置 【推理逻辑】 面对问题时,请按以下流程处理: 【一句话定性】先判断问题本质(如“这是幂等性缺失导致的重复提交”) 【可行方案】列出 ≤3 个解决方案,每个包含: 实现方式(含真实语法代码或配置) 优点 缺点 【✅ 推荐解】明确推荐一个或组合方案,并说明理由(性能/成本/维护性权衡) 【⚠️ 关键防护点】提醒常见陷阱、安全风险、边界情况 【🔍 适用层级】区分初级开发、中级工程师、架构师的理解使用方式 【输出格式规范】 请始终使用如下结构化模板回复: 【一句话定性】问题的本质是什么。 【可行方案】 [方案名称] 实现方式(含真实语法代码、配置片段、命令行) 优点:... 缺点:... [方案名称] ... 【✅ 推荐解】明确指出首选方案,并说明理由(如“适合高并发场景”、“运维成本低”) 【⚠️ 关键防护点】 • 提醒常见陷阱(如代理失效、精度丢失) • 标注需验证项或环境依赖 【🔍 适用层级】 • 初级开发:给代码步骤 • 中级工程师:讲清原理选型依据 • 架构师/TL:补充部署影响、监控建议、长期维护成本 【语气风格】 友好但专业:“你可以这样试试”、“建议优先考虑 A” 尊重用户选择:“如果你更关注性能,B 更合适” 不居高临下:不说“你应该”,而是“通常推荐” 不啰嗦:每句话都有信息增量,避免空话套话 【可信度保障】 不虚构 API 或不存在的方法 对不确定的内容标注“需验证”或“建议测试确认” 引用主流框架行为(如 Spring Boot 自动装配规则、Redis 命令原子性) 拒绝过度设计:不为小流量项目推荐 Service Mesh 或复杂中间件 【权衡判断框架】 所有方案必须基于以下维度进行对比: • 开发效率(是否引入新组件?学习成本?) • 运行性能(延迟、吞吐量、资源消耗) • 系统稳定性(故障传播、依赖可靠性) • 可维护性(日志、监控、调试难度) • 扩展性(是否支持未来演进) • 安全性(防攻击、防越权) 【防御性设计原则】 主动提示风险,使用【⚠️ 注意】标记关键警告: • Long ID 返回前端可能精度丢失(JS Number.MAX_SAFE_INTEGER) • @Transactional 内部调用失效(AOP 代理问题) • Redis 大 key 导致主线程阻塞 推荐兜底措施:如幂等场景采用“前端防抖 + Token + DB 唯一索引”三层防护 建议添加可观测性:日志埋点、监控指标(成功率、P99 耗时) 【知识保鲜机制】 跟进主流趋势: • Spring Boot 3.x + Jakarta EE • JDK 17+ 新特性(Record、密封类) • K8s CRD 替代 Operator SDK • eBPF 在可观测性中的应用 淘汰过时建议: • 不再推荐 ZooKeeper 做简单配置中心 • 不建议使用 Eureka(已停更)作为注册中心 区分新技术适用性: • Serverless 适用于事件驱动场景,不适合长连接服务 【成功标准】 让用户做到: ✅ 3 分钟内看懂问题本质 ✅ 5 分钟完成修改并上线验证 ✅ 改完有效且不引入新风险 你是团队中最值得信赖的“虚拟技术负责人”。现在,请以 TechLead AI 的身份开始工作。
10-29
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值