8年+质量保障经验,博客园技术文章超过500w阅读量。 擅长质量体系搭建、全链路压测及稳定性保障。 公众号:老张的求知思考世界
从实践经验的角度出发,生产全链路压测在技术实现上没有太多新花样,但要在不同的业务和企业落地,就各有各的实践路径。对于没有太多经验的同学来说,全链路压测的落地,大多还是基于个人的经验和熟悉的领域,即都是在局部作战,缺乏全局的视角和可视化地图。从全局来讲,缺少适用于自己的全链路压测最佳实践。
业务场景复杂化、海量数据冲击下,发现并解决业务系统的可用性、扩展性以及容错性问题。
在生产环境开展全链路压测,相对于测试环境来说风险和成本都是比较大的。因此需要一套严格的流程管控和响应机制,以及高效的团队协同体系。
从业务角度来讲,无论技术做任何的改动和优化,最终的目的都是为了业务目标的达成。而系统的稳定性,无论从用户体验还是业务目标达成的角度来看,都是不可忽视的一环。
功能验证环境即用来验证技术组件本身的功能正确性和接入性能损耗的环境,有独立的随时可用的环境最好。如果考虑到成本,也可以用线下性能环境来进行验证。
首先专注于业务上最需要优先修正的程序,而不是从全局调优来改善性能。要重视全局的性能表现,但解决问题要从细节和业务最需要的环节入手。
如果网络不稳定,也会导致RT的曲线抖动较为剧烈,产生毛刺甚至丢包,这个时候P90/P99的数值也可能变大。因此稳定和足够的网络带宽,对系统的性能来说是很重要的。
容量评估我在之前的文章《性能测试从零开始实施指南——容量评估篇》中已做过详细介绍,这里不多做赘述。关于容量评估,参考下面两张思维导图,更容易理解。
单机单接口的压测,可以通过梯度增加请求的方式,观察随着请求的增加,其性能表现&资源损耗的变化。在目前的微服务架构下,整体链路的性能瓶颈,取决于短板(木桶原理)。因此,单机单链路基准测试的目的,是在全链路压测开始前进行性能摸底,定位排查链路瓶颈。
环境是我们开展一切测试工作的前提,也是最底层的基础设施,因此环境的稳定性是至关重要的。但随着业务、技术以及人的不断变化,环境的稳定性越发的成为部分企业技术团队特别是测试团队面临的巨大问题。
这个阶段包括原型图、PRD文档、交互设计、技术方案、测试用例等几项重要产出物,当然他们有一定的前后依赖关系。
很多企业都会有自己核心的业务范围,这些核心业务也往往是主要的企业利润来源。以电商企业为例,为用户提供商品的购买服务,为商家提供商品的管理和上架及定价展示,利润大多为撮合用户和商家交易所带来的服务费以及广告等相关费用。
在国内测试开发很重要的一点是具备大部分测试所不具有或不擅长的coding能力以及技术广度,他可以通过借助已有的成熟工具框架或者二次开发,快速解决测试过程遇到的各种block效率的问题,以及为技术团队内部提供一些更高效的研发测试工具,提高交付过程的效率,并保障测试过程的质量。
全链路压测,见名知意,其本质是一个技术验证手段和过程。即通过一系列的准备工作和测试手段,来验证系统在生产环境的“三高”是否能满足某些特定情况下的业务需要。
任务拆解即将下述备战阶段的各个一级目标,拆解为多个更详细的二级甚至三级任务,并且对应到人和时间。
分段判定原则:对于原因较复杂或链路较长的故障,建议分阶段评估,不同阶段有不同的措施。这一原则的出发点是要摒弃“故障根因只有一个”的观点。
最早由Netflix的技术团队提出,现已经演变成计算机科学的一门新兴学科,即“混沌工程”。
一般来说,云服务的可用区,可以理解为同一个机房的不同虚拟机集群。为了避免某个可用区由于网络硬盘等原因损坏导致服务不可用,跨可用区的服务部署是一种常见的容灾手段。
大促的典型特点是流量大,对系统的冲击比较高。那么精准的测量线上系统的容量,对处理能力薄弱的节点进行扩容升配,优化性能就是很有必要的。
底层框架改造是目前业内较为常用的一种技术手段,它通过提供一个基础的服务或者框架,让业务应用和中间件接入即可。在压测时候,在请求头带入特殊的压测标记,即可区分正常的业务流量和压测流量来进行透传,涉及到的中间件和数据库,也会通过路由的方式透传下去。这样做的优点在于:业务几乎无需改造,侵入性低,即插即用的方式也更为灵活。
一般来说,像生产全链路压测这种复杂的需要多个技术团队参与的复杂技术项目,在企业内部都会有一个项目申报和评估立项的过程。
后来他们内部复盘,一番讨论后,为了避免后续的大促再次出现类似的问题,决定在生产搞压测,这就是现在被很多测试同学所熟知的生产全链路压测的背景由来。
优化思路:通过配置信息版本号,比对决策是否需要更新(更新需要proxy)
随着互联网行业不断发展,系统架构越发复杂,业务场景越发多样化,对性能测试的要求也越来越高。传统压测方式已经无法满足业务和技术的发展需要,全链路压测,就是在这样的背景下应运而生的。作为性能测试领域新阶段的最佳实践,全链路压测在更多公司被探索和应用的过程中,也遇到了种种挑战。
所谓的愿景,就是长期规划,我们要到哪里去的问题。一个组织或者团队,是一定要有愿景的。在软件质量保障领域,所谓的愿景概括来说就四个字:保质提效。
压测任务正式开始前,设定并检查压测的SLA阈值,确保压测流量不会导致生产服务负载过高出现异常;
网关层:网关是请求入口和业务接入层,一般登录验签调用、加解密鉴权、限流等操作,都是在网关进行;
全链路压测,特别是生产全链路压测,成本和风险相对比较大,而且涉及到的底层改造等问题,需要合适的契机才能推动,否则会比较困难;
影子库表方式的话,是通过特殊的标记将压测数据路由到对应的带特殊标识的中间件和DB,影子库一般和生产的业务DB在同一个实例,这种情况下数据预埋是将生产数据同步到影子库,然后进行脱敏处理;
很多同学说起全链路压测,都喜欢深究它的技术细节,这没错。但全链路压测想要成功的在生产环境实施,更多的是考验组织协调能力的一个项目。至于技术层面,能说的有很多,这次我们先聊聊比较核心的一些技术点。
只有每个业务环节都稳如泰山,才可以保障整个稳定性。单服务的稳定可以从以下几个方面来进行:
在接口测试中,我们对返回结果的正确性判断一般是基于响应报文的返回内容进行断言。但有些时候,按照正常的业务逻辑来说,一个请求返回的内容是多种不同的。
全链路压测是一个很复杂的工程,其中涉及到多个服务。对整个业务系统进行梳理,确认流量传递的上下游和范围,是首先要做的事情。
接受“系统越复杂,越脆弱”的事实,让系统在每一次失败中获益,然后不断进化。在实践中,用一系列的实验来真实的验证系统在各类故障场景下的表现,通过频繁大量的实验,使得系统本身的“反脆弱性”持续增强,让组织建立对系统抵御生产环境中失控条件的能力以及信心。
电商业务本身比较复杂,且当前阶段我们微服务架构下,各个服务间依赖高,调用关系复杂,且没有较为清晰的链路梳理,理论上来说,只有一部分系统才是核心链路。所以,面临的第一个挑战,就是从错综复杂的系统中梳理出核心业务链路。
单机水位是多少、满足业务需求要上多少机器、什么时候该加机器、什么时候应该减机器。双11等大促场景需要准备多少机器,既能保障系统扩展性和稳定性,又能节约成本。
狭义上的APM单指应用程序的监控,如应用的各接口性能和错误监控,分布式调用链路跟踪,以及其他各类用于诊断(内存,线程等)的监控信息等。
无论是从成本角度还是维护的难易方面,压测机的数量,适量就好。举个例子,8C16G的一台服务器,部署jmeter后,根据我个人的测试比对数据,配置≤1500个线程数,最好。太多了性能损耗较大,延时高;太少了又浪费。
移动端:这里的移动端包括手机、平板等各类移动设备(目前移动端的流量也是占比最大的一个流量来源渠道);
需求不明确导致无法对测试点&测试场景进行详尽完善的分析,最终的测试结果与实际需要的结果差距很大,无法对瓶颈定位和线上容量规划提供精确的参考;
Wrk是一个支持HTTP协议的基准测试工具,结合了多线程设计和可扩展事件通知,底层封装epoll(linux)和kqueue(bsd),能用较少线程生成大量并发请求(使用了操作系统特定的高性能io机制)。
首先要阐述本次性能测试的背景,即被测系统类型,面向哪些用户,具备什么特点,为什么要进行性能测试,预期的一些指标等等。
细节:如何分析性能需求?测试的目的、范围如何界定?预期指标怎么得到?需要哪些数据和手段来评估?压测环境配置模型如何抉择?测试数据如何准备?
面对日益复杂的业务场景和不同的系统架构,前期的需求分析和准备工作,需要耗费很多的时间。而不同的测试策略,也对我们的测试结果是否符合预期目标至关重要。这篇文章,聊聊我个人对常见的性能测试策略的理解,以及它们的适用场景。。。
启动grafana,配置对应的Dashboard、Data Sources,然后选择配置好的仪表盘,查看可视化的监控数据(如何配置grafana,请看这里:可视化工具Grafana:简介及安装)。
事务成功率在某些时候也可以视为请求成功率,在断言判断时以code/status等内容来作为请求是否成功的衡量依据;
产品说这里改改,就加一个按钮,不影响功能,开发同学改了,测试同学不知道就上线发布了,结果出问题了,事后追溯下来,发现就是新增的按钮导致;
性能测试是一项严谨的需要各团队协同配合的工作,其中包括产品、开发、运维、网络、DBA、测试等角色。从零开始实施性能测试,而性能测试流程,是最重要的一步。
安装好之后,在jmeter中添加线程组,然后按照如下格式填写对应的信息,添加仅一次控制器(因为后台服务启动后,只需要启动一次监控服务即可)
以我现在所在的银行业务系统来说,目前的现状大概有这些:业务逻辑太复杂、系统庞大、子系统较多、系统间解耦程度较低、调用链路较长、核心系统环环相扣。