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

1背景

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

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

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

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

图2跨度信息

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

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

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

如果你想学习交流，看下方：

↓↓

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