案例实践丨基于SkyWalking全链路监控的微服务系统性能调优实践篇

1背景

随着开源社区和云计算的快速推进,云原生微服务作为新型应用系统的核心架构,得到了越来越广泛的应用。根据Gartner对微服务的定义:“微服务是范围狭窄、封装紧密、松散耦合、可独立部署且可独立伸缩的应用程序组件。”

案例实践丨基于SkyWalking全链路监控的微服务系统性能调优实践篇_第1张图片

微服务之父,马丁.福勒,对微服务概述如下:就目前而言,对于微服务业界并没有一个统一的、标准的定义。但通常而言,微服务架构是一种架构模式或者说是一种架构风格,它提倡将单一应用程序划分成一组小的服务,每个服务运行在自己独立的进程中,服务之间互相协调、互相配合,为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通(通常是基于HTTP的RESTful API)。

每个服务都围绕着具体业务进行构建,并且能够被独立地部署到生产环境、类生产环境等,这种方法能够提高应用系统的响应速度、灵活性和部署弹性,能够按照业务发展与时俱进快速迭代和优化。目前行内越来越多的应用服务系统已升级改造为微服务架构,对现有应用监控体系提出了新的挑战。

为推动微服务应用监控体系的建设和发展,探索微服务全链路监控技术在行内的实践路径,我们重点引入了SkyWalking开源可观测平台,通过非代码侵入的方式,采集微服务全链路监控信息,以可视化的方式展现微服务系统的拓扑关系、追踪交易链路、精准识别性能瓶颈,弥补现有测试工具和方法对微服务全链路应用监控的缺失。

2 SkyWalking简介

SkyWalking是开源的可观测平台的APM系统,专为微服务,云原生架构和基于容器(Docker,k8s,Mesos等)的架构设计的应用程序性能监控工具,用于收集、分析、聚合和可视化来自服务和云原生基础设施的数据。提供分布式追踪、服务网格遥测分析、度量聚合和可视化一体化解决方案。SkyWalking主要由以下四大部分构成:

Agent代理程序

探针收集数据并根据SkyWalking的要求对数据进行重新格式化(不同的探测器支持不同的来源);Agent运行在各个服务实例中,负责采集服务实例的Trace、Metrics等数据,然后通过gRPC方式上报给SkyWalking后端,供OAP服务器进行分析,本文将在第3章详细介绍Agent代理程序。

OAP服务器

SkyWalking的OAP(Observability Analysis Platform,观测分析平台)是一个用于分析链路采样数据的分析计算系统。

在OAP服务主要需要计算以下三类数据:

(1)Record数据

记录的链路数据,如Trace、访问日志等数据,由RecordStreamProcessor进行处理。

(2)Metrics数据

记录的指标数据,绝大部分的OAL(Observability Analysis Language)指标都将生成这类数据,由MetricsStreamProcessor进行处理。

(3)TopN数据

记录的周期性的采样数据,如慢SQL的周期性采集,由TopNStreamProcessor进行处理。

Trace、访问日志等这类的明细数据,数据量比较大,但不需要归并处理,所以在OAP节点内部即可处理完成,这些明细数据采用缓存、异步批量处理和流式写入的方式将它们写入到外部存储器(Storage)中。

绝大部分由OAL(Observability Analysis Language)定义的指标数据是需要微服务聚合计算的,所以在OAP集群计算流中将其分为了两个步骤。

步骤一,接收和解析Agent代理程序发送的数据,并执行当前OAP服务节点内的数据聚合,使用OAL或其他聚合模式。对于不需要聚合的数据,直接将其写入到外部存储器(Storage)中;如果是需要微服务聚合的数据,根据一定的路由规则发送给指定的OAP服务节点。

步骤二,接收和解析经步骤一处理的数据,之后进行二次聚合计算,并将结果数据写入到外部存储器(Storage)中。

针对以上两个步骤,OAP服务节点被分为Receiver(处理步骤一)和Aggregator(处理步骤二)两种角色。

默认情况下,所有OAP服务节点均为Mixed混合角色,其既可以执行步骤一的操作,也可以执行步骤二的操作。在大规模系统部署SkyWalking的场景下,可根据网络流量进行角色分离的两级部署。

OAP服务器还服务响应SkyWalking UI界面发送来的查询请求,将前面持久化的数据查询出来,组成正确的响应结果返回给UI界面进行展示。

Storage数据库存储

作为OAP服务的外部存储设备,负责数据的存储,支持多种存储类型,可以使用既有的存储系统,如ElasticSearch,Mysql等,也可以自定义实现存储系统。SkyWalking数据可以选择存储在已实现的ElasticSearch,Mysql,TiDB,InfluxDB,H2的持久化系统,其中H2是内存数据库,存储的数据在内存里,不落到磁盘上,重启SkyWalking服务会导致数据丢失,是默认的存储方式,一般线上使用ElasticSearch集群作为其后端存储。

UI界面

负责可视化和管理SkyWalking数据,前后端分离,该UI界面负责将用户的查询操作封装为GraphQL请求提交给OAP后端触发后续的查询操作,待拿到查询结果之后会在前端负责展示并可以查看链路调用关系,查看各种监控指标,性能指标等等。

由以上对构成SkyWalking的各分系统的介绍可知,Agent代理程序负责收集各种链路采样数据,通过GRPC的?式传递给OAP进行分析并且存储到数据库中,最终通过UI界面将分析的统计报表、服务依赖、拓扑关系图展示出来。

3 SkyWalking应用扩展及性能调优

自定义插件开发示例,基于某系统开发自定义插件,将其部署至SkyWalking部署包的plugins目录内。

对某查询接口执行调用操作,多个线程都可以在SkyWalking中查看方法的采样信息,如图1所示:

案例实践丨基于SkyWalking全链路监控的微服务系统性能调优实践篇_第2张图片

图1某查询方法的采样信息

点击图1中的某查询方法链接,可以查看详细的跨度信息,如图2所示。

案例实践丨基于SkyWalking全链路监控的微服务系统性能调优实践篇_第3张图片

图2跨度信息

由以上信息可知,可以清晰看到我们添加的三个tag标签分别为:invoke开始时间,invoke结束时间,系统间查询方法执行时长(ms)。

系统重构,架构特点为多微服务、多链路系统。可应用参数配置检查、可观测性技术、数据移植、同步验证4个课题的成果。

性能调优示例,为了尽可能减少SkyWaling Agent对业务性能测试的影响,真实监控出业务系统性能瓶颈,我们对SkywalkingAgent进行了一些性能调优,通过调整采样频率和采样数量等相关参数,减少部署SkyWalking Agent后产生的额外的性能损耗。图3是通过对同一只交易在未部署SkyWaling Agent情况下、已部署SkyWaling Agent标准化(未性能调优)情况下、已部署SkyWaling Agent已性能调优情况下,在相同并发下的性能测试结果对比,调优之后,我们发现性能表现相对于标准化部署场景下有提升,相较未部署agent情况,将性能损耗降到最小。

案例实践丨基于SkyWalking全链路监控的微服务系统性能调优实践篇_第4张图片

如果你想学习交流,看下方:

↓↓

可以到我的个人号:atstudy-js,就可以邀请你进群一起探讨学习交流。

你可能感兴趣的:(性能测试,数据库,软件测试,java,python,性能调优,性能优化)