【NCTS峰会回顾】京东零售侯磊：从链路化压测到流量回放的平台实践

发布时间：2025-11-04 14:31:15 来源：云智核 作者：域名

2019年10月26日，峰会放由Testin云测主办的回顾侯磊第二届NCTS中国云测试行业峰会在京召开，此次峰会以“AI+未来”为主题，京东汇聚来自国内外测试领域的零售路化量知名专家学者、领先企业决策者、从链高层技术管理者、压测媒体从业者等，到流共同探讨高端云测试技术，平台帮助测试从业者了解最前沿行业趋势，实践及最新的峰会放行业实践。

会上，回顾侯磊京东零售技术与数据中台测试架构师侯磊做《从链路化压测到流量回放的京东平台实践》主题演讲。侯磊介绍了京东在链路化压测方面的零售路化量实践以及今年在工具上的演进，并指出，从链“开源社区星级最高的压测往往不是技术最牛、最好、最新颖的，而是论坛最丰富、社区最活跃，文档最全面的。当整个团队的能力逐步提升后，测试工具要想脱颖而出拼的云服务器就是运营了。”

以下为侯磊演讲实录：

谢谢大家，谢谢Testin云测给我这样一个机会和大家分享。和前两位讲师相比我的主题更细节一些、更专业一点。今天演讲的主题是《从链路化压测到流量回放的平台实践》。链路化压测去年、前年讲过很多次了，去年TID上也做过这样一个平台的分享，今天在Testin云测主场不以分享工具为主了，还是说压测方面的东西，以及今年在工具演进上做了哪些尝试，也是强业务相关的。开始之前，我先问一下大家真正做业务测试的有多少？做工具开发类的呢？如果都没有举手的就是领导了，大家注意一下周围的领导，可能他们需要挖人了。

我本人做开发出身，服务器托管对工具平台会更游刃有余一点，今天还是把PPT做了一些调整。从性能测试开始主要分三个方面，先介绍一下链路化测试，再介绍一下我们平台是如何应对链路化测试的，最后是今年一个新的尝试点，流量回放。

说到流量，录制的方式其实有很多，我们从很多地方都可以录制流量，大家也都做很多尝试，比如java中的AOP拦截、机器运维手段（tcpcopy）、或者从LB层也可以。而今天我所讲的这个流量回放还是从全链路角度，从公司入口交换机上录流量，这样的录制的和基于应用服务器的录制还是有些区别的。

首先看链路压测，在京东性能测试有几个发展阶段，香港云服务器最初是线下测试，在这个阶段由各个功能团队执行性能测试，大家用的工具也比较分散，主要用于线下问题的定位、新部署系统的性能的评估，再往后，发现线下的测试不能满足线上的需求，线下的场景也不能复现线上的问题，同时mock的过程比较繁琐复杂。之后转为线上测试，再由线上的单点测试向集群测试过渡。在线上测试的时候，大家都会面临同样的问题——写流量，写流量就要做系统改造，这也是一个非常复杂，非常艰难的一步，上次分享的时候，大家都在问这样的问题，系统改造应该从何入手？我们改造的困难在哪儿？这个我在后面也会再提到。再之后，就是一些场景化，我们除了压单接口、压单服务，逐渐向组合业务、组合接口，包括刚才陆老师说到的BDD，这样一个在压测场景的应用。

现在开始做链路化压测，链路化压测又分为系统的链路和业务链路，这两个怎么理解？比如，压一个服务，这个服务会调我的缓存、调数据库、调其它中间件，这样就形成一个基于系统的流量的传输，这是天然形成的一个系统链路。业务链路呢？压一个接口，这个接口可能会调其他的接口，接口A调接口B，也可能调接口C，B有可能又调接口C，这样形成一个业务的链路。

在这个基础之上，如果我同时对ABC三个服务进行压测，或者说从多个入口进行压测，就会形成一个全链路的网状的流量结构。大家可以看这样一个图，如果压一个APP，它会调它的服务层，这样从一个入口进行压测的话会访问多中间层，最后到持久化。如果从多个入口同时压测的话，比如压APP1和web3，service2就可能会成为一个瓶颈。单压任何一个接口TPS都会很高，在组合情况下，service2可能成为多场景的短板，所以链路化压测就是要找到整个系统里面在全流量进行高峰访问时，到底哪些系统是短板，哪些应用的资源过剩了，做资源调整。比较典型的是京东开了海外站，海外和国内是有区别的，国内APP是主要的入口，泰国、印尼没有发展到这个阶段，PC就是主要的入口，这样的流量特点就会造成我们系统的资源分布是不同的，我们在海外站上线之前要对海外站做全链路压测，找到系统里面到底哪些资源需要做调整。因为在项目中，每个业务条线、每个开发都尽可能要更多的资源保证自己的系统不挂，而作为项目管理者，需要统筹规划，做好资源调整使资源达到平衡状态，最大化的发挥价值，节约成本。

所以说链路化压测主要是以下几个意义，首先是做整体流量的评估，我们的系统预期今年的双十一、618能够扛住多少量？我系统的短板是什么？其次是根据我的短板怎么再做资源的调配，让我们的木桶尽可能盛装更多的水，这是链路化压测的目的。

基于这样的目的，我们的工具平台又需要做哪些改进呢？首先看我们的链路化压测的核心需求，海量用户的模拟，链路化压测区分于以往的单机压测和集群压测，我们的目标群体是我们的主站上的所有应用，所以我们也需要有等量的压力机或者等量的用户发起流量访问，海量用户的模拟是必不可少的。第二点就是链路化发压的时候，压测团队是多个团队一起进行发压，如果有一条业务线压测的系统扛不住了，就需要降级或者需要减流量，另一种可能是有一条业务线的压测没有达标需要增加的流量，则需要把所有的任务都停止从头再来，这样的效率是不可接受的，所以要动态的调整某一个接口、某一些流量的访问量。第三点就是要模拟秒杀以及复合场景。随着京东组织架构的调整也经历过工具的变革，最初是有很多工具，各个业务功能团队执行性能测试，所以各自选型、各自为战，用的很多工具都有。第二阶段，随着京东业务量的提升，大促618、双十一的备战，组建专职的性能测试团队，这个在业界是比较少的，有专门性能测试团队，就有专门的经验积累以及工具的沉淀，大家选型三款工具，它们各有特点，jmeter上手比较方便。ngrinder是一家韩国的开源工具，这款工具第一次把压力机资源池、脚本资源池管理起来，这样的性能工具在项目管理上，知识沉淀上，是有优势的。gatling发压效率比较高。但是，这三款工具都不能满足链路化压测的要求，我们做了一个自己的压测平台，也是参考了很多压测工具的实现方式，这一点还得再说一下，在上次的分享之后，很多朋友都会问，京东的这个平台什么时候对外开放？开始很高兴加了很多微信，聊着聊着发现大家不是真的想做我们的用户，而是担心京东什么时候会成为竞争对手？这个我们目前是没有这样的计划的，我们还是一个对内的工具，我们也是希望借这样的机会跟大家交流工具的实践，因为我本身是做工具开发的。这个大家可以放心，Testin云测这边也没有任何竞争的关系。作为一个商业工具来说，它的门槛还是很高的，对内的测试工具即使功能再完善，可能对于用户的易用性还不是那么好，只是功能性多一点。

测试工具想在公司内推广，对公司每个组件、每个功能点都要支持，要支持数据库、支持消息中间件，测试人员也会提一些需求，甚至要一些智能化的东西，比如，自动寻找备测系统最大的处理TPS，这个是逐渐增加并发实现的，有一些自动停止的条件，比如，错误率是多少停止发压了，响应时间多少就停止发压。还有一种资源的调配，对压力机的资源、项目管理、对于测试计划、测试预警。还有作为一个压测平台也需要有一个整个性能测试的生态，包括监控，日志、性能调优的诊断工具，所有这些工具要在平台里做一个汇总。

因为我是做工具的，如果大家也是做工具的，可能也会遇到这样的问题，每个业务部门都会做自己的工具，接口测试工具、测试脚本管理、测试用例管理，每个部门都有自己的工具，做完这个工具又会面临一个推广的问题，跟同公司或者跟同业竞争的问题。性能测试工具相对于功能来说可能还好一点，因为这个门槛稍微会高一些。比如大家都会做性能测试，也都了解线程和进程，但是让大家真能说出来在性能测试里面什么时候用多线程并发、什么时候多进程并发，不是那么好回答的问题，所以做性能测试工具的时候，也是有一些难度的同样的需求，各个部门都会做工具，你的工具有什么突出点？首先一点还是技术的保障、技术的壁垒，这就是forcebot在京东内部的不可替代性。首先是海量用户的操作，下面我会介绍实现过程。另外一个是动态增减并发用户数，可以看到如图，这是模拟双十一的效果，在双十一0点的时候响应的请求突然有一个递增的效果，这就是秒杀活动，这个秒杀会持续一段时间，然后逐渐的减少，过一段时间可能有一个新的二次秒杀活动，这个流量又会上去，再逐渐的往下降，这是一个场景的模拟。为什么有这种场景？因为我们的系统现在做的很智能，我们要动态的缩容、增容，我们在秒杀之后的二次活动，二次洪峰来临的时候系统能不能扛住新的流量，这也是性能测试里面需要模拟的场景，做这个平台就需要支持这样的功能。

如图这是一个平台实现的基础架构，就不详细说了，其中有一点是任务调度服务，通过它的水平扩展支持海量的压力机进行并发的发压。

还是说一点我自身做工具的感想，做工具如果在内部推广最好有一个护城河。首先就是技术的门槛。如果让一般的测试工程师来做一些工具的开发，封一个页面，或者通过运维脚本驱动单机测试工具达到集成的效果，或者用一些开源工具包一层，这是大家最擅长、最容易做的。如果再提高一步做一些改良，例如多线程并发、流式计算，可能对于测试工程师来说这个门槛就稍微高了一点点，这是我作为工具开发的一点儿体会/心得。第二个护城河是当整个测试能力逐步提升后，拼的就是运营和维护了，开源社区星级最高的往往不是技术最牛、最好、最新颖的，而是论坛最丰富、社区最活跃，文档最全面的。在提升后，测试工具要想脱颖而出拼的就是运营了。

再回到系统里来，这里面有几个难点，1、海量数据的模拟，多并发就是通过海量的压力机、多线程、多进程实现。在双十一要想模拟百万级用户，至少需要四五千台压力机，每台压力机线程、进程也看容器的规格，好一点的机器支持并发多一点，差一点的机器一百并发就到头了。2、数据的收集，这是性能测试工具都会面临的问题，在jmeter为了精确计算TB99，会把每个响应时间都生成在文件里面，传给它的master，这样就造成了网络传输的问题和计算问题。ngrinder有了进一步的改造，它按秒收集单台压力机每个请求的响应时间，做一个汇总，求平均后再交给controller，由controller再进行二次平均，进行计算，当然这个数就有些失真了，所以我们在这里做了一点改进。首先还是数据合并，在压力机上把每个请求的响应时间都做了汇总，这个汇总不是求平均，而是做了数据压缩，把每一个响应时间的次数统计一下，把这个key-value的数据传到我们监控的平台上，这样传输的数据量变小了，同时在计算的时候，只要对map的key值进行计算就可以了，这是中间的小技巧。

还有作为一个压测的生态来说，监控是必不可少的，除了对压力机的监控还有被测服务的监控，监控的内容包括资源的监控还有发下请求的监控，对于性能监控来说一定是秒级的，往往程序里面GC时间很短，在频繁GC的情况下，压测图形的秒级监控会形成一个锯齿状。另外在GC的时候，还有可能TPS就会掉0，掉坑，这种锯齿状的处理能力可能会造成线上的问题，所以压测监控一定要按照秒级监控。另外一个要注意的是，发压端与被测端对比。有时候出现这种场景：研发人员很自信：我的监控数据很好、响应时间OK、可用率100%，但是从发压端来看，发压端真正是用户感知的，收到的响应时间跟慢，也有很多time out，但是发压端的监测是感觉不到的，这样的问题就需要再定位这是通过对比出来的。这种问题的原因有很多，比如网络传输，序列化和反序列化、系统资源的抖动等等，这就需要具体问题具体定位，这个对于初级性能测试人员是往往容易忽略的问题。

讲完工具，再看看京东是怎么做链路化压测这种实践的，怎么利用forcebot平台做全链路压测的?首先定义一下压测的目的：对容量整体的评估，对资源再分配;第二点看压测方式：我们的军演是把压力机部署在CDN上，通过外网模拟真实用户，这样的好处是压测链路比较长，包括公司负载均衡、网关、安全都压到了，但是这套实施的难点就是数据流量的识别，到底哪些是测试数据，这是千万不能影响线上环境的，也不能给线上带来脏数据，数据的改造是每一个公司都要面临的问题。京东做这件事做了一年多，到现在也继续在持续改造着，上次讲完很多朋友都在问京东是怎么做的。我再来解释一下，最重要的一点是在公司领导层面达成一致。为了一个质量的改进或者质量的验证，可能会牺牲业务开发的时间，公司高层一定要达成一致意见后再往下推，在推的时候建议各个业务条线架构师配合，如果让测试人员做技术改造可能有点困难，但是测试人员比较适合做推动者和倡导者，因为改进的是我们的质量，是跟我们的工作息息相关的，可以提高测试效率和效果。最后一定要每周做例会、回顾、周报什么的，通过项目制，把系统改造作为很重要的事推进下去。

如图，我们是这样做的打标流量识别，首先在测试之前先准备一些测试数据、测试帐号，发压的时候需要打标，因为是模拟用户行为，所以一般都是HTTP请求，第一层服务识别这个标再进行RPC透传。这也是看业务系统如何改造，如果有能力的话最好在RPC框架基础上做流量识别、流量隔离。如果不方便从业务层面改造识别也是OK的，改造方式其实有很多，有可能配置一个影子库、影子中间件，有可能就写进一个打标的数据，事后再进行清理，这些都是可行的办法。在京东我们也是每一条线处理的方式有区别。

最后看链路化压测，每年的双十一、618都会做链路化压测，这个压测前前后后可能从准备到最终实施要一周多的时间。准备的时候要确认压测范围、确定好流量到那个环节就会停止住了，或者说是有哪些入口、哪些系统需要参与压测对于中台来说，是否需要补量压测场景的设计和评审、数据的准备，这就需要花很长的时间了。

第二步要在压测前，把我们的脚本还有我们的数据准备好，压测池的资源分配、压测数据提前录制好、准备好，分发到压力机上，因为这个数据往往都是很大的文件，线上录制也好，构建生成也好，要提前同步到压力机上，实时拉取可能会影响效果。还要准备好我们要压什么、紧急预案是什么、发生问题第一联系人是谁等等，在压测前一天晚上，要准备好小流量的验证，可以先试压一下，最后再线上流量的验证。实施阶段，我们一般是线上扛量用一个机房，压测用另外一个机房，压测流量需要适时调整，还有降级演练，最后还要把压测成绩单进行汇总。这个步骤每年都会很费时、很费力，从数据准备到脚本验证再回放，其实回放可能不会很长时间，但是前期的数据准备、构造会很耗时。

这就说到全链路的一个痛点，也就是我们为什么做流量回放，这是今年我们想的一个平台2.0的演进。

作为平台开发来说，链路化压测做完以后下一步做点什么？业界都会想到自动化、智能化、常态化，这样的 title很大，但是怎么做到呢？我们首先想到从数据的准备到发压做成自动化，就是流量的录制和回放。不再需要写脚本和准备数据，这样从真实环境上录制流量，当然这个前提是，业务改造一定要相当的完备了，我们写的流量到底能不能去识别？这个是很必要的。其实做流量回放在京东也是有背景的，在618今年也发生这样一件事，之前军演准备的时候，我系统处理的TPS可以达到很高，但实际上在流量高峰的时候，发现还没有到达这个TPS，系统资源CPU就已经耗尽了。后来，分析原因还是压测场景设计的不到位，比如，同样是一个查询用户的接口，用户信息多和用户信息量少，这个对于系统来说处理是不同的，我们准备压测场景还没有完全覆盖住真实的线上状态，所以这也是驱动我们必须要做这么一件事的原因：真实的线上的流量回放。

另外一个方面，刚才也提到了，流量回放不仅仅是单机对于单一应用的回放，是中台和前台体系所有入口流量通通进行回放，这个在回放过程中天然形成一个配比关系。以往我们的配比关系都是专门分析出来的，例如同一个系统里的三个接口，配比1：3，是通过分析日志，或者分析以往的流量得到的。而流量回放的时候，这个比例是天然形成的，不用再参考、不用再设计了。这是一个巨大的方便优势。；

第三是切实做到提效，我们想做常态化的压测，想把这种军演、链路化压测成为常态化，除了系统改造，还要实施的很方便，录制数据不需要研发配合，不需要在应用端抓log，不需要改java代码拦截流量数据，回放的时候也不需要再写脚本了，这是一个常态化或者说自动化的前提。其实从入口上录的流量还有一个好处：不再依赖于被测系统，不再依赖于线上应用。以往我们对线上应用的log录制的话，在大促的时候可能是不敢打开的，因为会影响线上的性能，但是如果我们从入口交换机分光出来的流量对业务是完全无侵扰的，可以随时随地的录，这也是它的好处之一。

最终达到这样一个效果，线上流量录制，然后放在数据中心再做压测流量的回放。

如图，这是我们实现的一个架构，其实我们也在实践阶段，方案并不是很完备，更多实现细节我也就不再详细的介绍了，主要还是这样几个模块，抓取模块从分光器上把流量抓取，到一个性能非常好的消息队列里面，之后再增加一个安全模块。线上数据安全性问题是非常重要的，在互联网行业，安全再怎么做都不会过分，因为用户安全可能会有各种各样的问题。最后落盘到京东一个分布式系统里面，大家可以用自己公司的文件系统，这个加密后的数据也可以放到内网回放，甚至用于功能回放都是OK的。具体怎么用，依赖于域名的过滤，根据自己的系统适配就行了，回放的时候可以用个固定的脚本，把录制的东西当作参数化文件进行发压。

最后做一个比喻，流量录制回放相当于蓄水池的概念，用几个小时的时间把线上数据录制下来集中存放，然后再用很短的时间集中释放，达到模拟洪峰来临的效果。今年在双十一备战上我们的流量录制已经在开始用了，效果还是可以的，很多业务的配比关系直接用这样的真实数据了，业务的测试也比较轻松了，不用再写很多脚本了，也不用再向研发要这种参数数据了。

最后有一点想说的是，“醉里挑灯看剑，梦回吹角连营。”线上各种各样的状态牵动着测试人员的心，希望大家还是用自己的技术改变公司的质量文化、质量氛围，从自己做起。谢谢大家！

相关文章