查看原文
其他

实战丨​​​全链路生产压测探索与实践

金融电子化 金融电子化 2021-08-11

欢迎金融科技工作者积极投稿!

各抒己见!

投稿邮箱: 

newmedia@fcmag.com.cn

                                 ——金融电子化

文 / 中国银联科技事业部高级总监    欧鹏

       中国银联科技事业部总监    翟威

近年来,随着用户量和交易规模的逐年增长,尤其是“银联62节”等营销活动的火热开展,云闪付APP及相关上下游系统(后简称“云闪付”或者“云闪付系统”)应对短时海量访问冲击的技术能力,越来越成为支撑业务发展的重要保障。


初期对于云闪付的压测工作主要在研发测试环境进行,对单节点或者集群发起高并发的服务调用,通过分析其在研发测试环境下的表现情况,推算出生产集群的性能,并为生产集群的容量规划提供参考依据。但该方法存在以下几个问题:


一是测试集群规模相比生产集群较小,生产集群的性能是通过测试集群的压测数据简单乘以系数推算得到的,无法准确评估生产集群性能及不同模块间的资源配比。二是研发测试环境的基础设施与真实的生产环境存在差异,如各种网络安全设备、带宽、系统拓扑、数据容量等。三是测试环境进行压测的系统相互之间是独立的,即使各系统单独的性能测试已达标,但在生产环境多系统串联后往往存在“1+1<2”的情况。


由于这些问题的存在,基于研发测试环境的压测所推演出对生产集群的扩容方案往往不够准确。如果资源评估多了,造成人力物力的浪费;评估少了,则会引发生产问题,影响用户体验,更有甚者在营销活动现场引发群体事件。综上,在生产环境引入全链路生产压测,可以真实、高效地评估生产系统链条中核心业务的实际承载能力,指导限流配置、熔断策略、服务降级策略等工作,同时及时发现系统瓶颈,在营销活动开展前及时调配服务资源,最终保障营销活动的平稳运行。


本文分享了中国银联在探索全链路生产压测过程中的碰到的一些挑战和解决方案,并对具体实施方案进行了系统性的介绍,希望可以对大家建立符合自身特点的全链路生产压测体系提供帮助。


挑战与应对

1. 模拟流量真实有效

如何模拟营销期间的流量情况,包括总体流量、以及分解到各API接口的流量和比例,是确保生产压测成功进行的最基础最重要的一环。如果模拟流量无法做到贴近真实,就可能产生无法预知的后果。可以设想一下,如果压测设计方案疏漏了某冷门接口,没有做限流设置,在正式营销期间,很容易会被突如其来的海量请求压垮,并引发其他关联业务的雪崩。


业界解决此问题一般有业务模型梳理、真实流量录制回放、灰度分流等多种方案,各种方案各有优劣。


(1)业务模型梳理:压测方案设计人员需要对营销业务场景和全业务链条系统有整体的把握,有一定的难度。优点是可以全方位无死角的将营销活动的业务场景分解到具体的API接口和链路上。


(2)真实流量录制回放:录制并提取真实流量的元数据,并对关键信息(如用户ID,手机号等)做参数偏移,批量生成模拟流量。


(3)灰度分流:直接将真实生产流量按照一定规则分流到压测环境。日常流量情况与营销期间并不一定一致,尤其是一些冷门业务,因此该方案更适合于日常压测而非营销前的大型压测。


在实践过程中,由于历次营销活动内容及侧重点都会有所变化,并综合考虑中国银联自身情况,目前主要采用业务模型自上而下分解的方式来设计压测方案,并在生成模拟流量时,对关键信息做参数偏移,保证流量的多样性。


2. 保证系统安全可控

业务安全是全链路生产压测过程中始终要绷紧的一根弦,尤其在被测系统是一款金融应用的情况下,必须做好在管理、业务和技术等多个维度的层层防御措施,保证资金的安全以及压测过程中系统可以平稳对外服务。


(1)管理措施:时间上尽量选择在业务相对较少的夜间进行,压测总时长也要控制;对压测方案中可能导致系统不稳定或资金风险的部分进行多轮充分的评审;设置压测专用的证书、密钥并严格保密,且仅在压测期间启用。 


(2)业务措施:控制压测活动交易金额,使用压测专用的机构、商户、卡号、账户信息等。


(3)技术措施:针对压测发现的系统瓶颈,如短时间内无法通过资源调配来消除,则应准备相应的限流措施、服务降级措施和熔断策略,避免雪崩效应;对压测产生的数据和真实生产数据做严格隔离,避免互相污染。


3. 压测任务高效实施

云闪付作为一款ToC的应用,版本迭代速度较快。为保证生产压测环境、系统版本和参数等与最终营销期间一致,留给压测的时间窗口非常短。在有限的时间窗口内,为指导系统资源比例和限流策略的不断调优,往往需要安排多轮压测,密度甚至达到每天一轮,对整体压测计划的组织协调提出了较高的要求,对参与人员的身体和心理压力也非常之大。通过成立联合指挥部和建设生产压测平台,可以大大提升压测任务的执行效率。


(1)成立联合指挥部:业务部门、运维部门和科技部门共同组成联合指挥部,每天对压测结果进行复盘分析,针对性的调整下一轮压测策略和方案,协调各相关部门做好系统版本变更、网络变更、数据清理等准备工作。


(2)建设生产压测平台:早期银联生产压测为半手工半自动化方式。面对庞大的压测集群和生产系统集群,夜间需投入大量的人力执行压测、收集数据、观测环境资源和应用状态。多轮高强度夜间压测工作不仅对相关参与人员的身体和心理健康造成了很大挑战,也会存在某些异常信息无法被及时观测到的情况,不利于后续问题的分析和改进工作,因此需要研发一款可以根据实践情况不断改进的生产压测平台。


实施方案

通过几年的实践和不断优化,中国银联已逐步建立起一套从业务模型梳理、生产系统配合改造、研发环节的性能测试、生产压测数据准备到最后的压测实施、数据收集及问题分析的全链路生产压测整体实施方案,并在历次营销活动中经受住了考验。下面对压测实施过程中的关键节点做一下介绍。

图1    全链路生产压测整体方案


1. 梳理业务模型

因云闪付营销活动的业务场景多且复杂,在将其业务指标解析为后台服务并进而形成压测模型的过程中,为确保没有遗漏,主要通过以下三个方面进行梳理:


(1)建立核心压测业务模型:一个业务流程通常由多步后台服务调用组成,以业务流程出发,首先把所有业务流程逐一分解成后台服务调用,其次汇总叠加关键业务流程对应的后台服务调用,最后根据这些业务流程的压测指标,计算每个后台服务保障指标,建立核心压测业务模型、明确压测指标值。


(2)补充压测业务模型:大型营销活动一般都配套有新业务功能上线,这些新功能新服务未经生产验证,容易成为性能短板,必须加入到压测业务模型中。同时,常规业务如登录、签到、查询等,作为重点背景流量,也需加入到压测业务模型中。


(3) 调整压测业务模型:除了正常业务梳理之外,还会抓取生产上流量排名Top N的热点URL,并与压测业务模型进行比对分析。对于合理的调用,补充到压测业务模型中;对于不合理的冗余调用,则优化该业务流程。


通过业务模型的梳理,形成了最终需要压测的服务接口列表以及各自的性能指标,同时也明确了参与营销活动及生产压测的上下游系统,为后续的工作打好基础。


2.生产系统配合改造

参与全链路生产压测的系统要具备可测性。可测试性主要体现在以下几个方面:一是过滤掉不能参与全链路压测的系统,如用户登录的图形验证码系统、调用外部接口等;二是压测数据要隔离,不污染生产环境,方便压测结束后批量清理,不影响真实业务数据;三是安全控制,压测数据不能使用真实的证书和密钥,保证系统的安全,需要用压测证书和压测密钥。所以生产系统要做相关的配套改造,确保测试能够实施。除了满足以上要求外,还设计了全链路测试跟踪标识,用于区分真实生产流量和压测流量,该标识在所有系统中透传并在日志和数据库的必要环节进行持久化,有了该标识,能更有效率地定位、分析、总结压测情况,为系统优化提供依据。

图2    生产系统配合压测改造示意图

 

3. 单链路性能测试

根据梳理业务模型得到的服务接口列表,在研发测试环境逐一进行的单链路性能测试,是全链路生产压测之前的必要步骤。


单链路性能测试是指系统的各层服务均只部署一个节点,即最小化部署,要求整个链路要联通,对于非关键环节可以进行mock,然后按接口对整条链路进行性能测试。


通过单链路性能测试,首先是为了发现代码缺陷,如多线程并发未加锁、不正确使用资源池等,所导致的性能问题;其次,验证系统的性能是否满足设计指标;然后,可以明确性能的瓶颈点,形成不同应用层级之前的合理配比,最大化系统资源利用率;最后,进行横向扩展测试,验证系统的横向扩展能力。


在研发测试环境,可以不断的测试、调整策略、问题快速修复、再测试等,尽量把更多的性能问题在研发测试环境解决,而非在生产环境的全链路压测中暴露。


4. 全链路生产压测准备及执行

经过调研互联网头部企业在双11等大促场景的生产压测情况,结合中国银联自身的业务属性和系统特点,定制化的开发了一个生产压测平台。


根据业务模型的梳理结果,可以在生产压测平台较为便捷的编排出各类复杂的压测场景,并通过参数化的偏移,生成海量测试数据。同时平台还支持压测流量阶梯发起、实时监控被测场景、压测数据自动收集、自动生成压测报告等功能。原本复杂繁琐的准备和执行工作,基本做到了平台化。


实践效果表明,基于生产压测平台执行全链路生产压测,相比半自动化半手工方式,参与人数降低了60%,执行效率提升了80%以上。


5. 数据收集及指导改进

生产压测平台在执行全链路生产压测任务过程中,可以自动收集全链路生产压测过程中产生的各类数据,并生成压测报告。除了各业务场景、各服务接口的QPS、响应时间、错误率等必要的性能数据,平台还会收集系统层和应用层在压测过程中产生的各类数据。在系统层,收集了各层节点资源使用情况,如CPU、内存、跨服务调用的网络耗时、网络带宽、磁盘IO情况等。在应用层,收集了Java类应用的GC信息、各类连接池的水位、抽样抓取应用抛出的业务异常等。


基于以上丰富的数据,一方面可以较为准确的评估系统实际承载能力,指导限流配置、熔断策略、服务降级策略等工作,另一方面可以及时发现系统瓶颈,通过调配服务资源,在营销活动正式开展前消除隐患。


总结及展望

从近年来云闪付营销活动的顺利举办来看,全链路生产压测工作对后台系统的安全稳定运行起到了举足轻重的作用。在营销活动期间,系统承受住了比平时高出几十倍的流量压力,没有出现由于性能瓶颈导致的服务不可用,取得了令人满意的效果。


未来计划一方面在云闪付逐步引入常态化压测,通过划定性能基线和日常小规模压测,可以较为快捷的了解到日常版本对生产性能的影响,有利于及时做出调整,为营销活动大型压测减轻压力。另一方面总结提炼在云闪付生产压测过程中的经验教训,形成更加通用的全链路生产压测工作方法论和工具,推广应用到更多的系统,更好的保障银联生产系统整体安全稳定运行。





往期精选:

(点击查看精彩内容)


● 实战丨分布式架构转型之服务网格探索与实践

● 实战丨东吴证券的企业存储转型之路

● 实战丨广发证券迈向自动化测试新时代

● 实战丨数字征信赋能,普惠小微三农——鞍山市银行业金融机构服务小微企业和三农发展的实践

● 实战丨金融行业信息化项目建设与服务实施的预算模型需求探索






关于仿冒我刊收费的声明





我刊自创刊以来,从未向投稿人收取过任何费用。任何以刊发文章为名向投稿人收取费用的行为,均属于对投稿人的欺诈行为。


我刊官网地址为 www.fcmag.com.cn。

我刊投稿邮箱为 fcmag@fcmag.com.cn。


对于仿冒我刊网站、网页的违法行为,我社将追究其侵权责任,以维护我社和投稿人的合法权益。仿冒网站、网页举报电话:010-88232443



《金融电子化》新媒体部:主任 / 邝源  编辑 / 潘婧 傅甜甜

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存