注：
1. 程序员做的测试
2. 测试报告文档原稿在上传审核中，请等待
审核好了：https://download.csdn.net/download/yiquan_yang/12694138

1 概述

1.1 背景

系统的稳定性是系统长期稳定运行能力，需要时间累积才能度量。平台的某些问题需要达到一定时间、一定的使用量后才会暴露出来。如内存泄漏，系统运行过程中发现部分服务的部分接口会发生服务不可达的情况。
从而团队提出对平台进行稳定性分析，通过给系统施加一定业务压力大情况下，使系统持续运行一段时间，以此来检测系统是否稳定运行（下统称稳定性测试或测试）。

1.2 服务说明

平台运行的服务包括系统服务和业务服务，系统服务包括Consul、Redis、Cap、RabbitMQ、Exceptionless套件等，业务服务包括用户服务、基础数据服务、网关服务，详细见《xxx发布标准》。本次测试针对三个业务服务，对系统外界只有网关可视（测试对象统称系统或平台），故测试对象为一个服务。

1.2.1 服务器部署

本次测试采用单机环境，所有服务全部配置在同一台服务上，数据库部署在另一台机器上。

Manufacturer: Microsoft Corporation
Product Name: Virtual Machine
IP：192.168.4.57（业务服务）、192.168.4.253（数据库）
CPU：Intel® Xeon® Gold 5117 CPU @ 2.00GHz （物理CPU个数 1，核数：16）
Memory：16G

OS：CentOS Linux release 7.6.1810 (Core)
PostgreSQL：PostgreSQL 11.6 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39), 64-bit
Docker：Docker version 19.03.5, build 633a0ea
其他软件环境见1.3测试工具

1.2.2 服务配置

其中系统中存在大量配置，其中影响测试的配置包括：
xx：单服务接口最大并发数 设置为 1万
xxx：请求执行超时时间 设置为 30s
xxx：是否启用性能追踪组件 设置为 不启用
xxxxxx：是否启用服务接口缓存拦截 设置为 启用
Xxxxxxxx：是否启用集中式日志 设置为 不启用

1.3 测试工具

Apache JMeter（5.2.1）：测试客户端，作为虚拟用户脚本产生器（Virtual User Generator）、压力产生器（player）、用户代理（Agent）、压力调度和监控系统（Controller）、压力结果分析工具（Analysis）
1)安装前需要安装Java，本次测试使用jre1.8.0_241
2)客户端如需则自行汉化
3)安装服务资源监控器插件，从官网下载安装Plugins Manager，并安装jpgc - Standard Set
ServerAgent（2.2.1）：服务器Agent，提供服务器资源使用数据
1)服务器需要安装Java，本测试使用java version “1.8.0_241”
2)进入ServerAgent存放目录，使用命令“./startAgent.sh”启动Agent
3)需要确保端口4444能够访问，本测试关闭了服务器防火墙

1.4 稳定标准

在一定的配置情况下
CPU：单颗，16核
Memory：16G
在以上硬件环境下满足
1)系统指标
满足100个/s的最大并发。请求100%请求成功，且平均响应时间小于5s；
2)资源指标
在单位时间内（5s），CPU最大使用率不能持续超过95%，内存最大占用率不能持续超过95%。
1.5 关键字定义
1.6 排除干扰项
不考虑断电，硬件资源损坏情况

2 测试方案

本次测试采取负载测试、并发测试、可靠性测试。测试方案采取模拟真实用户使用场景，模拟指定人数在一定时间点击界面产生的请求数。
在并发10（单位个/s）、20、40、80、160、500、1000、2000的基准下，调整用户数（虚拟用户用一个线程，下统称线程数）、点击准备时间（用户点击时间模拟时间，下称Ramp-up单位秒）和用户点击次数（下称循环），例如10个用户，每个用户每5秒点击1次，则线程数为10，Ramp-up为5，循环数为1。详细测试策略请看2.1。

对登录、数据新增（用户）、编辑（用户）、获取（用户）和删除（用户）进行负载测试，获得其稳定负载值。
对全站使用策略100-100-1-1进行并发测试，挑选用户服务所有接口。基础数据服务中挑选和用户服务关联的功能接口5个，组织结构接口4个，和用户服务无关的行政区3个接口。具体接口请查看附件1。
对全站进行可靠性测试，根据以上测试接口，选择稳定的并发数后持续测试-模拟时长8+小时。
稳定性测试是通过运行状态和资源指标的2个方面来分析及评估系统的稳定性，请求记录项响应的时间平均值、最小值、最大值、标准偏差、异常（百分比）、吞吐量、接收、发送、平均字节数，服务器资源指标CPU、Memory，在此额外添加记录数据库数据。通过调试测试策略、分析实验数据得出相关系统稳定性的结论，从而达到平台能力验证、规划能力、性能调优、缺陷发现等目的。

评价定义
稳定：无异常，平均值和变成偏差差距较少且不高；
普通：无异常，平均值小于5秒，平均值和变成偏差差距较少；
一般：无异常，平均值大于5秒，平均值和变成偏差差距较大；
差：存在异常，异常率小于30%；
极差：存在异常，异常率大于登录30%；

2.1 测试策略

测试策略

编号	并发数	线程数	Ramp-up	循环	场景	备注
10-1-1-10	10	1	1	10	1个用户，每个用户每秒提交10次请求
10-10-1-1	10	10	1	1	10个用户，每个用户每秒提交1次请求
10-20-2-1	10	20	2	1	20个用户，每个用户2秒内提交1次请求
10-20-4-2	10	20	4	2	20个用户，每个用户4秒内提交2次请求
10-40-4-1	10	40	4	1	40个用户，每个用户4秒内提交1次请求
10-40-8-2	10	40	8	2	40个用户，每个用户8秒内提交2次请求
10-80-8-1	10	80	8	1	80个用户，每个用户8秒内提交1次请求
10-80-16-2	10	80	16	2	80个用户，每个用户16秒内提交2次请求
。。。。。。

2.2 测试脚本

测试脚本分为登录和服务接口两个线程组，模拟用户登录后进行系统。
1)在测试前定义测试配置变量，查看图2.2-1，使用变量

图2.2-1 定义线程组中配置变量

图2.2-2 使用线程组中配置变量
2)用户登录成功后将Token写入全局变量中，服务接口线程组统一使用该Token。
3)创建数据类接口，相关使用值在BeanShell预处理程序中创建，创建完成后在JSON提取器中提取相关值，供请求组装报文，例如用户，产生用户姓名请查看图2.2-3，使用查看图2.2-4，提取值查看图2.2-5。

图2.2-3 定义线程组中创建用户姓名变量

图2.2-4 使用线程组中创建用户姓名变量

图2.2-5 使用线程组中创建用户姓名变量
4)编辑、获取和删除接口需要的主键ID从创建请求成功后提取。
5)脚本中还包括HTTP头信息管理器(HTTP Header Manager)，相关运行结果项察看结果树（请求头，Body，Response结果）、用表格察看结果（请求开始时间、运行时间等）、汇总报告（样本、最小值、最大值、错误率等）、jp@pc-PerMon Metrics Collector（服务器资源监视器）、汇总图（请求时间管理：样本、中位数、平均值、90%百分比等）
6)整体脚本编写完成后，请查看图2.2-6。

图2.2-5 脚本一览

3 负载测试

3.1 测试样本

3.1.1 登录接口

1)查看结果树

登录接口（线程池100）

策略编号	样本	平均值	最小值	最大值	标准偏差	异常%	吞吐量	接收	发送	平均字节数	评价
100-50-1-2	100	383	40	1181	294.89	0	55.43	30.96	30.92	572.00	稳定
100-100-1-1	100	244	41	962	192.77	0	68.63	38.34	40.37	572.00	稳定
100-200-2-1	200	768	39	2969	716.67	0	55.87	31.21	33.03	572.00	稳定
100-1000-10-1	1000	50779	38	79358	29633.03	0.739	12.17	3.97	7.35	334.04	极差
100-1000-20-2	很卡无法测试

登录接口（线程池1000）

策略编号	样本	平均值	最小值	最大值	标准偏差	异常%	吞吐量	接收	发送	平均字节数	评价
100-1000-10-1	1040	18037	43	30473	11904.87157	0.15	3.45	1.77	2.07	527.1	差

登录接口（线程池1500）

策略编号	样本	平均值	最小值	最大值	标准偏差	异常%	吞吐量	接收	发送	平均字节数	评价
100-1000-10-1	1000	4189	32	13070	2803.22	0	54.38	30.59	33.06	576	稳定

登录接口（使用多个策略连续测试-线程池1500）

策略编号	样本	平均值	最小值	最大值	标准偏差	异常%	吞吐量	接收	发送	平均字节数	评价
1-10-10-1
10-100-10-1
100-1000-10-1	1000	4189	32	13070	2803.22	0	54.38	30.59	33.06	576	一般
100-1000-10-1
100-1000-10-1	3110	5443	34	17675	3858.24	0	21.67	12.19	13.17	576	一般
100-1000-10-1	4120	4895	30	17675	3654.62	0	13.77	7.75	8.37	576	一般
1-10-10-1
1-10-10-1	4130	4883	30	17675	3657.94	0	11.79	6.63	7.16	576

2)使用多个策略连续测试

jp@pc-PerMon Metrics Collector 服务资源监控
3)100-1000-10-无线循环（10次+）

CPU占用在30%左右
内存在30%左右
4)100-1000-10-2 汇总图

中位数（所有请求响应时间的中间值可认为50%的请求）低于平均值和最大值的一般，比较稳定。
90%请求在15s内请求完成，在并发高的情况下响应时间会降低，一半以上的会大于6s。但是100%响应，无异常产生。

3.1.2 创建接口

创建用户（连续请求两次）
策略编号 样本 平均值 最小值 最大值 标准偏差 异常% 吞吐量 接收 发送 平均字节数 评价
100-1000-10-1 2001 79 41 262 20.40 0.00 30.36 8.75 20.55 295 稳定

各项测试策略表现的非常稳定

3.1.3 获取接口

此接口没有配置缓存拦截，数据直接读库

获取用户（连续请求两次）

策略编号	样本	平均值	最小值	最大值	标准偏差	异常%	吞吐量	接收	发送	平均字节数	评价
100-1000-10-1	2000	21	13	144	7.95	0.00	32.23	19.70	19.67	626	稳定

各项测试策略表现的非常稳定

3.1.4 编辑接口

1)更新用户

更新用户（连续请求两次）

策略编号	样本	平均值	最小值	最大值	标准偏差	异常%	吞吐量	接收	发送	平均字节数	评价
100-1000-10-1	2000	7877	26	18932	4915.29	0	16.35	4.17	12.85	261	稳定

2)修改用户密码

修改用户密码

策略编号	样本	平均值	最小值	最大值	标准偏差	异常%	吞吐量	接收	发送	平均字节数	评价
100-1000-10-1	2000	3986	22	12778	2689.05	0.00	49.09	12.80	30.06	267	稳定

3.1.5 删除接口

删除用户（暂时无并场景）

策略编号	样本	平均值	最小值	最大值	标准偏差	异常%	吞吐量	接收	发送	平均字节数	评价

3.1.6 分页接口

此处没有选择分页查看用户，是因为查询数据无数据，经排查是没有权限，但是搜索角色却可以。并且页大小为10，查询第一页没有考虑数据量大的情况，搜索比较靠后的页。此接口没有配置缓存拦截，数据直接读库

分页查询角色

策略编号	样本	平均值	最小值	最大值	标准偏差	异常%	吞吐量	接收	发送	平均字节数	评价
100-1000-10-1	2000	16	10	104	6.85	0.00	12.67	25.41	7.93	2054	稳定

3.1.7 其他接口

用户服务

编号	模块	接口	是否满足	评价	备注
1	User	获得当前登录用户信息	满足	稳定
2	User	获得用户数据权限	满足	稳定	获取同一个用户
3	User	获得用户功能权限	满足	稳定	获取同一个用户
4	User	从数据库获取权限数据	满足	普通	获取同一个用户
5	User	获得用户列表	满足	稳定	无权限
6	User	分页获取用户数据	满足	稳定
…

比较突出的四个为评价“普通”，“一般”的。登录请求请看3.1.1

3.2 结果分析

3.2.1 稳定性分析

经过修复上一轮测试暴露出来的问题，目前登录、新增、编辑、查看、删除、分页等不同类型接口都有较好负载能力，满足团队当前对并发值100的期望值，部分接口平均响应时间未能满足要求，请求查看3.1。

3.2.2 解决方案

1)修改PostgreSql最大连接数，视服务器配置设定
在本次测试服务器环境下设定1000，能满足基本负载要求（基础数据平台）
参考资料：
https://stackoverflow.com/questions/30778015/how-to-increase-the-max-connections-in-postgres/32584211#32584211
2)修改服务事务，禁止在事务中添加执行长时间的代码，例如：大量RPC、HTTP、大量循环等。
事务使用方式请参考《xx平台文档库》
3)修改服务最小线程池值
在本次测试服务器环境下设定1500，能满足负载要求（基础数据平台）
参考资料：https://stackexchange.github.io/StackExchange.Redis/Timeouts.html
4)优化细节
登录后权限设定改为异步；
方法中添加返回值，返回类型为Task添加async关键字；
取消接口事务，如果零个或单个DML取消事务，其他情况事务中只含DML语句；
优化代码结构，防止重复代码或重复业务操作（如删除操作：Service判断是否存在、仓储层再次判断是否存在）；
获取类接口（执行时间久、修改频率低）添加服务端缓存拦截；
修改xxxxxxxx.json中接口并发数，MaxConcurrentRequests=1000
修改yyyyyyyy.json中管理Redis线程数值，本次测试为：minSize=100、maxSize=1000

4 并发测试

4.1 测试样本

100-100-1-1策略下测试整个服务

Label	# 样本	平均值	最小值	最大值	标准偏差	异常 %	吞吐量	接收 KB/sec	发送 KB/sec	平均字节数
登录	1	333	333	333	0	0.00%	3.003	1.67	0.91 568
获得当前登录用户信息	100	1103	52	2379	757.52	0.00%	3.17188	23.72	1.56	7656.2
。。。
总体	4501	1303	52	3499	865.01	0.00%	48.36561	1987.8	30.81	42085.8

表3.2-1 负载测试汇总报告

图3.2-1 负载测试jp@pc-PerMon Metrics Collector

图3.2-2 负载测试汇总图

图3.2-3 负载测试报错日志

图3.2-4 吞吐量正序排序

图3.2-5 接收数据倒序排序

4.2 结果分析

测试一次用例总共耗时1分33秒，共4501一个请求，接口普遍正常，其中“根据角色和功能删除”、“根据角色Id删除对象功能”出现少量异常分别为1%、3%，错误信息请查看图“3.2-3”。接口的普遍中位数在500ms以上且标准偏差大在800ms左右，不考虑接口业务设计错误信息下，指标与当前版本要求差距不大。部分接口返回数据较大和吞吐量低的情况，更详细请查看可靠性测试。

5 可靠性测试

5.1 测试样本

5.1.1 全站可靠性测试

使用稳定的并发数持续运行-模拟时长8+小时
先采取策略100-100-1-1执行一段时间报错，由于单个接口100并发，49个接口总共并发数较大，调整策略为10-10-1-1，单接口10并发整站490并发，循环持续执行。

Label	# 样本	平均值	最小值	最大值	标准偏差	异常 %	吞吐量	接收 KB/sec	发送 KB/sec	平均字节数
登录	7	2637	1373	5387	1393.34	0.00%	0.00038	0	0	568
获得当前登录用户信息	5600	511	83	29353	493.23	0.00%	0.24883	102.87	0.12	423337.8
…
总体	267387	903	47	60105	1867.88	0.50%	10.40672	2425.9	6.61	238703.3

表3.3.1-1 汇总报告
修改后 相同测试样本，

Label	# 样本	平均值	最小值	最大值	标准偏差	异常 %	吞吐量	接收 KB/sec	发送 KB/sec	平均字节数
登录	2	124	123	125	1	0.00%	0.05811	0.03	0.02	568
。。。

修改前和修改后服务器消耗资源对比

图3.3.1-1 PerMon Metrics Collector-修改前

图3.3.1-1 PerMon Metrics Collector-修改后

修改前和修改后服务器内存消耗对比

图3.3.1-3 PerMon Metrics Collector-Memory-修改前

图3.3.1-3 PerMon Metrics Collector-Memory

5.1.2 创建接口类型可靠性测试

1)创建用户

Label	# 样本	平均值	最小值	最大值	标准偏差	异常 %	吞吐量	接收 KB/sec	发送 KB/sec	平均字节数
登录	10	4786	4263	5101	294.54	0.00%	0.002	0	0	568
创建用户	110263	4219	153	12548	1224.2	0.00%	21.94785	6.32	14.69	295
总体	110273	4219	153	12548	1224.16	0.00%	21.93116	6.32	14.67	295

表3.3.2-1 汇总报告
修改后 平均响应时间缩短计算器60%，吞吐量增加300%

Label	# 样本	平均值	最小值	最大值	标准偏差	异常 %	吞吐量	接收 KB/sec	发送 KB/sec	平均字节数
登录	1	447	447	447	0	0.00%	2.23714	1.24	0.68	568
创建用户	100000	1609	177	5784	468.86	0.00%	61.72664	17.78	41.3 295
总体	100001	1609	177	5784	468.88	0.00%	61.70951	17.78	41.29	295

图3.3.2-1 服务器资源消耗-修改前后对比
修改后：内存消耗稳定，且能够回收内存，之前需要运行1h23min，现在仅需27min，缩短67%的时间。

图3.3.2-2 服务器资源消耗-Memory-对比
2)创建功能

Label	# 样本	平均值	最小值	最大值	标准偏差	异常 %	吞吐量	接收 KB/sec	发送 KB/sec	平均字节数
登录	2	4873	4512	5234	361	0.00%	0.00284	0	0	568
创建功能接口	108708	2829	128	9021	910.88	0.00%	30.63697	8.83	23.47	295
总体	108710	2829	128	9021	910.92	0.00%	30.59851	8.82	23.44	295

表3.3.2-2-1 汇总报告
修改后 平均响应时间缩短计算器57%，吞吐量增加270%

Label	# 样本	平均值	最小值	最大值	标准偏差	异常 %	吞吐量	接收 KB/sec	发送 KB/sec	平均字节数
登录	2	409	375	444	34.5	0.00%	0.01732	0.01	0.01	568
创建功能接口	100000	1208	115	3842	432.26	0.00%	81.5692	23.5	62.48	295
总体	100002	1208	115	3842	432.27	0.00%	81.54023	23.49	62.45	295

修改后：各项指标均运行平稳，其中内存消耗比较明显，之前需要运行58min，现在仅需20min，缩短65%的时间。

图3.3.2-2-1 服务器资源消耗
内存消耗比较：由于是单机部署，存在多个服务，此处只比较内存变化稳定性，修改后较修改前稳定。

图3.3.2-2-2 服务器资源消耗-Memory

5.1.3 编辑接口类型可靠性测试

Label	# 样本	平均值	最小值	最大值	标准偏差	异常 %	吞吐量	接收 KB/sec	发送 KB/sec	平均字节数
登录	5	4280	4167	4415	82.15	0.00%	0.00076	0	0	568
编辑用户	130000	4761	90	30528	4445.93	0.15%	17.24658	4.4	13.42	261

表3.3.3-1 汇总报告
修改后 接口存在错误，并发下编辑同库同表同行数据，与本次测试的策略有关系。报错详情：This NpgsqlTransaction has completed;it is no longer usable. 限制因素：数据库行级锁限制或并发下事务处理方案需优化

Label	# 样本	平均值	最小值	最大值	标准偏差	异常 %	吞吐量	接收 KB/sec	发送 KB/sec	平均字节数
登录	4	928	352	2303	805.26	0.00%	0.00138	0	0	568
编辑用户	34264	8338	84	30455	7267.91	0.59%	11.75666	3	9.15	261.7

服务器资源消耗对比

图3.3.3-1 服务器资源消耗
内存消耗对比：修改后编辑用户前期内存消耗正常，在程序后期出现错误后内存消耗严重，和本次测试策略有关系。

图3.3.3-2 服务器资源消耗-Memory

5.1.4 获取接口类型可靠性测试

。。。

5.1.5 分页获接口类型可靠性测试

…

5.2 结果分析

5.2.1 概况

本次测试计划测试时长为8h+，实际测试时长为7小时8分钟，总共发起请求267387个，吞吐量为10.4/s，平均响应时间900ms，错误率0.5%，平均发送速率6.61KB/s，接收速率2425KB/s。
数据库数据无异常。

假设系统常用在线用户10人，每人平均每分钟点击20次，每天平均在线时长10分钟，13天

1)服务器资源CPU
服务器资源中CPU表现稳定，在测试后半段出现满负荷情况；
2)服务器Memory
服务器内存单位时间内平缓但总体呈上逐步升趋势；
3)服务器Disks I/O
服务器磁盘I/O比较稳定，测试用例循环测试的启动初期会出现一定的波动；
4)服务器Swap
服务器Swap在服务启动初期会暂用比较高资源，在服务运行过程中逐步下降；
5)服务器TCP
服务器TCP连接数在运行过程中一直保持在4000个连接左右，可能是影响吞吐量的因素之一；
6)Network I/O
网络I/O比较稳定，总体上没有太多的异常。

5.2.1.1 问题

1)服务器资源占用会越来越多
从图3.3-2 PerMon Metrics Collector-CPU、图3.3-3 PerMon Metrics Collector-Memory可以观察到CPU在测试后期出现异常，而内存逐步上升，在1h40min、3h、4h20min时出现一定下降，原因是测试循环和下一个循环的间隔，系统可能回收了资源。停止服务请求在相隔一定时间（8h+）后再次测试，资源占用情况并未好转（测试登录服务报错）。

2)服务吞吐量较低
在负载测试和并发测试中，虽然请求在100并发下都能真确响应，但响应时间长，在可靠性测试中实际吞吐量为10.4个每秒，考虑到不同类型的接口场景不同受影响因素不同，该值有一定不准确性。
3)服务出现的异常

根据角色和功能删除权限 20.50%
根据角色Id删除对象功能 2.98%
从数据库获取权限数据 0.09%
获得用户列表 0.09%
刷新用户缓存数据 0.09%
分页获取用户数据 0.04%
删除用户 0.04%
根据条件查询所有角色 0.04%
获得用户数据权限 0.02%
获取当用用户角色权限 0.02%

4)部分接口响应时间长
“从数据库获取权限数据”、“分页获取用户数据”等。

5.2.2 不同接口类型测试

由于全栈可靠性测试发现问题“服务器资源占用会越来越多”，故而进一步测试，选取压力测试里面增加、编辑、获取、分页获取四种类型接口进行可靠性分析。总体服务器资源消耗严重在于内存会持续增加，最终导致服务器宕机。
根据测试数据可得出以下结论
1)服务器消耗瓶颈在于内存，CPU、TPC、I/O等比较稳定；
2)创建类接口会导致内存泄露；
3)编辑类接口总体上稳定，但长期观察内存有缓慢上升趋势，但TPC连接数也同步上升，需要深入Linux调优排查；
4)获取类接口可以长时间稳定运行；
5)接口吞吐量与接口响应时间正比，响应时间长的接口吞吐量低，比较突出的“分页获取用户数据”、“获得用户列表”、“登录”、“从数据库获得权限数据”、“获取组织机构List”。而相对于不同接口类型，获取类的接口比操作类的接口快。

5.2.3 解决方案

1)登录问题
Token过期后大量请求导致系统卡顿
原因，Token保活机制在其最后5分钟内触发，对比时间取得是请求Header中的时间，而保活操作取得是缓存时间，导致Token失效后所有请求都触发保活操作，消耗大量资源。
解决方案：时间统一用缓存中时间
2)DotNetty组件
每次Rpc会长留一个byte[]的变量（客户端和客户端都会），记录已发送字节大小。
修改方案修：不记录已发字节数且Rpc结束之后调用ReferenceCountUtil.Release(buffer);清除Rpc过程中产生的垃圾。
修改DotNetty服务端和客户端，涉及模块Surging.Core.DotNetty、Surging.Core.DotNettyWSServer、Surging.Core.Protocol.Http、Surging.Core.Protocol.Mqtt、Surging.Core.Protocol.Udp、Surging.Core.DNS。
3)禁用Surging性能追踪组件。
原因：使用微软DiagnosticListener组件，记录记录锚点数据用于记录性能追踪数据，BUP目前未启用surging的Skywalking（不完善），所以数据一直长留在内存中，
4)集中式日志
当不使用集中式日志时需要在配置中不启动
5)未使用Module影响
xxxxxxxx.json中Packages->Using配置：ServiceProxyModule、SkywalkingModule

6)Surging生命周期管理引起的内存泄漏
总体上修改后提升了稳定性（详情数据查看3.3中修改后测试结果），首先CPU和Memory振幅变小，系统运行平稳，其次平均响应时间大大缩短，最好为200ms，再者吞吐量提升明显最大接近500个/s。

5.3 稳定测试-可靠性测试

5.3.1 平稳-高并发-平稳

选择接口采用“平稳-高并发-平稳”的测试策略进行测试，设置并发数为1-5-10-15-10-5-30-60-5（接口35个，实际并发高于设定值）。

测试结果

结论：内存能够回收，证明在高并发后能够回收内存资源；

5.3.2 长时间测试

选择部分接口进行长时间运行测试，1千万左右请求

最终内存消耗情况

最终系统运行时间

结论：能够长时间运行，且请求结束能够能存占用情况能够回归到稳定水平。

6 总结

经过三种不同测试方法负载测试、并发测试、可靠性测试。
负载测试证明能平台框架在不同类型接口下能满足预定的稳定指标；
并发测试证明平台所有业务接口能够满足预定的稳定指标；
可靠性测试证明平台能够长时间运行，满足预定的稳定指标

7 附录

附录1-测试接口列表

编号 服务名 接口名 接口URL
1 用户 登录 POST /api/user/login?servicekey=User
2 获得当前登录用户信息 GET /api/user/getcurrentuserinfo?servicekey=User
3 创建用户 POST /api/user/createuserinfo?servicekey=User

详细请翻阅附件2-测试脚本

附录2-测试脚本

JMeter打开

··已删除jmx文件··

PostMan打开
··已删除 postman_collection.json··

附录3-数据库数据统计

原始测试数据库是从253已存库备份而来
1.数据库
编号 数据库
大小
测试项 bup_xxx_stability bup_cap_stability bup_yyy_stability
1 测试前数据 15 MB 8157 kB 15 MB
2 负载测试 15 MB 8245 kB 20 MB
3 并发测试 15 MB 8789 kB 23 MB
4 可靠性测试 26 MB 31 MB 57 MB
2.数据库表大小
编号 数据库 表名 原始 负载测试 并发测试 可靠性测试
1 bup_basedata_stability cap.published 16 kB 16 kB 16 kB 16 kB
。。
3.数据库表行数
编号 数据库 表名 原始 负载测试 并发测试 可靠性测试
1 bup_basedata_stability Xxx_t_xxxx 348 348 348 348
…

随着互联网的快速发展，传统的单工程的性能瓶颈越发明显，分布式系统的优点越发突出。分布式系统具有廉价高效的特点，利用性能相对一般的PC横向扩展，提升服务器性能，通过软件来保障系统的高可靠性。

由于分布式系统存在API接口通信、微服务架构、节点规模大等特点，增加了系统的复杂性和出错的概率，从而很难确保系统的容错机制得到充分的验证，依赖自动化工具来完成对系统端到端验证是不可避免的。

Netflix和类似互联网企业构建的大规模的分布式系统，不可避免地会发生如机器崩溃和网络延迟等故障。为了给客户提供“永远在线”的体验，建立系统可以可靠运行的信心需要软件能够检测、处理各种错误情况，除了少量发生概率较低的极端故障。

华为云可靠性解决方案

在业界，混沌工程被定义为“在分布式系统上进行实验, 以建立对系统抵御生产环境中失控条件的能力的信心”。

基于华为在ICT领域10多年的软件可靠性测试经验，以及工程师们的千万个夜以继日，华为云推出了混沌工程领域应用实践的一套完整解决方案。目标是沉淀通用的故障模式，从入门到精通，从研发到生产，层层推进，以在线演练和专业测评来持续暴露问题，从而推动产品全方位的改进。防止失败的最佳方法就是经常失败，在真实环境测试，而不是模拟环境。

• 全面有效的故障模式库

基于华为在ICT领域10多年的实践积累和数百产品的实际应用的沉淀，电信领域软件的高要求，我们通过正向分析、事故分析、业界案例分析三个维度建立全面的故障模式库。

• 精准高效的故障模拟

我们通过软件模拟各种硬件故障，对应用无侵入，而且跟应用的实现语言无关。

• 端到端全自动化测评

我们实现了智能识别故障对象，而且全自动化运行，自动度量KPI，自动实现风险评估，生成测评报告，测试工程可反复执行。防止失败的最佳方法就是经常失败。在真实环境测试，而不是模拟环境。通过我们的端到端全自动化测评，可以实现这个目标。

华为云混沌工程应用场景

入门级可靠性测试：手工注入

功能：提供对Kubernetes集群、弹性云服务器的单业务实例、单故障模式的注入。

适用场景：开发人员针对确定故障的自验证；测试人员针对可靠性问题回归验证等。

特点：操作简单，故障注入/清除结果及系统的表现清晰可见。

手工注入是混沌工程的入门级功能，操作非常容易，结果直接清晰。

• 首先在服务所在的容器集群或者节点上安装探针，一键安装，秒级创建，速度很快；
• 然后选择注入对象和注入的故障，还可以选择设置告警、CPTS压测工程，就可以完成一次故障注入；
• 再接着就是以5分钟为维度获取监控数据生成测试报告；
• 最后你就可以基于报告来评估服务可靠性的质量了。

全流程可视化操作，只用鼠标点点点就可以了；简单易用，使用门槛低，非常方便开发者和测试人员进行基本的可靠性测试。

进阶级可靠性测试：故障演练

功能：提供对单工作负载的随机故障注入，预置了多种入门级和进阶级演练场景。

适用场景：线下随机故障注入测试；线上例行故障演练、专项演练等。

特点：模型化的场景定义、灵活的编排调度、丰富的评估报告。

故障演练主要使用场景是线上例行故障演练和专项演练。相比于手工注入，故障演练会提供多种入门级和进阶级的演练场景。上图为传统的手工演练流程，与混沌工程提供的故障演练能力对比。

三、四年前我们还处于传统手工演练阶段，全流程的手工进行，后续逐步演变为现在混沌工程提供的全自动化故障演练能力，经我们自己实际使用对比，现在的自动化演练过程比手工更准确和规范，避免人为导致的差错；可靠性专项测试人员投入的时间可以减少80%，端到端效率提升10倍以上。

我们提供如下的预置模板，同时也支持自定义演练任务。

高阶级可靠性测试：自动测评

功能：提供对多工作负载全量的可靠性测评，即将支持。

适用场景：云服务的全量可靠性测评；不同服务、不同版本的可靠性能力对比。

特点：智能对象识别、自动用例生成、无脚本化执行、自动KPI度量、丰富的评估报告。

自动测评最大的特点就是智能对象识别、自动用例生成、无需定制脚本的全自动化执行、自动KPI度量生成丰富的评估报告，可以对不同服务、不同版本的可靠性能力进行对比。

自动测评服务的智能对象识别能力，保证了故障对象覆盖的全面性，能有效避免人工测试出现的遗漏。自动用例生成与无脚本化执行，大幅节省了用例设计和自动化脚本编写的工作，同时降低了自动化可靠性测试对人员技能的要求。

系统预置了3种常见场景模板，同时支持用户自定义。既可以用预置目标快速创建任务，也可以灵活的定制任务。

测评报告

混沌工程通过结合华为云上的CCE、ECS、CPTS、AOM、APM等服务，提供了一套完整的端到端的可靠性测试解决方案，解决了测什么、如何测、如何评价的问题。

可靠性质量评估架构

在华为云上，云服务部署的载体要么是ECS的弹性云服务器，要么是CCE的容器集群，我们现在已经支持对CCE容器集群和弹性云服务器ECS（linux）进行故障注入。

CPTS服务可以实现对应用接口的压测，在故障注入的同时运行，通过CPTS的报告用来评估故障对业务的影响。

AOM可以完成对容器、主机的资源监控，以及自定义阈值告警，故障注入后相关的监控数据和告警数据会被写入混沌工程测试任务的报告中，然后根据可靠性质量评估方法实现自动KPI度量，生成评估报告。

APM提供了调用链功能，在故障注入后，利用调用链可以快速完成问题定位分析。

可靠性质量评估方法上，我们采用的是基于可靠性关键质量属性的KPI评估方式，如下图。从故障模式维度和测试对象维度对KPI进行分析，可以针对自己的服务特性，自主调整评估的参数，然后生成测评报告。

评估属性和方法

目前华为云混沌工程正在公测中，可免费使用，公测申请免审批，申请即可用，详情点击这里，欢迎大家试用。

戳→传送门