基于计费流处理的全链路压测-江苏移动SRE运维实践
Posted IT运维新视界
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了基于计费流处理的全链路压测-江苏移动SRE运维实践相关的知识,希望对你有一定的参考价值。
随着移动互联网的盛行、4G业务以及物联网业务蓬勃的发展,业务服务调用量和话单量均呈爆炸式几何级增长,面对如此庞大的业务量,如何保证生产系统性能满足实际业务量需要?同时在容量规划时,如何合理精准评估所需要的资源?成为运维人员面临的两大难题。传统的全链路压测主要是针对业务查询与办理,但在移动运营商业务支撑领域不仅业务查询受理的性能要求高,需要全链路压测保障,核心计费系统对性能要求也非常高,同样需要全链路压测。
目前有很多的开源工具可以提供分布式压测的方式,比如开源软件jmeter、Ngrinder、locust等。
比较点 |
JMeter |
Ngrinder |
Locust |
实现语言 |
Java |
java/python |
python |
使用方式 |
C/S或Command |
B/S |
B/S |
支持分布式 |
master/slave |
controller/agent |
master/slave |
资源监控 |
monitor/plugin,自开发 |
monitor方式 |
不支持 |
社区活跃度 |
活跃,文档完善 |
较活跃 |
较活跃 |
脚本的维护 |
本地 |
内置SVN |
本地 |
测试脚本形式 |
java/python |
java |
pytho |
当前业界常用的链路压测工具主要包含两类:一类基于开源的Jmeter做了二次封装,另一类是自研的压测系统,通过分析主要在以下方面不满足移动运营商支撑系统的需要:
1)测试效果有效性:一般是使用测试号码或虚拟号码构建一定数量场景的测试报文进行压测,由于场景数量有限,不能覆盖所有实际业务场景,且由于测试号码或虚拟号码数量有限,压测压力主要集中这部分号码上,不能反映生产实际情况;
2)压测场景全面性:现有的压测工具主要针对查询交易或界面进行测试,而对于支撑系统中事务型交易(如充值、产品订购等重要的事务型交易)以及对话单计费全流程处理能力的压测支持不足;
实施方案
借鉴Jmeter等开源平台框架,构建基于业务支撑领域业务服务和计费话单数据流处理的全链路压测系统,通过构建测试数据或实际数据蓄量的方式,实现现对业务服务及话单计费等全场景进行压测;利用流处理技术实时处理压测过程数据,实现压测过程及结果的可视化。
1、业务服务压测
使用测试号码构建测试报文,通过压测系统对业务服务进行压测,压测过程中根据效果可灵活调整测试压力,直到达到预期效果;
2、计费话单处理压测
计费系统有离线话单计费和在线话单计费,在线话单计费是网元侧发起消息请求触发计费,类似业务服务请求,压测方法同业务服务压测,离线计费是以话单文件为计费请求,其压测方法如下:
计费压测时,通过压测控制器进行话单蓄量,当积压的话单量达到预期时,一键放开控制闸门,话单洪峰流向下游计费各环节,下游计费各环节的处理性能及队列中话单量实时输出到业务航海图上。
主机资源情况:
容量预测计算公式如下:积蓄话单A条,其处理时长为B秒,处理性能C=A/B=**条/秒。实际需要的处理能力D=每天话单量/24*3600*集中系数,系统扩容容量E=(D/C-1)*现有资源数量*调整因子。
总结与展望
全链路压测平台已在相关应用实际场景中经过实践检验,其特点主要有以下几个方面:
1)架构先进:引入流处理技术,计费压测过程全流式处理;
2)压测效率高:无需提前准备压测资源及压测数据,缩短压测准备时间,并且可以一键施压,提升压测的操作效率;
3)核心全场景覆盖:实现了业务查询、计费话单全流程等核心业务场景压测,提升了系统的稳定性;
虽然压测取得了不错的效果,但是在与人工智能及大数据结合方面有较大的发展空间,还要继续创新和使用更多智能化方法,使用机器学习对系统性能的预测结果,一旦发现性能有持续下降趋势,则自动发起压测,验证预测的准确性。
更多精彩热文:
以上是关于基于计费流处理的全链路压测-江苏移动SRE运维实践的主要内容,如果未能解决你的问题,请参考以下文章