论文分布式系统架构下银行应用系统的性能测试技术和实践，本文是关于性能测试方面论文范文集和系统架构和性能测试和分布式相关参考文献格式范文.
随着移动互联网、云计算、大数据和社交网络的蓬勃发展,传统金融业运营模式面临着巨大挑战.面对海量数据和交易数量的急速增长,分布式架构技术在银行应用系统中的运用越来越广泛.
中国工商银行（以下简称“工行”）从2014 年启动了IT 架构转型工程,其中一项重要内容就是加快分布式架构的使用,推动信息系统从传统集中式架构为主的架构体系,向集中式和分布式架构有机融合的架构体系转型.
经过三年的建设,工行的“全新技术体系框架”已初具雏形.目前工行已经构建了分布式服务框架、分布式事务管理、分布式缓存平台、分布式消息平台和分布式对象存储平台等标准的分布式技术框架,同时也引入分布式数据库满足分析型业务处理对弹性存储与计算、高性能和高可靠性的要求,有效支撑了分析型业务量快速增长.此外,工行还综合运用Hadoop、分布式数据库和流数据处理等各类分布式技术,构建大数据云,为客户营销与服务、风险管控和经营管理等提供数据支撑.
用户需求的日益增长,对银行服务的质量、可靠性提出了越来越高的要求.因此,分布式系统架构下的性能测试变得尤为重要.本文介绍了基于工行分布式系统架构下银行应用系统的性能测试技术研究与测试平台E-STRESS 的实现.
一、现状与挑战
工行开放平台在“双核心”架构体系中的重要性得到进一步提升,与此同时对开放平台的服务支撑能力也提出了更高要求.高可用、高吞吐量、快速响应和可扩展等分布式架构的特性,不仅对系统的性能提出了挑战,也对性能测试既有工作模式和方法提出了挑战.相对于传统集中式交易系统,分布式架构的性能测试目前主要面临以下三方面压力.
1. 并发性测试成本高
分布式系统对客户端发压要求极高,传统集中式交易系统TPS 不超过100,而分布式系统动辄上万.业界主流的性能测试工具Loadrunner 和Jmeter,均支持分布式发压,但上述工具在执行性能测试场景时,需要人为判断*器是否可用并手工选择*器,人力成本非常高.
2. 无法准确评估系统上线后的扩展能力
可扩展性是分布式计算和并行计算中的重要指标,它描述了系统通过改变可用计算资源和调度方式来动态调整自身计算性能的能力.需要进行多轮测试,通过不断的尝试调整设备资源及目标压力值,直到系统达到极限处理能力.因测试与生产的资源差异较大,测试环境资源有限,目前只能利用较小的测试集群规模去评估投产后的表现.
3. 无法高效快速定位被测系统的性能瓶颈
分布式系统测试环境服务器数量较多,针对每台服务器都需要手工收集并分析各项性能指标,监控分析、整理及指标统计准确性较低,无法高效快速地定位被测系统的性能瓶颈.
二、设计与实现
1. 解决方案
为有力应对分布式系统性能测试的新挑战,工行软件开发中心在不断摸索及实践后,针对分布式性能测试面临的三大痛点提出了以下解决方案.
（1）引入*资源池
转变*模式,*以资源池的方式存在.资源池是一种配置机制,由资源池管理器提供一定数目的*资源.当有请求调用时,资源池自动分配资源,并标识为“忙”；当资源使用完毕后,资源池自动回收资源,以便被下一请求调用.在测试执行前可根据需要选择发压所需要的*器,在Windows 或Linux 服务器上启动*客户端,实现与*资源池进行通信.规避Loadrunner和Jmeter 需要手工选择*器、测试成本高的问题.
（2）自适应的扩展性测试
为避免出现系统上线后的扩展能力评估不准确问题,提出自适应的扩展性测试方法,引入阿姆达尔（Amdahl）定律及相关公式用于计算自适应启动并行处理结点的个数.该方法可实现固定负载下设备资源的自动调配,同时可根据实时运行情况自动调整交易发送模拟器的目标压力值,避免手工调配时可能产生的设计遗漏或不合理等问题,提高测试场景的有效性和执行效率.阿姆达尔定律描述如下：系统中对某一部件采用更快执行方式所能获得的系统性能改进程度,取决于这种执行方式被使用的频率或所占总执行时间的比例.
对于固定负载情况下描述并行处理效果的加速比s,有如下公式：
其中,a 为并行计算部分所占比例,n 为并行处理结点个数.
特别地,当1-a等于0 时,s等于n,此时没有串行,只有并行
当a等于0 时,s等于1,此时只有串行,没有并行自适应启动主机的台数由阿姆达尔定律的变形公式算得：
单模块执行的时间占比：
T 为整个系统处理单笔交易所占时间,t 为瓶颈资源处理单笔交易所占时间（根据正式测试前的基准测试获得）.
处理效果加速比：
经公式1 至公式3 的推导,最终得到如下公式：
n 经向上取整后,即为自适应启动并行处理结点的个数.
（3）协作式轮询实现各项性能指标的自动收集分析传统性能监控通常是一个存在于网络中某个位置的集中式守护进程,通过对每台主机的频繁轮询来收集系统状态.一个守护进程只能对一定数量的主机进行轮询,一旦有主机加入网络就会增加监控系统服务器的负荷.为解决上述瓶颈,考虑每台主机都是积极的参与者,它们相互合作,有机地分散工作量,数据被复制、分发和共享,从而避免了某一节点的负荷过重.这种协作式设计意味着每个新加入网络的节点都会提升轮询能力,每台主机都会积极地上报指标数据,主机即监控系统,可实现高效快速的问题定位.
2. 平台设计思路
在上述解决方案的基础上,工行软件开发中心自主搭建了分布式自动化性能测试平台E-STRESS,由测试管理系统、执行调度系统、监控分析系统及扩展性分析系统四部分组成,分别负责平台功能管理、任务执行调度、日志收集分析和自适应扩展性测试.平台总体框架如图1 所示.
（1）测试管理系统
测试管理系统采用B/S 界面,通过可视化配置式操作,引导用户进行测试用例及场景设计,在线编写测试脚本,实现任务自动调度,并将测试结果及监控日志自动推送至用户.同时测试管理系统利用SVN 插件进行脚本管理,以图形化形式直观展示,对测试资产进行集中化管理.
（2）执行调度系统
用户可在E-STRESS 上预约测试任务并以预约时间记入任务表,后端进程定时扫描任务表,若当前时间大于等于预约时间,则自动将任务分发至Controller控制台运行脚本,Controller 负责管理和控制测试流程以及下发测试任务.Controller 下挂*（agent）资源池,agent 负责启动压测进程和线程,压测目标服务器.Controller 会把压测脚本和压测数据分发到一个或多个agent 去执行,通过测试用例中配置的*、进程及线程数并发调度测试脚本,实现测试执行的无人值守.
（3）监控分析系统
E-STRESS 通过目标服务器上部署monitor 来不断轮询监控目标服务器和被压测站点,监控指标包括平均响应时间、TPS、事务成功率等、运行时并发用户数、CPU、内存、磁盘和网络等.monitor 通过与目标服务器操作系统交互自动获取指标数据,并与同一集群内的其他服务器共享数据.集群内的每个monitor 已知同一集群内其他服务器所收集的数据,并默认向任意连接monitor 端口的客户端实时上报整个集群状态的监控数据.
（4）扩展性分析系统
扩展性分析系统是通过监控分析系统上报的性能指标监控结果,并解析计算压力池中各主机的资源监控数据（CPU、内存、磁盘和网络等）,定时与预先设定的阈值做比较,并采取进一步措施.扩展性分析逻辑如下：
①若某项资源超出阈值且未达到目标TPS,则平台自适应启动相应类型的主机,纳入压力池,进行下一轮测试.
②若所有资源均未超出阈值且未达到目标TPS,则通知交易发送模拟器向上调整并发数,进行下一轮测试.③若某项资源超出阈值且未达到目标TPS, 而此时资源池中所有瓶颈资源都已纳入压力池,则通知模拟器终止测试.
扩展性分析测试流程如图2 所示.目前E-STRESS平台的扩展性分析系统只完成了向上调整并发数的逻辑分支,缺少对被测主机的管理和调度.
三、实践与成效
1. 测试实践
用户通过web 管理页面在线创建及编辑测试脚本,在页面上通过配置方式快速创建场景并关联测试用例和脚本.通过场景的自动化调度,可实时在测试报告中查看各类性能测试指标,并通过邮件订阅管理推送测试结果至用户,所有测试资产在E-STRESS 上进行传承及复用.平台自动化性能测试流程如图3 所示.
（1）创建标准化测试场景图
用户进行测试策略以及业务指标的设计,并将测试场景保存入库,供用户查询,测试策略包括：负载测试、容量测试、疲劳测试、极限测试、失效恢复测试、配置比对测试和可扩展性测试.场景创建如图4 所示.
（2）在线脚本编辑及调试使用Python 或Groovy 语言在线编辑脚本,点击“验证脚本”,可直接进行调试,并在页面下方查看控制台输出.
（3）创建标准化测试用例
E-STRESS 可为一个测试场景创建多个测试用例,根据测试场景的测试策略,提供用户多样、灵活的场景调度策略（见表1）.
用例创建如图5 所示.
（4）实时展现性能测试指标
E-STRESS 可同步显示各类业务指标、发压客户端及被测服务器的各项资源指标,场景运行完成后,用户可在平台上轻松查阅完整的性能测试报告.性能监控结果如图6 所示.
（5）邮件订阅
可开启后端报告分析订阅服务,自动定时扫描测试结果中的各项指标数据,经过数据处理,将订阅信息邮件通知用户（见表2）.
2. 实施效果
E-STRESS 目前已成功应用于工行五个分布式应用系统的性能测试中,形成了经典场景案例的最佳性能测试实践.在降低测试成本以及提升测试质量方面效果显著,总结如下：
（1）显著降低测试成本、提升测试效率
测试脚本编写、场景配置、监控部署和结果分析生成等环节的执行成本显著降低,所有的操作均可在平台上完成.一个上千TPS 的接口仅需1 分钟即可完成测试场景的配置,无需手工选择*服务器,也无需人工介入收集分析性能指标监控结果.平台可实时定位被测系统的性能瓶颈,一名零基础的性能测试人员可在30 分钟内完全掌握测试方法,工作效率可提升70%.
（2）显著提高评估系统上线后扩展能力的准确性平台通过自动调配设备资源,根据实时运行情况自动调整交易发送模拟器的目标压力值,有效规避了手工调配时可能的设计遗漏或不合理等问题.相较以往的抽样运行测试场景,通过平台进行扩展性测试可快速获得详尽客观的系统扩展性评估数据,大大提升扩展性测试的完备性和准确性.
四、总结及展望
综上所述,E-STRESS 平台的扩展性分析系统尚在持续完善阶段,后续工行软件开发中心将进一步聚焦被测应用系统服务器的管理和调度,实现完整的扩展性测试.同时将高可用测试纳入E-STRESS 平台的后续建设,自动模拟各类系统故障, 使E-STRESS 平台延伸为分布式系统的非功能性自动化测试平台.
此文点评：该文是大学硕士与性能测试本科性能测试毕业论文开题报告范文和相关优秀学术职称论文参考文献资料，关于免费教你怎么写系统架构和性能测试和分布式方面论文范文.
参考文献：
1、 电力营销系统软件性能测试 前言近二十年来,我国电力系统的软件发展越来越快,发展的规模和结构也越来越趋向复杂化 与此同时规模带来的扩张,对软件的可靠性和实用性也带来了不小的影响, 并且日益明显, 所以在软件技术的层面上, 一方面.
2、 关于新华社音频新闻采编制作系统互联网化功能延展和实践 摘要全媒体时代,新华社音频新闻的业务将面临全新变革,支撑音频新闻采编的技术系统也需要进行升级 本文主要针对音频新闻采编制作系统在多维度稿件采集、语音智能识别、移动互联网第三方平台推送的技术和方案,进行.
3、 高移动性无线通信系统空间信道测量技术 前言在下一代无线技术发展中,高速铁路通信系统是重要内容,但是HSR 信道的完全表征会为信道建模带来挑战,HSR 信道场景本身具有多样性特点,需要对大量测试数据进行采集,可能会为信道测量工作带来挑战,对.
4、 ERP系统运维管理的开展实践与相关问题阐述 一、ERP系统的概念与内涵当前国内制造型企业已经意识到大数据背后所潜藏的价值,其怎样才能展现其中的价值对于所有制造型企业而言,是一项难度巨大、挑战性极强的工作 ERP 在中文的意思是企业资源计划,ER.
5、 电动汽车充电系统分级和测试方法 1充魄模式一个完整的车用充电站系统,包含直接充电设备、配电设备、管理辅助设备……三个部分 直接充电设备将断路器 ( Breaker)及电路设计、充电插头加电线 (PlugCable)、充电设备外壳.
6、 图书馆情报系统中信息融合技术的应用 关键词图书馆；情报系统；信息融合技术；研究应用摘要作为图书馆管理工作的重点内容,图书馆情报咨询工作意义重大 其直接影响馆藏资源的有效利用,也对社会文化及科研探讨起到辅助作用 在信息技术迅猛发展的今天,.