2019年10月26日,由Testin云测主办的第二届NCTS中国云测试行业峰会在京召开。峰会以“AI+未来”为主题,汇聚国内外检测领域知名专家学者、企业决策领导者、高层技术管理者、媒体从业者等,共同探讨高端云测试技术,帮助测试从业者了解最新的行业前沿趋势,以及最新的行业实践。会上,京东零售技术与数据中心测试架构师侯磊做了主题演讲《从链路化压测到流量回放的平台实践》。侯磊介绍了京东今年在链接压测方面的实践和工具的演进,并指出,“星级最高的开源社区,往往不是技术最好、最好、最优秀的社区”。最具创新性的技术,但拥有最丰富的论坛。”,社区最活跃,文档最全。当整个团队的能力逐渐提升时,测试工具一定要操作出来才能脱颖而出。”以下是侯磊演讲实录:谢谢大家,也谢谢Testin云测给了我这样一个机会和大家分享。与前两位讲师相比,我的题目更加详细和专业。今天演讲的主题是《从链路化压测到流量回放的平台实践》。基于链接的压力测试,去年和前年都讲过很多次了。去年,TID也分享了这样一个平台。今天在Testin云测试中,重点不在共享工具上,而是在压力测试上,而今年在工具进化上做了哪些尝试,也跟业务强相关。在开始之前,让我问一下真正做业务测试的人有多少?工具开发呢?如果没有人举手,他们就是领导者。请注意身边的领导,说不定他们需要挖人。我自己是开发者,对工具平台比较适应。今天,我对PPT做了一些调整。从性能测试开始,主要分为三个方面。首先介绍链路测试,然后介绍我们的平台如何响应链路测试。最后介绍一下今年新的试用点,流量播放。说到流量,其实记录流量的方式有很多种。我们可以从很多地方记录流量,大家也尝试过很多,比如java中的AOP拦截,机器运维方式(tcpcopy),或者从LB层。今天说的流量回放,还是从整个链路的角度,记录公司入口交换机的流量。这种录音与基于应用服务器的录音有些不同。首先看链路压力测试。京东性能测试有几个发展阶段。最初,它是离线测试。在此阶段,性能测试由各个职能团队执行。大家使用的工具也比较分散,主要用于线下问题定位,对新部署的系统进行性能评估,后来发现线下测试无法满足线上需求,线下场景无法复现线上问题,mock过程繁琐复杂。然后切换到在线测试,再从在线单点测试过渡到集群测试。上线测试的时候,大家都会面临同样的问题——写流量,写流量需要进行系统改造,这也是非常复杂和困难的一步。上次分享的时候,大家都在问这样的问题,系统改造应该从哪里入手?我们转型的难点在哪里?稍后我会再次提到这一点。在那之后,有一些场景。除了压单接口和压单服务,我们在逐渐走向组合业务和组合接口,包括刚才卢老师提到的BDD,这样一个在压测场景下的应用。现在开始做基于链接的压力测试。基于链路的压力测试分为系统链路和业务链路。怎么理解这两个?比如按一个服务,就会调整我的缓存、数据库等中间件,从而形成一个系统化的流量传输,这是一个自然形成的系统链接。商业链接呢?如果按下一个接口,则该接口可能会调用其他接口。接口A可以调用接口B,也可以调用接口C,B又可以调用接口C,这样就形成了一条服务链路。在此基础上,如果我同时对ABC的三个服务进行压测,或者从多个入口进行,就会形成一个全链路的mesh流量结构。你可以看到这样一张图片。如果你按下一个APP,它会调整它的服务层,这样如果你从一个入口进行压力测试,你会访问多个中间层,最后到持久化。如果同时从多个入口进行压测,比如压APP1和web3,service2可能会成为瓶颈。任何接口在单压下的TPS都会很高。在组合的情况下,service2可能会成为多个场景下的短板。所以,链路压测就是在整个系统处于满负荷访问高峰的情况下,找出哪些系统是短板。,哪些应用程序资源过剩,调整资源。京东开海外站很典型。国外和国内是有区别的。国内APP是主要入口。泰国和印尼还没有发展到这个阶段,PC是主要入口。这样的流量特性会导致我们的系统出现故障。资源分布不同。在海外站上线前,我们需要对海外站进行全链路压力测试,找出系统中哪些资源需要调整。因为在项目中,每一个业务线,每一个开发都需要尽可能多的资源来保证自己的系统不挂掉。作为项目经理,需要统筹规划,进行资源调整,达到资源平衡的状态。价值最大化,节约成本。因此,基于链接的压力测试主要有以下含义。首先是评估整体流量。今年双十一和618预计我们的系统要处理多少流量?我系统的短板是什么?二是如何根据自己的短板来分配资源,让我们的木桶尽可能的盛水。这就是基于链接的压力测试的目的。基于这个目的,我们的工具平台需要做哪些改进?首先看我们链路压测的核心需求,模拟大量用户,链路压测不同于以往的单机压测和集群压测,我们的目标人群是我们主站的所有应用,所以我们也需要等量的压力机或者用户发起流量访问,大量用户的模拟是必不可少的。第二点,当应用基于链路的压力时,压力测试团队由多个团队组成。如果某条业务线的压测系统无法应对,就需要降级或者降低流量。另一种可能,如果某条业务线压测不达标,需要增加流量,则需要停止所有任务,重新开始。这种效率是不可接受的,所以需要动态调整某个接口和某个流量的访问量。第三点是模拟尖峰和复合场景。伴随着京东组织架构的调整,其工具也发生了变化。一开始工具很多,各个业务功能团队做性能测试,所以选型独立作战,用了很多工具。第二阶段,随着京东业务量的增加,将大力推进6.18和双十一的准备工作,并成立专门的性能测试团队。这在业内比较少见。一个专门的性能测试团队,会有专门的经验积累和工具的沉淀,你选择三个工具,各有特点,jmeter用起来更方便。Ngrinder是一款来自韩国的开源工具。该工具首次管理新闻资源库和脚本资源库。这样的性能工具在项目管理和知识积累方面具有优势。加特林机在产生压力方面相对有效。但是,这三个工具都不能满足基于链路的压力测试的要求。我们搭建了自己的压测平台,也参考了很多压测工具的实现方法。这一点不得不再说一遍。在上次的分享之后,很多朋友会问,京东这个平台什么时候对外开放呢?一开始很开心加了很多微信。聊完发现大家都不是很想做我们的用户,而是担心京东什么时候成为竞争对手?我们目前没有这个计划,我们还是一个内部工具,也希望能借此机会把工具的实践分享给大家,因为我本身就是一个工具开发者。您可以放心,Testin云测试这边没有竞争。作为商业工具,它的门槛还是很高的。即使内测工具再完善,用户使用起来也未必那么好用,但功能性更强。测试工具要想在公司推广,必须支持公司的每一个组件、每一个功能点。为了支持数据库和消息中间件,测试人员也会提出一些要求,甚至是一些智能的东西,比如自动查找备份系统的最大处理TPS。这是通过逐渐增加并发来实现的。有一些自动停止的条件,比如当错误率较高时停止发送压力,当响应时间较高时停止发送压力。还有一个资源分配,比如印刷机、项目管理、测试计划和测试警告的资源。此外,作为压测平台,还需要有完整的性能测试生态,包括性能调优的监控、日志、诊断工具。所有这些工具都必须在平台中进行汇总。因为我是做工具的,如果你也是做工具的,可能也会遇到这样的问题。每个业务部门都会做自己的工具,接口测试工具,测试脚本管理,测试用例管理。每个部门都有自己的工具。自己的工具,做完这个工具之后,会面临一个推广的问题,和同一个公司或者同行业竞争的问题。性能测试工具可能比函数更好,因为门槛稍微高一点。比如做性能测试大家都懂,线程和进程都懂,但是性能测试什么时候用多线程并发什么时候用多进程并发这个问题不好回答,所以是一个性能测试工具。有时,同样的需求也会有一些高难度的需求。每个部门都会制作工具。你们的工具有什么突出的地方?首先,有技术保障和技术壁垒。这就是forcebot在京东内部的不可替代性。首先是大量用户的操作,下面介绍实现过程。另一种是动态增加或减少并发用户数。如图所示,这是模拟双十一的效果。双十一零点,响应请求突然有增效。这就是秒杀活动。这个秒杀会持续一段时间,然后逐渐减少。一段时间后,可能会有新的二次秒杀活动,这个流量又会增加,然后逐渐减少。这是场景的模拟。为什么会出现这样的场景?因为我们现在的系统很智能,所以我们需要动态的减容和增容。我们在秒杀后的第二个活动,在第二个洪峰到来时系统是否能够处理新的流量,在性能测试中也是有要求的。对于模拟场景,本平台需要支持此类功能。如图,这是一个平台实现的基础设施,就不细说了。其中之一是任务调度服务。通过横向扩展,支持大量出版社同时发布新闻。说说我自己做工具的感受吧。如果在内部推广工具,最好有护城河。首先是技术门槛。如果让普通的测试工程师做一些工具开发,封一个页面,或者通过运维脚本驱动单机测试工具达到集成的效果,或者使用一些开源的工具包,这是大家最擅长也最容易做的..如果再往前走,做一些改进,比如多线程并发、流式计算,测试工程师的门槛可能会高一点。这是我做工具开发的一点心得/体会。第二条护城河是整个测试能力逐步提升后,重点放在运维上。星级最高的开源社区,往往不是技术最好、最好、最创新的社区,而是最丰富的论坛和最活跃的社区。最全面的文档。升级后,测试工具需要脱颖而出进行操作。回到系统,有几个困难。1.模拟海量数据,通过海量压机、多线程、多进程实现多并发。双十一要模拟百万用户,至少需要四五千台压机。每个压机的螺纹和工艺也取决于容器的规格。好的机器支持多并发,小的机器支持百并发。结束了。2、数据采集是性能测试工具都会面临的问题。jmeter为了准确计算TB99,会将每个响应时间生成一个文件传给它的master,这样会造成网络传输问题和计算问题。Ngrinder得到进一步改进。它以秒为单位收集单次按下每个请求的响应时间,汇总,取平均值后发送给控制器,控制器进行二次平均计算。当然这个数字有些Distortion,所以我们这里稍微改进一下。首先,合并数据。每个请求的响应时间都在媒体上进行了总结。这个总结不是平均,而是数据压缩。统计每次响应的次数,将key-value数据传输到我们的监控平台,这样传输的数据量就变小了。同时在计算的时候,计算出map的key值即可。这是中间的一个小技巧。此外,作为压力测试生态系统,监控必不可少。除了监控媒体,它还监控被测服务。监控内容包括资源监控和发送请求监控。对于性能监控一般来说肯定是二级的。往往程序中的GC时间很短。在频繁GC的情况下,秒级监控的压测图会形成锯齿状。另外在GC的时候,TPS可能会下降到0,这种锯齿状的处理能力可能会导致线上出现问题,所以压测监控必须在秒级进行监控。另外需要注意的是,压力发送端与被测端进行对比。有时候会出现这样的场景:研发人员很有信心:我的监控数据很好,响应时间OK,可用率100%。比较慢,超时次数很多,但是感受不到压力发送端的监控。此类问题需要重新定位。这是通过比较发现的。出现这种问题的原因有很多,比如网络传输、序列化和反序列化、系统资源抖动等,这就需要针对具体问题具体定位,而这往往被初级性能测试人员所忽视。说完工具,我们再来看看京东是如何做链接压测的。它是如何利用forcebot平台做全链路压测的?首先明确压力测试的目的:评估整体能力,重新评估资源。分配;第二点看压测方式:我们军演是在CDN部署压机,通过外网模拟真实用户。这样做的好处是压测环节比较长,包括公司的负载均衡,网关,安全都是有压力的,但是这个实现的难点是数据流量的识别,就是测试数据,一定不能影响线上环境,也不会给线上带来脏数据。数据的转换是每个公司的责任。面临的问题。京东已经做了一年多了,而且还在继续改造。上次讲完,很多朋友都在问京东是怎么做到的。我再说明一下,最重要的一点是要在公司领导层达成一致。为了质量改进或质量验证,可能会牺牲业务开发时间。公司高层必须先达成共识再下推。推的时候,建议各业务线的架构师配合。如果让测试人员去做技术转型可能会有点难度,但是测试人员更适合做推广者和倡导者,因为提升的是我们的素质,和我们的工作息息相关,可以提高测试的效率和效果。最后,我们必须每周做例会、回顾、周报。通过项目制,我们会把体制改造作为一件很重要的事情来推进。如图所示,我们通过这种方式来标记流量标识。首先,在测试前准备一些测试数据和测试账号。送压时需作标记。因为模拟的是用户行为,所以一般都是HTTP请求。第一层服务识别这个标记,然后进行RPC透传。这也取决于业务系统如何改造。如果有能力最好在RPC框架的基础上做流量识别和流量隔离。如果不方便从业务层面对标识进行改造,也可以。改造的方法其实有很多。可以配置影子库,影子中间件,或者写一个标记数据,然后清理。这些都是可行的。方法。在京东,我们对每一行的处理方式也是不同的。最后看一下基于链接的压力测试。每年双十一和618都会进行链路压测。本次压力测试从准备到最终实施可能需要一周以上的时间。准备时需要确认压测的范围,确定流量会停在那个环节,或者哪些入口和系统需要参与压测。对于中台来说,是否需要补充压测场景的设计和审核以及数据准备,需要很长时间。第二步是在压力测试之前准备我们的脚本和我们的数据。压测池的资源分配和压测数据都是提前记录和准备好,分发给压测机的,因为这个数据往往非常大。大文件无论是在线录制还是构建生成,都要提前同步到压机上,实时拉取可能会影响效果。我们还需要准备好我们要压什么,应急预案是什么,遇到问题第一时间联系谁等等,压力测试的前一天晚上,我们要准备小流量的验证,可以测试压力先行,最后上线流量验证。在实施阶段,我们一般使用一个机房进行在线负载测试,另一个机房进行压力测试。压测流量需要及时调整,有降级演练。最后,一定要总结压测成绩单。这个步骤每年都非常费时费力。从数据准备到脚本校验和回放,其实回放可能不会花很长时间,但是前期的数据准备和构建会比较耗时。这里指的是整个链路的一个痛点,就是我们为什么要做流量播放。这是我们今年想到的平台2.0的演变。作为平台开发,链路压测完成后下一步是什么?行业会想到自动化、智能化、常态化。这样的标题很大,但是怎么做呢?我们首先想到的是从数据准备到压力分发,即流量记录和回放的自动化。不再需要编写脚本和准备数据,从真实环境中记录流量。当然,这个前提是业务转型必须相当完整。我们写的流量能被识别吗?这是非常有必要的。其实在京东也有流量播放的后台。今年618也发生过这样的事件。在准备军演的时候,我的系统处理的TPS可以达到很高,但是实际上,在流量高峰的时候,我发现还没有达到这个TPS的时候,系统资源CPU就已经耗尽了。后来分析原因是压测场景设计不到位。比如也是查询用户的接口,用户信息量大,用户信息量小。这对系统有不同的处理。我们还没有完全准备好压力测试场景。它覆盖了真实的在线状态,所以这也是我们要做这样一个事情的原因:真实的在线流量回放。另外一个方面,刚才也提到了,流量回放不仅仅是单台机器单个应用的回放,而是中台和前端系统所有进来的流量的回放。这自然形成了播放过程中的匹配关系。以前专门分析我们的比率关系。比如同一个系统中三个接口的比例是1:3,这是通过分析日志或者过去的流量得到的。流量回放的时候,这个比例是自然形成的,不需要参考,也不需要设计。这是一个巨大的便利优势。;三是切实提高效率。我们要做常态化的压测,我们要把这种军演、链路压测常态化。除了系统改造,实施起来也很方便。研发合作,应用端无需抓取日志,无需修改java代码拦截流量数据,播放时无需编写脚本。这是规范化或自动化的先决条件。其实从入口记录流量还有一个好处:不再依赖被测系统,不再依赖在线应用。以前如果把线上应用的日志记录下来,大促的时候可能不敢打开,因为会影响线上性能。但是如果我们从ingress交换机分出来的流量对业务是完全无侵入的,我们可以随时随地的Recording是它的好处之一。最终实现了这样一个效果,在线流量记录,然后放在数据中心回放压测流量。如图所示,这是我们实现的一个架构。其实我们还处于实践阶段。计划不是很完整。我不会详细介绍更多细节。主要模块就是这样的模块。抓取设备上的流量,放到性能非常好的消息队列中,然后加安全模块。在线数据安全问题非常重要。在互联网行业,安全再怎么强调也不为过,因为用户安全可能会出现各种各样的问题。最后放在京东的一个分布式系统中。您可以使用自己公司的文件系统。加密后的数据也可以放在内网播放,功能播放更OK。怎么用取决于域名的过滤,根据自己的系统适配。回放时,可以使用固定脚本,将录制的东西作为参数化文件发送。最后打个比方,路况录放就相当于水库的概念。在线数据在几个小时内记录和存储,然后在短时间内发布,以达到模拟洪峰到来的效果。今年我们已经开始使用行车记录,为今年的双十一做准备,效果还是不错的。很多业务撮合关系直接使用这样的真实数据,业务测试相对容易,不需要写很多脚本,不再需要向研发索取此类参数数据。最后想说的是,“酒醉看剑开灯,梦到连队吹喇叭”。线上的各种状态牵动着测试人员的心。希望大家用自己的技术改变公司的质量文化,质量氛围从自己做起。谢谢你们!
