银行集群架构非功能测试创新实践范文

本站小编为你精心准备了银行集群架构非功能测试创新实践参考范文，愿这些范文能点燃您思维的火花，激发您的写作灵感。欢迎深入阅读并收藏。

随着中国光大银行（以下简称“光大银行”）打造“一流财富银行”的战略目标深入落地，高并发、高吞吐量的应用系统越来越多，具备弹性扩展能力的大规模集群化系统也相应增多。动辄几十台数量的大规模集群，不仅给开发、运维带来巨大压力，同时也对非功能测试提出了更高的要求。本文以光大银行某系统非功能测试项目为例，阐述在大规模集群项目中实施非功能测试时面临的挑战和应对方法。

一、项目背景

光大银行某系统因数据库服务器容量出现瓶颈，无法满足业务增长需要，需通过对数据库服务器扩容升级以更好地支持业务发展。为此，根据光大银行管理要求，项目组提出非功能测试需求，需要通过非功能测试验证升级后的系统容量，以保障扩容效果和生产安全。

二、项目特点

1.系统架构系统架构通过多层负载均衡，实现快速横向扩展能力，架构节点包括外部接入层、接入主控层、路由层和应用层等，各节点层均可横向扩容。数据库服务器采用主备模式，单点提供服务，不具备横向扩展能力。系统物理架构如图1所示。2.传统测试方案本次测试验证的主要目的是验证升级后系统的最大容量。传统的测试方法有以下三个步骤：（1）部署与生产环境一致的测试环境，包括服务器数量、网络环境以及服务器的主要配置如CPU/内存、存储和数据等。（2）考虑到生产节点部署不是一步到位，因此会增加扩展性验证，即获取单台服务器容量后，逐步增加服务器数量，验证扩展能力（线性程度）。（3）加大压力，直至获取到数据库的容量拐点，因数据库一般不可横向扩展，因此获取到数据库容量拐点即意味着获取到应用系统的最大容量。以上测试方法针对的是服务器数量在10台以内的传统架构，测试环境的准备和测试验证过程，风险都相对可控，但当前该系统采用的是集群架构，服务器设备达到50台左右，CPU总核数达到400C，量变会产生质变，面对新的情况，如果仍然按照传统测试方法则会面临一系列的问题和挑战。3.困难和挑战由于架构变化和集群规模的扩大，非功能测试实施过程中产生了很多新问题、新挑战，主要体现在以下四个方面：（1）一个系统几十台设备，常备测试环境无法满足要求，需要运维设备团队协调资源，但如此大规模的资源调配，其难度可想而知。（2）系统使用的服务器中，除数据库外，基本都是光大银行私有云虚拟机，测试环境申请到的虚拟机无法保证与生产设备型号完全一致，甚至会差异较大，对性能有明显影响。同时，由于私有云特性，CPU和内存等基础资源会根据运行时状态进行动态调整，测试环境中虚拟机之间资源争用往往不期而至，测试结果分析面临很大困难。（3）数据库资源配置较高，有限的测试资源无法支撑获取最大容量的要求。如果要获取数据库最大容量，则测试工作量巨大，测试周期无法保证，对项目建设目标造成重大影响。（4）由于设备数量较多，测试场景复杂，测试过程需要开发配合的事项也会比较多，对于本已经较为紧张的项目周期来说是一个较重的负担。

三、创新实践

“思则变，变则通，通则达”，面对测试资源不足的客观条件，光大银行尝试转变测试思路和方法，另辟蹊径，规避上述难题。首先，对系统架构特点进行仔细分析。本次变更业务服务器（含接入、网关和应用）未做调整，生产运行相对稳定，而业务服务器出现瓶颈时，均可以通过横向扩展提高平台处理能力。进一步分析可以发现，接入层和网关层资源消耗都较低，容量风险很小，因此重点关注应用服务器扩展能力即可。从整个系统架构来看，数据库不能横向扩展，也就是数据库的处理能力决定了系统的最大处理能力。其次，结合理论和历史实践，若数据分布和索引相对合理，数据库服务器CPU使用率不超过60%时，数据库处理能力应该呈线性增长。而各业务处理层相对稳定，基于负载均衡集群架构，横向扩展能力理论上也接近线性。最后，由于业务发展具有不确定性，我们希望本次测试交付的数据不仅是一个静态的容量数据，最好能提供动态的扩展配置表，运维可以根据配置表，针对不同的业务发展调整合理的资源配置。基于以上分析和考虑，新的测试方案确定如下：（1）准备少量与生产配置相同的应用服务器，验证应用扩展趋势以及数据库资源消耗趋势。（2）准备尽可能多的应用服务器资源（不要求与生产配置一致，应用服务器资源消耗不作为考察点），尽可能地对数据库施压，获取一组实测的数据库容量数据，提供给运维作为预警参考。（3）通过线性回归分析工具，对测试结果进行回归分析，并预测随着业务发展，应用服务器资源配置和数据库资源消耗情况。以上方案在与开发和运维的沟通中获得了理解和认可，我们着手开展测试执行。

四、结果验证

按照新方案，本次测试协调了5台与生产匹配的应用服务器资源，同时准备了一些异构的应用服务器，测试结果说明如下。1.横向扩展验证应用层共验证了5个点，按1-2-3-4-5台扩展，获取不同应用服务器数量对应的TPS和数据库服务器CPU使用率。横向扩展实测验证结果见表1。2.数据库容量验证通过异构应用服务器资源，最终实测验证的数据库容量峰值为4456笔/秒，对应的DB-CPU使用率为16.2%。3.容量预测根据横向扩展验证的结果，分别从TPS应用服务器数量和TPS数据库CPU使用率两个维度进行线性回归拟合。处理能力与应用服务器数量拟合效果如图2所示。处理能力与数据库CPU使用率拟合效果如图3所示。从拟合结果看，R2达到0.995以上，拟合效果比较理想。根据拟合结果，我们获得了两个线性关系公式，一个是处理能力与应用服务器的线性公式y=203.2x1.009,另一个是处理能力与数据库CPU使用率的线性公式y=36150x1.126。根据这两个公式，我们可以进一步获取更多的预测数据，如图4所示，可以看到预测数据和实测结果吻合度还是比较高的。至此，我们本次的测试目的全部达到，而且为运维交付了更为详细的动态容量数据，可以更好地指导生产运维。容量扩展预测数据见图5。

五、项目总结

1.方法论说明针对本次测试采用的测试方法，为了方便说明和推广，我们将该方法命名为“验证预测法”，为了更好地理解，对该方法进一步解释如下：（1）验证点1的目的是获取处理能力与资源配置的相关性趋势，需要硬件配置（CPU、内存等）尽可能与生产接近一致，需要获取多组数据（建议不少于5组），是预测的基础。（2）验证点2的目的是获取一组在最大测试环境下能达到的实测容量，为运维提供预警参考，改组数据对应用服务器资源配置要求比较宽松，主要是为了尽可能给数据库施压。（3）根据验证点1的结果进行回归拟合，对预测图4容量测试验证测试法示意区1和预测区2的数据进行预测，为运维提供参考，同时通过验证点2对预测数据和实测数据进行对比，了解预测数据可信度。2.价值和收益验证预测法在应对大规模集群架构的容量测试中具有明显的优势。一是能够有效规避传统测试方法对测试资源过度依赖的痛点，利用较少的资源达成测试目标，大大降低了环境准备成本，缩短测试周期。二是可以提供动态容量数据，更有效地指导生产。运维可以通过查询预测数据表，根据业务发展情况动态配置服务器资源，既能通过扩容来快速应对业务高峰，又能在业务低谷时合理释放冗余资源，做到高效节约配置资源。3.局限性由于是实测验证和预测相结合，图5中验证点2以下囊括的区域基本是可信的，验证点2之外即预测区2的数据，由于数据的不断积累和更新，有可能存在数据热点、索引失效和sequence不足等引发的容量问题，须谨慎使用。有条件的情况下可以在预测区2中增加验证点进行验证。当前银行科技发展迅猛，各种新技术、新架构不断出现，给非功能测试带来诸多挑战，如果仅按照传统的测试方法去思考，很多问题将很棘手且难以解决，而换一种思路或许能够取得意想不到的效果。

作者：田渊文 雷宏波 单位：中国光大银行信息科技部