- 前言

随着信息化系统的建设完整和市场的推广竞争，性能慢慢变成衡量应用是否可用、好用的关键衡量指标之一。性能测试不同于功能测试、接口测试，性能更多关注于业务的响应速度和应用系统的整体处理能力上，当性能指标不符合与预期期望时，用户往往会直观地反馈不好用。

这里用户的 “不好用” 就是性能测试的核心重点。通过各种监控手段采集相关性能数据后，基于业务分析在各链路上的耗时、判断系统瓶颈是做性能测试、性能优化分析必不可少的环节。但是在当下这种靠个人能力或传统安插 Agent、日志等应用性能监控技术逐渐失效，已经无法满足用户的性能需求以及越来越快的系统迭代速度。

尤以当下企业全面转向云计算，以容器、微服务架构、DevOps 为核心的云原生架构成为降本提质增效的最优路径背景下，大规模容器集群产生更大的业务负载能力、更高的流量突发能力。容器架构的动态变化，对性能监控、分析的范围影响也越来越大与不可预估。因此，如何在云原生时代下更好开展质量领域性能测试，是我们为企业在市场上提供竞争力的弹药之一。

- 性能测试

说到性能测试，大家的第一印象基本上都是这三个阶段：

1. 模拟用户业务流程操作，通过录制手段或脚本编辑生成性能测试脚本，对脚本进行参数化、管理、思考时间、集合点设置完成整体性能脚本
2. 模拟用户负载行为，通过场景化进行压测的模型设置，选择监控指标
3. 分析测试数据，通过工具自带的整合分析功能或结合其他性能数据

那么我们做性能测试的目的在于什么呢？大多数同学刚开始做性能测试的时候，都是做完性能脚本调试、设置完压测模型、执行完脚本，看下系统的 CPU、内存、吞吐量、事务 TPS，在输出一份测试报告就结束了。

这种流程和测试报告在过去 10 年前或许是可以接受的，这受限于当初的技术架构（单体、前后端）和监控分析手段，但在当下技术架构、业务场景、用户需求、研发模式、敏捷转型、研发效能等诸多内、外环境的变化，企业对性能测试的目的越来越多样化、针对性。

常见性能测试目的一般包括：

1. 确定系统的响应时间：比如系统平均响应时间≤3 秒
2. 确定系统的最大用户数：比如系统在 100000 个用户下平均响应时间≤4 秒
3. 确定系统的最佳配置：比如在 Centos7、8C16G、500G 配置下，某业务支持 50000 个用户同时访问，平均响应时间≤1 秒

- 传统性能监控的窘境

性能测试目的确定后，往往都是基于此目的去做性能压测实施和监控数据分析，这里如何开展压测实施流程先不展开介绍，我们主要就监控数据分析这部分大家比较少谈的话题展开。

1、传统环境下性能监控颗粒度较粗

传统环境下系统的应用都是需要通过物理层网络设施进行流量转发，因此传统环境下，业务应用流量都是通过利用网络设备支持旁路流量镜像的方式实现采集，比如在交换机设置端口镜像或 TAP 转发采集。

但采集到的流量数据无法和业务对应起来，基本都是系统资源上如 CPU、内存、吞吐量或者本身服务器（如 Tomcat）自带的指标等数据，无法分解到具体某个 URL 和业务上。

这些都导致传统性能监控更多是以监控系统可用性为核心，不涉及具体业务。

2、技术架构升级的性能监控难点

过去在单体架构、前后端分离、SOA 架构上都可以进行物理层网络设施流量采集，随之信息化建设的发展，企业全面转向云计算，微服务架构、容器、DevOps 大行其道。

开发团队为了满足业务调整更加迅速，在技术上大量使用微服务架构，将业务解耦，把过去大单体拆解到小的服务，使其可以更加快速的发布投产。

运维团队使用容器、DevOps 技术，让代码更快发布，对业务流量进行实时监控、业务资源动态伸缩，更好的满足业务运营需求。

而这些都导致业务解析颗粒度越来越细，服务解耦越来越清晰，问题定位需要越来越精准，尤其是在当下技术上已经不会出现较大功能问题，更多在于不同技术架构、业务依赖、基础设施（网络、云平台、服务器）、服务配置、虚拟化技术的应用编排，而这些都需要精准的监控来进行分析。

3、业务性能需求常态化

得益于互联网的飞速发展，各种技术的迭代使其能够满足越来越多的业务形态，比如当下最流行的直播、赛事转播等，这些业务能够让我们身边每个人都能随时随地的参与和访问，都离不开性能保障。

性能需求在 14 年还只是在大型电商活动做秒杀、各种活动的时候，12306 刚开始发售时，也曾出现无数次出票服务不可用、系统响应缓慢的问题，当时的性能需求还是被动的或针对性的开展的。而现在日常的生活娱乐、出行交通、工作协同已经是无时无刻不在开展性能需求。

- 云原生时代性能监控探针

面对传统性能监控的窘境，以及现阶段技术上的框架推动、敏捷开发和自动化监控部署也对性能监控发起了挑战。

为了解决种种流量监控的难点，云网一体化性能保障平台（XrunnerFree）流量诊断探针，在面对复杂云环境下真正解决云流量采集、治理、回溯、输出的实用性价值，真正帮助企业对云环境进行无盲点、细粒度的监控，保障性能监控更加精准和性能定位到业务级别。

1、传统环境下性能监控颗粒度较粗

目前主流的开源项目底座、国内主流云厂商底环境、信创环境都支持云环境、宿主机、IDC 机房部署、流量采集。

1.云环境支持

• 部署支持私有云、公有云、混合云环境
• 部署支持虚拟机部署，或预置在 Docker

2.宿主机系统支持

• 对主流 Centos7/8，Ubuntu20.0 等相关发行版，都只需要一个版本、一个程序即可实现完美兼容
• 对主流虚拟化、容器化、云厂商（VMware、Kubernetes、Docker、OpenStack、阿里云、腾讯云、华为云等）支持

2、网络接口、数据包捕获

通过部署在私有云宿主机，或公有云工作负载的操作系统层，可以实现对：

• 全部网卡，特定网卡，IO 捕获
• 特定 IP / IP:Port / Port / IP~IP / Subnet 的数据包捕获
• 并可以执行 BPF 条件的 Byte-Code 数据包过滤捕获

3、宿主机统信数据治理与输出

对符合特征的流量进行实时解析，可以实时输出如下四种数据类型：

1.丰富的 TCP/UDP 的会话指标

判断网络时延行为的主要依据；可以实时的分析全部或特定网卡的 TCP/UDP 会话，并可以将分析结果，以 UDP 封装 JSON 格式的数据，实时转发到外部的数据接收端；主要的通信指标包括，聚合后的四元组信息，MAC，VXLAN/GRE 编号，以及全部标志位信息等。

2.HTTP/URL 的指标和内容，负载段的内容

判断各类应用层风险的主要依据，UniProbe 可以实时分析 HTTP/URL/XML 等会话和负载内容，并可以将其内容和主要指标，以 UDP 封装的 JSON 数据，实时转发到外部的数据接收端。

3.DB/SQL 的指标和内容

判断各类数据库风险的主要依据，UniProbe 可以实时分析 SQL 会话内容，并可以将其内容和主要指标，以 UDP 封装的 JSON 数据，实时转发到外部的数据接收端；支持的 DB 包括但不限于 Oracle，MySQL，SQLserver 等结构化数据库。

4.进程信息

如上三类数据监控功能，都可以与宿主机的进程相关联，通过分析进程的活跃程度（CPU/MEM 用量），进一步定位、分解性能风险。

- 收益与价值

通过云网一体化性能保障平台（XrunnerFree）的性能诊断探针的实施，能带给企业如下价值体现：

1.对复杂云环境下应用的云流量进行分析，做到云流量可视化，云网性能监控，异常流量发现和分析
2.在多层虚拟化环境下从物理设备层、私有云、K8S 容器云、lstio、业务层 POD 等多维度性能追踪，识别分层次下综合性能瓶颈，从而进行性能定位和调优
3.帮助客户从用户和业务视角分析和评估业务交易健康、后端应用性能、混合基础架构支撑能力
4.帮助用户基于统一平台，快速实现端到端业务交易追踪、代码级业务处理性能分析、业务故障、性能、多层虚拟化架构和 SDN 云网性能的全栈问题跟踪与诊断等等。