生产环境全链路性能测试体系建设之路主要包括生产测试流程规范建设、生产测试工具平台建设、生产测试实施团队建设、落地实施细则。
生产环境测试实施落地实施细则
第一步,核心链路调研。本步主要目的是识别测试的核心链路,构造真实场景模型。根据实际业务情况,通过Charles工具获得核心交易主链路接口,根据接口详情初步理涉及的业务应用服务。通过测试环境的APM工具进一步获得详细应用服务,然后使用中间件识别工具,获取各Java服务的数据连接池组件及其版本号、缓存中间件及其版本号、消息中间件及其版本号、日志组件及其版本号、Web容器及其版本号等数据,用作测试改造点评估。场景模型评估时,采用前期文章提到的业务建模方法,使用参考历史数据方法通过生产环境网关监控,分别获得近一周、近一个月、近三个月的接口调用数据,综合考虑各个接口实际调用业务比例,用作实际生产测试的业务模型。
在本案例中,通过多次沟通确定,在生产容量方面,待测试的渠道为App和微信渠道,测试场景为首页、菜单、加入购物车、下单、到店自取、快递下单主流程。在测试环境方面,待确定的系统为内部核心OMS、库存、菜单、促销引擎等,通过构建核心系统性能指标基线,建立核心系统的性能规范。
通过线上线下环境质量建设两步走策略,结合企业现状,逐步完成体系规范、团队配合打磨、实施流程优化升级、日常文档规范沉淀、数字化基线构造等事项,完成企业特色性能测试体系的落地。
第二步,基于技术架构和中间件,对中间件进行增强改造,并做改造点方案评估。具体技术改造细节涉及白名单技术改造、影子日志组件改造、影子库组件改造、消息中间件客户改造、影子缓存改造等多项关键中间件改造。
白名单技术改造方案取决于服务间调用方式。调研得知主链路应用使用Spring Cloud枢架做分布式通信框架,服务间调默认使用Felgn中间件,其HTTP组件使用的是JDK的HItpURLConnection,因此需要对JDK的HTTP调用进行增强,做测试标志识别,进行流量请求的拦击,做白名单控制,可降低未知三方调用造成生产事故的风险。
影子日志组件改造方案取决于日志中间件,获得日志组件为Logback,其每一个输出到文件的Append方法都有一个与之相对应的影子ShiftAppenderShftAppender可用于在影子路径变更时同步改变其路径。日志输出时会记录一个标识表明自己是测试产生的日志还是由正常流量产生的日志,在所有的Appender上添加标识以使影于Appender只输出影子日志,原有的Appender只输出正常流量的日志。
影子库组件改造可以通过增强数据库连接池或者直接增强数据库连接来实现,但数据库连接池可以对影子连接进行管理,例如对数据库连接进行探活等,因此选择对业务代码连接池中间件进行增强。
消息中间件客户端改造分别对生产者和消费者做增强,生产者增强通过publish方法,修改测试流的exchange和routingKey,同时往basicProperties的消息头中添加测试标。消费者增强考虑对Spring框架中AbstractMessageLlstenerContainer的execuleListener设置线程上下文。
第三步,基于平台探针技术,对涉及服务进行非侵入式接入,并构建影子库和影子中间件。本步涉及探针的接入改造和影子库规范的建立和执行。在探针接入和改造方面,考虑最大程度降低平台探针对生产环境业务的影响,只在测试过程中使用探针,测试结束卸载探针,因此需要对应用的部署方式进行改造,增加探针携带的标记位,若容器中PF_AGENT环境变量为tue则携带平台探针,否则卸载平台探针。
在影子库规范建立和执行方面,考虑3个方向:影子存量数据选择、影子库表结构更新、影子库存量数据脱敏。铺底数据考虑影子库的存量数据,我们通过机理关键表导入存量数据,导入生产环数据,并且根据现有脱敏方案,对用户的名字、地址、订单编号等关键信息进行脱敏。影子库表结构更新形成规范,与供应商同步,每当有表结构更新时邮件同步DDL和DML语句至影子库维护团队,并要求相应的应签回执
第四步,在测试环境对改造项目进行充分验证,验证项目涉及脚本的业务功能完整性、验证接入探针的中间件改造是否兼容。此步骤涉及细节项包括核心接口的链路机理,识别每个接口的核心调用链路和链路上的远程调用、数据库调用、缓存调用、队列调用等信息,在全链路压测平台完成所有远程调用白名单、影子库、影子级存、影子队列等配置,并通过数据库在源库和影子库的落库情况确定影子流量业务功能的完整性和中间件改造的兼容性。
在实施过程中,通过测试环境稳定性8小时测试,发现了增强中间件版本和实际使用版本不一致的特殊情况,因此在测试环境中对相应的核心业务进行长时间测试是很有必要的。
第五步,正式对生产环境进行发布,并通过低并发流量预热验证,确保试流量为安全流量,确保生产环境的风险监控相关平台正常运作。
测试环境验证完成后,为确保生产环境数据影响降到最小,推荐采用低并发流量预热的方式,做一段时间的稳定性测试,过程中检查数据库的落库情况,避免影子对生产库造成数据污染。
测试前期也需要考虑风险预防方案,主要考虑以下几点:对应用服务的机器资源监控,基于现有业务监控做熔断触发,通过现有中间件监控做熔断触发。中间件监控细化包括数据库监控、缓存监控、消息中间件,对通过监控手段发现的风险做紧急应急处理。
为降低生产测试的负面影响,列出生产测试时可能出现的风险及风险处理手段,在生产测试调试或生产测试正式开始时,按风险发现手段进行监控,按风险程度区分风险严重性,按应急处理方案快速处理风险,按责任人及联系方式落实监控与处理的责任。例如,测试过程中对于物理机指标的监控思路是谨防达到使用上限,若达到阀值上限则及时做熔断处理,但是对于数据,得同时关注影子库和源库的监控指标以及关键表的数据准确性。
第六步,测试过程中规范和落实每个步骤中的正确性,做好输入和产出记录,定期进行复盘。将每日测试分阶段明确待办事项,细化每日的校验工作、每日的实施执行工作、每日的测试收尾工作,具体内容可参考下表信息。
在实施测试之前,要向相关部门发起审批,审批流程细节如下图所示。供应商发出邮件申请平台便用,得到公司项目经理审批意见,测试部门根据平台资源开通账号,测试结束后告知测试部门回收账号。
邮件申请模板如下:
邮件回复模板如下:
其中,平台使用注意事项举例如下:
平台测试时间为每天21:00后,白天工作时间提供平台脚本调试;
非必要情况禁止测试公网域名,若有需要还请邮件说明情况,报备基础设施团队;
由于超过20000个并发用户的分布式测试会占用全部负发生资源,如有相关需求,还请提前和测试部门及供应商实施人员协商测试时间;
平台会定期清除测试数据,需要测试资产或者测试报告还请提前下载并进行本地保存;
项目组测试需要提供测试时间、测试源IP、测试业务域名,邮件抄送基础设施团队和安全团队;
测试报告需要同步测试部门;
使用平台者必须严格遵守以上规定。
在每个项目开始阶段的平台培训和流程规范的沟通中,同步具体的测试业务和实施测试的准备工作,包括测试接口范围、业务模型、模型比例、测试目标、各业务系统对接人联系方式(微信和邮箱)、项目完成时间等。
在测试实施阶段,若被测服务是Java服务,则可以使用平台探针,利用平台做全链路监控和测试;若非Java服务,则利用内部的监控平台,做数据汇总。
在结果产出阶段,对测试结果进行汇报和解读。
测试流程各阶段及其输入输出产物如下表所示。
在生产环境中实施测试(通常称为“生产环境测试”或“Live Testing”)是一项需要特别谨慎的任务,因为它直接涉及到实际运行的系统,可能会对业务操作和服务可用性产生影响。以下是实施生产环境测试时的一些注意事项:
确保你已经从所有相关方获得了进行测试的正式批准。
了解并遵守所在地区的法律法规以及公司的政策。
尽量选择用户活动较少的时间段进行测试,比如非工作时间或者业务低峰期。
避免在重要事件或促销活动期间进行测试。
在执行之前进行全面的风险评估。
制定详细的回滚和应急计划,以备测试过程中出现问题可以迅速恢复到正常状态。
如果可能的话,尽量使用合成数据或经过脱敏处理的真实数据来进行测试,以保护用户的隐私和个人信息。
在测试期间密切监控系统的性能和稳定性。
记录所有的测试活动,包括开始时间和结束时间、测试结果等,以便事后分析和报告。
提前通知所有受影响的利益相关者,包括内部团队和外部客户。
准备好应对可能出现的问题和疑问。
开始时可以选择一个小规模的样本集或特定功能点进行测试。
根据初步结果决定是否扩大测试范围。
测试结束后,组织相关人员召开会议讨论测试成果。
分析测试中遇到的问题,并提出改进建议用于未来的测试规划。
生产环境的任何变动都应严格遵循公司的变更管理流程。
确保所有更改都是经过审核、批准并且有文档记录的。
通过遵循上述指南,可以帮助确保生产环境测试的安全性和有效性,同时减少对现有服务的影响。
阅读后若有收获,不吝关注,分享,留言评论等操作!!!
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。