IT PRACTICE
商业银行全链路性能测试实践上海浦东发展银行信息科技部 刘达伟
一、全链路性能测试的概念及方法
概括来讲，全链路性能测试是指对链路上各业务系统服务器端进行压测的一种大型测试，期间会涉及多个不同系统。实践中，由于商业银行的各类业务系统大多分工明确，所以交易链路上往往会涉及多个不同系统的协作分工，因此要开展全链路性能测试，其主要难点在于如何同时模拟出真实的客户流量，以及如何对链路上的所有系统同时施压。对此，一是要厘清链路上的全部系统及交易性能指标，二是要在合适的系统环境上采用合理的测试及监控方法，即需要进行较为全面的交易链路分析，并根据交易量级准确评估性能指标。
1.交易链路分析
从业务视角来看，点击一次App即可看作是开启了一次业务交互；从系统处理的角度来说，一次业务交互会调度一个或多个服务器执行交易。因此，在开展分析前，首先需弄清系统间的调用关系，以及得到具体的交易码。当前，比较常用的方法主要有两种：一是通过工具对交易码进行跟踪；二是通过对应的全局交易名在各系统中关联查询，从而梳理出一对一、一对多等各种调用关系。以浦发银行手机银行“我的账户”
交易为例，当客户访问App时即开启了一次业务交互，而后面还涉及多个系统为其提供服务，包括处理交易数据、客户权限/信息等。“我的账户”交易拆解如图1所示。
图1中，transaction1并不涉及后台，为数据库查询类交易；transaction2-transaction5与后台为一对一调用关系，分别对应调用了后台A-D个系统的back_ transaction1～back_transaction4交易；transaction6为
摘　要：在“互联网+”浪潮的推动之下，移动应用的数量和种类不断增多，尤其在金融领域，手机银行更是发展为银行服务客户的主要渠道之一，而如何在有效应对用户和流量激增的同时，保证信息系统的平稳运行，也成为商业银行必须面对和解决的重要问题。对此，全链路性能测试技术提供了全新的解决方案，不仅能预估业务容量上限，还可提前发现并解决系统性能问题，从而更好地确保银行信息系统的运行安全。基于上述特点，本文重点介绍了商业银行实施全链路性能测试的路径和方法，以及浦发银行在手机银行系统全链路性能测试中的实践经验。
关键词：手机银行；全链路性能测试；交易链路分析；性能指标分析；服务器端测试
IT实践IT Practice
一对多调用，对应了back_transaction5/6两个不同系统的后台交易。综上，只有当6个交易同时响应成功，“我的账户”才会给客户反馈交易成功信息。
2.性能指标分析
全链路性能指标的设定主要可从两个维度考虑：一是在链路层面，可分为强业务关联链路和弱业务关联链路（如图2所示）；二是在系统层面，可采集链路上每个系统的性能指标，包括在线/并发用户数、交易响应时间、交易处理能力、服务器资源使用率等。
（1）按强/弱业务关联梳理交易链路性能指标
在链路层面，强关联链路主要面向的是流量聚集、流量洪峰类的业务场景，即主要的业务集中入口可称为“强关联链路”，如图2中的transaction1即为强关联链路。与之相比，非业务集中入口但又实际会发生的交易通常称为“弱关联链路”，如图2中的transaction2、3则为弱关联链路。一般而言，强/弱关联交易入口并没有交集，但对于测试场景和模拟压测来说，强关联链路中所有的交易处理能力、成功率都必须得到保证，而弱关联链路中的交易在确保自身达标的前提下，不能对强关联交易的性能产生明显影响。这种影响往往不是在业务入口产生，而是通过链路上的后台系统进行传导，从而在客户端表现出来，所以强/弱业务关联交易必须有明确的性能指标。在实际工作中，链路性能指标的设定也可分两种情况：一种情况是在已知生产环境流量的前提下进行，即从系统生产环境中提取某个时间段的运行数据，再细化分析其包含了哪些交易及每类交易的峰值处理能力；另一种情况为新增交易，通常可按业务规划直接提供性能指标。
（2）按接口交易维度梳理单系统性能指标
在系统层面，性能指标主要可分为业务服务消费方和业务服务提供方。其中，业务服务消费方类似于手机银行系统，是用户请求的主要来源；业务服务提供方通常指后台系统，类似于客户关系管理系统、营销系统，是服务的支撑系统。例如，图2中系统A提供了A_Server1- A_Server14共四个接口服务，如果在同时间段的某个营销类场景需要调用这些接口，则A系统需要满足各个接口的交易处理能力之和，而B系统也是同理，从而计算出各接口交易处理能力按类别占比（如A_Server1：A_Server2：A_Server3：A_Server4＝20%:40%:20%:20%）的指标总和。通常情况下，需按接口被调用次数来设定占比，并对总量适当放大，最后才以此作为指标对单系统进行接口交易混合压测。
二、全链路性能测试的测试策略
app接口测试工具1.测试环境及数据准备
在全链路性能测试过程中，往往需要对系统配置参数不断调整优化，并对使用过的测试账号数据进行还原，因此生产环境通常不适合反复压测。所以在硬件方面，
图1  “我的账户”交易拆解
IT PRACTICE
建议各系统按生产同等配置以1:1 的比例搭建测试环境，但不建议高于生产配置，即服务器硬件配置、操作系统/中间件参数配置、网络策略/带宽、防火墙配置等应与生产环境保持一致，如个别系统不具备条件则可采用挡板替代。
此外，对于铺底数据，建议在现有生产数据量的基础上，按用户、业务量的增长趋势，通过预估未来某个场景时间点的业务数据量来进行准备。同时，测试数据还需考虑全链路测试的连通性以及能否被有效使用，即确保对应的测试用户账号、权限、相关交易等在链路上的各系统中均能有效使用且数值一致，如客户号、手机号、账号、卡号、余额、客户等级等。
2.单系统及全链路测试策略
在测试策略方面，通常可先确认单系统需满足的性能指标，再验证全链路交易需满足的性能指标。在此过
程中，单系统性能测试策略是指按设定的业务占比模型，使用预期的在线/并发用户数混合压测单系统交易接口，测试指标包括交易处理能力、平均响应时间、服务器资源等，且只有当单系统环境压测达标后，才符合全链路测试环境的接入标准。
全链路性能测试策略是指模拟业务入口流量，按强/弱关联链路指标进行多链路混合发压，其核心内容为
恒定发压验证性能指标与梯度发压定位性能拐点。其中，恒定发压验证性能指标是指按业务占比分配在线/并发用户数，对强/弱关联链路保持恒定压力发压，以监控链路处理能力、交易成功率以及系统服务器资源使用率等是否能全部满足指标要求；梯度发压定位性能拐点是指按业务占比分配在线/并发用户数，对弱关联链路保持恒定压力发压，并逐步按梯度增加强关联链路的用户和压力，直至链路性能指标超标，以定位链路处理
2  交易链路示意
强关联
(弱关联
)
IT实践IT Practice
能力的性能拐点及瓶颈。
3.测试监控策略
在监控策略方面，测试工具主要用于模拟客户请求协议，常见协议包括Http或Tcp，而使用Loadrunner、JMeter工具均可模拟发压。此外，常用的服务器资源监控工具包括Nmon、Dstat、Spotlig
ht等，实践中根据测试情况可灵活选择。其中，对于交易监控来说，测试工具通常可以直接统计交易平均响应时间、交易成功率、系统处理能力等指标。交易监控项统计描述见表1。对于服务器资源来说，监控项主要为CPU、内存、进程等，监控对象包括X86虚机、实体机、Docker容器、中间件及数据库，一般可采用监控工具或通过产品级的监控平台实现监控。系统服务器资源监控项统计见表2。
三、浦发银行全链路性能测试实践
在浦发银行线上业务中，权益抢兑是通过手机银行开展的一项非常典型的营销活动。具体来说，浦发银行根据客户的上月日均资产达标情况，将客户等级划分为了V0－V12以及VVIP1－VVIP4，而不同权益的客户可在每月10日的10点整，通过手机银行权益专区领取相应的权益礼品。从业务角度来说，该业务属于营销类的权益产品秒杀兑换活动，因此其瞬时流量峰值对系统的冲击非常大，而运用全链路性能测试方法对该场景进行压测，将可提前预估生产环境可支撑的用户规模和交易流量上限。权益抢兑活动业务入口示意如图3所示。
1.权益抢兑链路交易及性能指标分析
在对权益抢兑开展全链路测试的过程中，浦发银行首先对达标用户总量进行了评估，得出近半年“视听权益”及“美好生活权益”生产环境的达标人数在7万～8万之间，因此决定取总数的1/10进行模拟发压。其中，生产环境为上海和合肥双边环境，而压测仅模拟了上海单边，因此最终参与测试的用户数量在3万
～4万。在此基础上，浦发银行通过对流量较大的强关联链路进行梳理，根据生产峰值业务量设定了“视听权益”“美好生活权益”领取及支付交易的链路性能指标。此外，考
表1  交易监控项统计
表2  系统服务器资源监控项统计
IT PRACTICE
虑手机银行在提供权益服务的同时还提供其它他服务，因此还设定了登录、我的频道、我的账户、生活频道、转账、理财、基金等弱关联链路，并取近期峰值交易处理能力进行了模拟发压。
2.权益抢兑场景模拟压测及监控
在生产测试环节，浦发银行搭建了与生产环境1:1等配的仿真测试环境，使用Load runner工具模拟发压，使用脚本透传方式进行服务器资源监控。同时，基于自研发的服务引擎将监控数据实时写入了Influxdb数据库，并采用Grafana工具对压测过程中的链路处理能力、平均交易响应时间、容器CPU资源、数据库CPU资源等监控结果进行了实时展现。权益抢兑链路压测架构如图4所示。
在实际测试过程中，浦发银行分别按35 000名、40 000名、45 000名的在线用户梯度执行了3轮场景压测。压测结果显示，第1轮35 000名用户的“视听权益”“美好生活权益”等交易处理能力不达标；第2轮40 000名用户的所有指标都满足；第3轮45 000名用户压测登录及视听交易的处理能力、响应时间、成功率均不达标。基于上述结论，最终确定了该全链路的性能拐点为40 000名在线用户。
3.常见测试问题及应对策略
在实际测试过程中，根据不同的系统架构、交易链路和应用特征，后台系统往往会遇到各种不同的性能问题。为便于同业参考，笔者梳理了手机银行测试过程中较为常见的一些共性问题。
一是服务器资源不足，即一旦链路中有服务器资源超标，易导致交易响应时间增加、处理能力下降、交易大量报错等结果。对此，如果手机转账微服务容器CPU 资源使用率达到100%，可尝试通过扩容硬件、容器资源来解决资源不足的问题。
二是测试数据不支持业务流程使用。例如，测试数据在A系统中可用，但在B系统中不可用，将无法完整模拟生产环境中的实际业务流程。对此，可在测试数据准备环节采用同一套规则、账户去创建相关数据。同时，铺底数据建议对关键信息数据进行脱敏后导入
图3  权益抢兑活动业务入口示意

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。