微服务架构已经是一个很通用的系统架构,常见的技术栈如下图所示,这张架构图基本涵括了当前微服务体系下的各种技术栈,可能不同的技术栈有不同的开源实现。
对于一个大型的几十个,几百个微服务构成的微服务架构系统,通常会遇到下面的一系列问题。
如何串联整个调用链路,快速定位问题?
如何澄清各个微服务之间的依赖关系?
如何进行各个微服务接口的性能分析?
如何追踪各个业务流程的调用处理顺序?
Skywalking是一个国产的开源框架,2015年有吴晟个人开源,2017年加入Apache孵化器,国人开源的产品,主要开发人员来自于华为,2019年4月17日Apache董事会批准SkyWalking成为顶级项目,支持Java、.Net、NodeJs等探针,数据存储支持Mysql、Elasticsearch等,跟Pinpoint一样采用字节码注入的方式实现代码的无侵入,探针采集数据粒度粗,但性能表现优秀,且对云原生支持,目前增长势头强劲,社区活跃。 Skywalking是分布式系统的应用程序性能监视工具,专为微服务,云原生架构和基于容器(Docker,K8S,Mesos)架构而设计,它是一款优秀的APM(Application Performance Management)工具,包括了分布式追踪,性能指标分析和服务依赖分析等。
目前市面上开源的APM系统主要有CAT、Zipkin、Pinpoint、SkyWalking,大都是参考Google的Dapper实现的
Zipkin是Twitter开源的调用链路分析工具,目前基于Spingcloud sleuth得到了广泛的应用,特点是轻量,部署简单。
Pinpoint一个韩国团队开源的产品,运用了字节码增强技术,只需要在启动时添加启动参数即可,对代码无侵入,目前支持Java和PHP语言,底层采用HBase来存储数据,探针收集的数据粒度非常细,但性能损耗大,因其出现的时间较长,完成度也很高,应用的公司较多
Skywalking是本土开源的基于字节码注入的调用链路分析以及应用监控分析工具,特点是支持多种插件,UI功能较强,接入端无代码侵入。
CAT是由国内美团点评开源的,基于Java语言开发,目前提供Java、C/C++、Node.js、Python、Go等语言的客户端,监控数据会全量统计,国内很多公司在用,例如美团点评、携程、拼多多等,CAT跟下边要介绍的Zipkin都需要在应用程序中埋点,对代码侵入性强。
模拟了三种并发用户,500,750,1000,使用JMeter测试,每个线程发送30个请求,设置间隔时间为10ms,使用采用频率为1,即100%。下面是性能测试报告:
从上表可以看出,在三种链路监控组件中,skywalking探针对吞吐量影响最小,zipkin对吞吐量影响适中,pinpoint的探针对吞吐量影响最大。对于内存和cpu的使用,都差不多,相差在10%之内。
SkyWalking 逻辑上分为四部分: 探针, 平台后端, 存储和用户界面。
下载skywalking:
Downloads | Apache SkyWalking
这里我用的是8.5.0版本的
第1步 默认skywalking不支持gateway服务,我们需要在agent/options-plugins下的gateway的jar复制到/agent/plugins
它的默认端口号是8080,如果想自己修改,可以修改apache-skywalking-apm-bin\webapp下的
webapp.yml
第2步 启动skywalking
双击/bin/start.bat
此时会弹出两个黑窗口,如果有一个启动失败则会关闭失败的窗口,必须保证两者都开着
不要关闭黑窗口,最小化即可
logs下可以查看启动日志
开发环境IDEA中使用探针配置即可集成使用agent,我们把 apache-skywalking-apm-bin
放到本地D:/safety/springcloud
目录下,此时我们使用探针配置为3个项目分别配置agent:
# 客户端需要的jar所在位置
-javaagent:D:/safety/springcloud/apache-skywalking-apm-bin/agent/skywalking-agent.jar
# 客户端服务名称
-Dskywalking.agent.service_name=springcloud-order
# skywalking地址
-Dskywalking.collector.backend_service=localhost:11800
注意:路径有一部分需要变更为自己存放文件的位置
将上面配置复制到IDEA中,且删除注释:
11800是oapservice集群的端口号,9999是UI服务的端口号
此时启动IDEA,并访问 http://localhost:9999/效果如下:
跟上边设置的名称对应
生产环境使用,因此我们需要将agent和每个项目的jar包上传到服务器上,上传apache-skywalking-apm-bin 至/softwares ,再将 工程\hailtaxi-parent中的项目打包,并分别上传到服务器上,如下三个工程:
启动hailtaxi-order
java -jar -javaagent:/softwares/apache-skywalking-apm-bin/agent/skywalking-agent.jar -Dskywalking.agent.service_name=hailtaxi-order-jar -Dskywalking.collector.backend_service=localhost:11800 springcloud-gateway-1.0-SNAPSHOT.jar &
默认skywalking不会收集gateway微服务的信息,如何让他支持gateway微服务。
skywalking如果服务重新启动,链路日志消失了,因为默认在内存中保存
可以持久化存储到mysql,es存储引擎。
1.打开\apache-skywalking-apm-bin\config下的application.yml配置文件
2. 把mysql的驱动放入skywalking的\apache-skywalking-apm-bin\oap-libs中
3. 自己创建数据库,无需创建表
4.重启skywalking,依旧是bin下的双击startup.bat
作用:查看被监控服务的运行状态。
监控面板:
1.1 APM
APM: 应用性能管理,通过各种探针采集数据,收集关键指标,同时搭配数据呈现以实现对应用程序性能管理和故障管理的系统化解决方案。
1.1.1 Global全局维度
板块描述:
services load :服务每分钟请求数s1ow services:慢响应服务,单位ms
Un-Health services (Apdex) :Apdex性能指标,1为满分。
show Endpoints:慢响应端点,单面ms
G1obal Response Latency:百分比响应延时,不同百分比的延时时间,单位ms
G1obal Heatmap:服务响应时间热力分布图,根据时间段内不同响应时间的数量显示颜色深度
底部栏:展示数据的时间区间,点击可以调整
1.1.2 Service服务维度
service Apdex(数字):当前服务的评分
service Apdex(折线图):不同时间的Apdex评分
service Avg Response Times:平均响应延时,单位ms
G1obal Response Time Percentile:百分比响应延时
successfu1 Rate(数字):请求成功率
successfu1 Rate(折线图):不同时间的请求成功率
servce Load(数字):每分钟请求数
servce Load(折线图):不同时间的每分钟请求数
servce Instances Load:每个服务实例的每分钟请求数
show service Instance:每个服务实例的最大延时
service Instance successfu1 Rate:每个服务实例的请求成功率
1.1.3 Instance实例维度
属性描述:
service Instance Load:当前实例的每分钟请求数
service Instance successfu1 Rate:当前实例的请求成功率
service Instance Latency:当前实例的响应延时
vM CPu: jvm占用CPU的百分比
JVM Memory : VM内存占用大小,单位m
JVM GC Time : VM垃圾回收时间,包含YGC和oGC
JVM Gc count: JVM垃圾回收次数,包含YGC和oGC
JVM Thread count (ava service) : VM创建线程数量
CLR xx:类似VM虚拟机(可以直接理解成虚拟机)
1.1.4 Endpoint端点(API)维度
属性描述:
Endpoint Load in current service:每个端点的每分钟请求数
s1ow Endpoints in current service:每个端点的最慢请求时间,单位ms
successful Rate in current service:每个端点的请求成功率
Endpoint Load:当前端点每个时间段的请求数据
Endpoint Avg Response Time:当前端点每个时间段的请求行响应时间
Endpoint Response Time Percentile:当前端点每个时间段的响应时间占比
Endpoint successfu1 Rate:当前端点每个时间段的请求成功率
1.2 DataSource展示栏
属性描述:
当前数据库:选择查看数据库指标
Database Avg Response Time:当前数据库事件平均响应时间,单位ms
Database Access successfu7 Rate:当前数据库访问成功率
Database Traffic:CPM,当前数据库每分钟请求数
Database Access Latency Percentile:数据库不同比例的响应时间,单位ms
s1ow statements :前N个慢查询,单位ms
A17 Database Loads:所有数据库中CPM排名
Un-Health Databases:所有数据库健康排名,请求成功率排名
属性描述:
左侧:api接口列表,红色-异常请求,蓝色-正常请求
右侧:api追踪列表,api请求连接各端点的先后顺序和时间
操作详情:可以看到底层执行语句
如果那个业务慢了可以性能剖析,非常详细
这里我们可以看到追踪里/order/buy/1/1有一步非常慢,我们可以解剖一波
1 性能剖析-->新建任务
2 运行相应的任务,等待片刻
新建性能剖析属性描述:
服务:需要分析的服务
端点:链路监控中端点的名称,可以在链路追踪中查看端点名称监控时间:采集数据的开始时间
监控持续时间:监控采集多长时间起始监控时间:多少秒后进行采集监控间隔:多少秒采集一次
最大采集数:最大采集多少样本
不同维度告警列表,可分为服务、端点和实例。日志收集只在8.4以上版本支持。
Skywalking-UI(三)界面说明_CodingAnHour的博客-CSDN博客_skywalking界面介绍