CN111625452A

CN111625452A - 流量回放方法和系统

Info

Publication number: CN111625452A
Application number: CN202010444014.8A
Authority: CN
Inventors: 沈佳伟; 贾艳祥
Original assignee: Shanghai Bilibili Technology Co Ltd
Current assignee: Shanghai Bilibili Technology Co Ltd
Priority date: 2020-05-22
Filing date: 2020-05-22
Publication date: 2020-09-04
Anticipated expiration: 2040-05-22
Also published as: CN111625452B

Abstract

本申请实施例提供了一种流量回放方法，所述方法包括：录制目标服务的数据流量以得到录制流量；其中，所述录制流量包括多个调用链路对应的多组调用链路数据，每组调用链路数据包括相应的调用链路中的多个调用事件对应的多组调用数据；及将所述录制流量推送至回放计算机设备，以通过所述回放计算机设备将所述录制流量用于流量回放。本实施例提供的录制流量，由于提供了整个调用链路的各个调用事件的调用数据，使得在测试环境中对目标服务进行测试时，并不需要与生产环境相同的配套设备，有效减少了测试环境中的目标服务所需的各种外部架构、各种设备间交互和测试成本。

Description

流量回放方法和系统

技术领域

本申请实施例涉及计算机技术领域，尤其涉及一种流量回放方法、系统、计算机设备及计算机可读存储介质。

背景技术

随着互联网行业的业务规模不断扩大，系统设计也越来越复杂。在业务复杂度的系统上进行业务快速迭代时，对系统的鲁棒性、兼容性、测试覆盖率以及实效性也提出了更高的要求。人人往往通过更多的自动化回归脚本和人工编写的脚本，来适应这种要求。但是，由于系统每时每刻都在演化，自动化回归脚本的正确性和实效性很难得到保证，同时人工编写的脚本不能有效地覆盖大量的真实业务场景。

为了减缓复杂度之熵对系统迭代造成的影响，通常需要采用流量回放技术来保障在业务场景、服务架构复杂下的系统测试，将线上真实的数据流转化为覆盖全面的回归测试用例。流量回放技术，是指对生产环境下的业务流量执行录制，并将录制后的业务流量用于在生产环境或测试环境中进行回放的一种测试技术。

在现有技术中，当需要对某个服务在测试环境中进行测试时，测试环境中的配套设备和生产环境中的配套设备需要对应一致，从而造成测试环境下的服务架构复杂、设备间交互复杂、测试成本高昂的问题。

发明内容

本申请实施例的目的是提供一种流量回放方法、系统、计算机设备及计算机可读存储介质，用于解决以下问题：当需要对某个服务在测试环境中进行测试时，测试环境中的配套设备和生产环境中的配套设备需要对应一致，从而造成测试环境下的服务架构复杂、设备间交互复杂、测试成本高昂的问题。

本申请实施例提供了一种流量回放方法，所述方法包括：录制目标服务的数据流量以得到录制流量；其中，所述录制流量包括多个调用链路对应的多组调用链路数据，每组调用链路数据包括相应的调用链路中的多个调用事件对应的多组调用数据；及将所述录制流量推送至回放计算机设备，以通过所述回放计算机设备将所述录制流量用于流量回放。

可选的，每组调用数据包括：(1)相应的调用事件中的交互数据；(2)调用链路标识，用于表示所述相应的调用事件所对应的调用链路；(3)调用编号，用于表示所述相应的调用事件在所述对应的调用链路中的调用顺序；(4)调用链路入口数据，用于表示所述相应的调用事件的调用入口。

可选的，还包括：获取每个调用链路中各个调用事件对应的调用编号，包括：通过Trace传递组件获取计数器并通过所述计数器进行计数操作；及根据计数结果确定各个调用事件的调用编号；其中，所述计数器为基于Trace的计数器并被预先存储在全局ConcurrentHashMap中。

可选的，录制目标服务的数据流量以得到录制流量，包括：根据调用入口，将AOP代理拦截器注入到所述目标服务中；及通过所述AOP代理拦截器进行AOP拦截操作，以获取所述目标服务在各个调用事件中的交互数据。

可选的，所述调用入口包括DB入口、Redis入口和Feign入口。

可选的，所述AOP代理拦截器为继承JVM Sandbox并用于流量录制的增强代码。

可选的，每组调用数据是经过JSON序列化得到的包括元数据的字符串。

可选的，将所述录制流量推送至回放计算机设备，包括：通过限容队列将所述录制流量转发至Kafka中，以便所述Kafka推送所述录制流量至所述回放计算机设备中。

本申请实施例又提供了一种流量回放系统，所述流量回放系统，包括：录制模块，用于录制目标服务的数据流量以得到录制流量；其中，所述录制流量包括多个调用链路对应的多组调用链路数据，每组调用链路数据包括相应的调用链路中的多个调用事件对应的多组调用数据；及推送模块，用于将所述录制流量推送至回放计算机设备，以通过所述回放计算机设备将所述录制流量用于流量回放。

本申请实施例又提供了一种计算机设备，包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述流量回放方法的步骤。

本申请实施例又提供了一种计算机可读存储介质，包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如上述流量回放方法的步骤。

本申请实施例又提供了一种用于回归测试的流量录制方法，所述方法包括：基于录制流量，对目标服务进行流量回放操作；其中，所述录制流量是在生产环境下预先录制得到的，所述录制流量包括多个调用链路对应的多组调用链路数据，每组调用链路数据包括相应的调用链路中的多个调用事件对应的多组调用数据。

可选的，对目标服务进行流量回放操作，包括：判断所述目标服务中的请求是否触发AOP代理拦截器；其中，所述AOP拦截器被预先注入到所述目标服务中；及如果所述请求触发所述AOP代理拦截器，则通过所述AOP代理拦截器从录制流量中获取与所述请求属于同一调用链路中的相应调用事件的目标调用数据，并将所述目标调用数据作为响应回放至所述目标服务中。

可选的，所述AOP代理拦截器为继承JVM Sandbox并用于流量回放的增强代码。

可选的，判断所述目标服务中的请求是否触发AOP代理拦截器的拦截操作，包括：判断所述请求中否携带回放开关标识；及如果所述请求携带所述回放开关标识，则触发所述AOP代理拦截器进行拦截操作。

可选的，判断所述目标服务中的请求是否触发AOP代理拦截器的拦截操作，包括：判断所述请求中否携带跳跃标识，其中，所述跳跃标识用于指示针对所述请求不执行流量回放操作；及如果所述请求携带所述跳跃标识，则不触发所述AOP代理拦截器的拦截操作。

可选的，还包括：编辑所述目标调用数据，并将编辑后的目标调用数据作为响应回放至所述目标服务中。

本申请实施例提供的流量回放方法、系统、计算机设备及计算机可读存储介质，由于录制了整个调用链路的各个调用事件的调用数据，使得在测试环境中对目标服务进行测试时，并不需要与生产环境相同的配套设备，有效减少了测试环境中的目标服务所需的各种外部架构、各种设备间交互和测试成本。

附图说明

图1示意性示出了根据本申请实施例的流量回放方法运行环境图；

图2示意性示出了流量录制效果图；

图3示意性示出了流量回放效果图；

图4示意性示出了目标服务涉及的示例性调用步骤；

图5示意性示出了实现图2所示流量录制效果的流量录制的具体实施方法；

图6示意性示出了录制流量的流向图；

图7A～7E示意性示出了流量录制操作中的AOP拦截的一些示例数据流向图；

图8示意性示出了录制流量的另一流向图；

图9A～9E示意性示出了流量回放操作中的AOP拦截的一些示例数据流向图；

图10示意性示出了根据本申请实施例一的流量回放方法的流程图；

图11示意性示出了图10中步骤S1000的子步骤流程图；

图12示意性示出了图10中步骤S1000的另一子步骤流程图；

图13示意性示出了图10中步骤S1002的子步骤流程图；

图14示意性示出了根据本申请实施例二的流量回放系统的框图；

图15示意性示出了根据本申请实施例三的适于实现流量回放方法的计算机设备的硬件架构示意图；

图16示意性示出了根据本申请实施例五的流量回放方法的流程图；

图17示意性示出了图16中步骤S1600的子步骤流程图；

图18示意性示出了图17中步骤S1700的子步骤流程图；

图19示意性示出了图17中步骤S1700的另一子步骤流程图；及

图20示意性示出了图16中步骤S1600的另一子步骤流程图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

需要说明的是，在本申请实施例中涉及“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本申请要求的保护范围之内。

流量回放包括以下两个阶段：录制阶段和回放阶段；

录制阶段，在于生成录制流量。所述录制流量是通过录制生产环境(Prod)中的目标服务的服务流量得到的。所述服务流量是所述目标服务和客户端交互期间产生的真实流量。

回放阶段，在于将所述录制流量用于对测试环境(UAT)中的目标服务进行回放操作，即：将所述录制流量输入至所述测试环境中的目标服务中，并判断所述测试环境中的目标服务的响应数据和所述生成环境中的目标服务输出的响应数据是否是一致的。

图1提供了一种目标服务的流量回放操作的环境示意图。需要说明的是，该目标服务可以是「会员购」服务或其他各类互联网服务。生产环境中的目标服务和测试环境中的目标服务是同一个服务。但是，为了方便表述，下文将如图1所示将生产环境中的目标服务称之为Service A1，将测试环境中的目标服务称之为Service A2。

如图1所示，所述环境示意图包括生产环境和测试环境。所述生成环境通常为线上环境，包括Prod计算机设备2以及服务器2、4、6等。所述测试环境可以是线上环境、线下环境，包括回放计算机设备10、UAT计算机设备12和回放数据库(Repeat DB)14。

Prod计算机设备2配置有Service A1，用于为用户提供Service A1服务。Prod计算机设备2可以是基于Spring Cloud框架搭建的集群系统。Prod计算机设备2连接于服务器4、6、8。服务器4、6、8用于供Service A1调用，为Service A1提供相应的外部数据。Service A1可以处理来自客户端(如手机、电脑等)的请求，并将相应的响应返回给所述客户端。需要说明的是，根据Service A1的业务需求，可以增加或删减相应的服务器。各个服务器对应的硬件系统、软件系统等，亦可以视情况设置。

Prod计算机设备2还配有录制组件(如，Copy Agent)，并连接于回放计算机设备10。Prod计算机设备2可以通过录制组件录制Service A1的数据流量，从而得到对应于Service A1的录制流量，并将该录制流量推送至回放计算机设备10中。

UAT计算机设备12配置有Service A2。Service A2用于根据回放计算机设备10提供的录制流量进行回归测试，以验证所述目标服务的缺陷和所述目标服务的稳定性等。UAT计算机设备12还配有回放组件(如，Repeat Agent)。该回放组件在于从回放服务器10中获取录制流量，并将获取到的录制流量导入到Service A2，以对Service A2进行测试。

回放数据库(Repeat DB)14，用于存储回放计算机设备10异步存入的录制流量。

需要说明的是，Prod计算机设备2、UAT计算机设备12，可以由多个服务器组成，用于提供「会员购」服务。该多个服务器可以包括虚拟化计算实例。虚拟化计算实例可以包括虚拟机，诸如计算机系统的仿真，操作系统，服务器等。服务器可以基于定义用于仿真的特定软件(例如，操作系统，专用应用程序，服务器)的虚拟映像和/或其他数据来加载虚拟机。随着对不同类型的处理服务的需求改变，可以在一个或多个服务器上加载和/或终止不同的虚拟机。可以实现管理程序以管理同一服务器上的不同虚拟机的使用。

为了方便介绍流量回放操作，本实施例示例性地将服务器4设定为用于提供DB(Database，数据库)，示例性地将服务器6设定为用于提供Feign(第三方远程服务，ServiceB)，以及示例性地将服务器8设定为用于提供Redis(Remote Dictionary Server，远程字典服务)。

图2和图3提供了示例性流量录制流程和示例性流量回放流程。

所述流量录制流程，是在生产环境中的Prod计算机2中执行的。如图2所示，Service A1响应于HTTP request调用DB、Service B或Redis。通过所述流量录制流程得到的录制流量，包括调用链路的调用链路数据，如HTTP request、HTTP response、以及在生成HTTP response过程中Service A1和其他服务之间的调用数据。

所述流量回放流程，是在测试环境中的UAT计算机设备12中执行的。如图3所示，UAT计算机设备12根据上述流量录制流程得到的录制流量执行流量回放操作，以测试Service A2。例如，UAT计算机设备12可以执行如下操作：将录制流量中的其中一个HTTPrequest输入到Service A2中；当Service A2基于这个HTTP request调用DB时，可以拦截这个调用操作，并将录制流量中相应的DB调用数据(DB反馈的响应Response)返回给ServiceA2，使得Service A2认为它已经执行了DB调用操作。

由以上内容可知，本实施例提供的流量录制流程和流量回放流程，不局限于仅仅录制服务入口流量(即，HTTP入口层的HTTP request和HTTP response)，还录制了调用链路内部的调用数据(如，调用链路内部对DB、Reids及Service B的Request/Response)。相对于现有技术中的TcpReplay、TcpCopy等仅局限于复制服务入口流量，其流量回放服务必须要配套和流量录制环境(即，生成环境)一致的DB、Service B或Redis等，本实施例具有如下好处：测试环境中的Service A2不需要和生产环境中的Service A1相同的配套环境(如DB、Service B、Redis等)，从而有效减少了测试环境中的Service A2所需的各种外部架构和各种设备间交互。

【流量录制】

下文将提供示例性的技术手段，来实现图2提供的流量录制流程。

如图4所示，响应于入口层的请求(如，HTTP request)，Service A1可能会涉及各个步骤，例如：

(1)Service A1接收request；

(2)Service A1接收request→Service A1访问DB；

(3)Service A1接收request→Service A1访问DB→Service A1访问Redis；

(4)Service A1接收request→Service A1访问DB→Service A1访问Redis→Service A1访问Service B；

(5)Service A1接收request→Service A1访问DB→Service A1访问Redis→Service A1访问Service B→Service B访问Redis；

(6)Service A1接收request→Service A1访问DB→Service A1访问Redis→Service A1访问Service B→Service B访问Redis→Service A1返回响应(response)。

从上述各个步骤可以看出：

(1)入口层的Request/Response处于调用链路的首位和末尾；

(2)处于调用链路中间的各组调用数据属于无效信息，无法用于流量回放。原因如下：调用链路在应用内部的顺序是高度不确定的且没有任何规律，比如：可能先调用DB后调用Redis，也可能先调用Redis后调用同样的DB SQL多次。

为了使得调用链路中的各组调用数据能够用于流量回放操作中，本实施例将以下概念引入到流量录制过程中。

以下对本文涉及到的一些术语进行解释。

调用链路：是指以调用事件为节点构成的链路。该链路的链首为入口层的请求、链尾入口层的响应，以及处于链首和链尾之间的一个或多个中间节点。每个中间节点对应Service A1与其他服务之间的一次调用事件，如对DB的第一次调用事件，对DB的第二次调用事件，对Feign的第一次调用事件等。在某个调用链路中，当链首和链尾包括多个中间节点时，这些中间节点在所述调用链路中的分布是根据调用顺序先后排列的。

调用链路数据：包括调用链路中各个调用事件对应的调用数据，如对应于链首的调用数据、对应于链尾的调用数据，以及处于链首和链尾之间的一个或多个调用事件对应的调用数据。各个调用事件对应的调用数据包括入参(如，HTTP入口层的HTTP request，Service A1调用DB、Reids、Feign过程中产生的Request)、出参(如，HTTP入口层的HTTPresponse，Service A1调用DB、Reids、Feign过程中得到的Response)，以及Entry。该Entry用于记录调用入口信息(如，进入DB、Reids、Feign等的端点的切入位置)。所述端点(Endpoint)的切入位置可以理解为进入指定调用入口的指定代码位置。当然，入参或出参是可以根据调用对象、传输协议等调整的。

当一个调用链路中包括多个调用事件或多次调用事件时，需要为这个调用链路中的所有调用事件统一配置一个调用链路标识；及，需要为这个调用链路中的每个/次调用事件分别配置一个调用编号。

所述调用链路标识(Trace)，用于串联流量回放的相应的调用链路。例如，响应于一个HTTP request A，Service A1需要进行一系列的调用步骤，例如对DB的一次或多次调用、对Feign的一次或多次调用等。对于这一系列调用步骤中的关联数据都会统一配置同一个调用链路标识。在后续的流量回放过程中，如果Service A2输入的是这个HTTP requestA，则可以找到与这个HTTP request A具有相同调用链路标识的其他调用数据，并将这些其他调用数据(或这些其他调用数据中的部分数据)用于与HTTP request A关联的流量回放操作中。

所述调用编号(Index)，用于记录各个调用链路中的各个调用事件的调用编号。所述Index在于通过编号的方式区分处于同一个调用链路中的各个调用事件的被调用顺序。也就是说，同一个调用链路中的所有调用事件都会同时被录制一个基于当前上下文的调用编号(如1，2，3等)。由于流量回放时的调用链路与流量录制时的调用链路是一致的，Index可以用于在流量回放时通过进行数据定位，即可以通过调用编号准确的找到各个步骤需要回放的调用数据(如调用数据中的Response等交互数据)。

所述调用编号(Index)，可以通过采用ThreadLocal(InheritableThreadLocal)绑定线程计数得到。但是在实际录制过程中发现由于基础组件的限制，并无法很好约束业务代码在调用链路方式上的规范，经常导致无法从线程获取计数器(比如不规范的使用线程池或中间件)。为解决这一个问题，在默认RestController为流量入口的情况下，在全局ConcurrentHashMap中存储基于Trace(调用链路标识)的计数器，随后在流量出口(或异常)时移除该计数器，使用时各调用入口的执行代码(Endpoint)通过Trace来获取计数器。

由以上内容可知，本实施例所述的流量录制流程，需要录制调用链路中各个调用事件的调用数据(如，Entry、入参、出参、Trace和Index)。如图5所示，其提供了一种实现上述流量录制的具体实施方法。该具体实施方法引入了AOP(aspect oriented programming，面向切面编程)拦截方案，以通过所述AOP拦截方案实现应用代码无侵入及流量录制过程中对Service A1极低的性能耗损。具体如下：(1)预先配置增强代码(Copy Agent)。该CopyAgent继承自JVM Sandbox，可以实现流量录制业务，并且可以在指定代码位置(即，端点的切入位置)进行代码织入(AOP)。(2)预先配置调用链路中各个调用入口，如DB入口、Redis入口和Feign入口。(3)通过内置事件模型(Before、After、Throw)以拦截事件(InterceptEvent)的形式通知Copy Agent，以使Copy Agent执行AOP拦截操作；(4)通过Copy Agent进行AOP拦截，以获取Service A1与DB、Redis、Feign等之间的交互数据，如入参、出参等。(5)通过MQ(message queue，消息队列)、DataBus(数据抓取系统)或Kafka(分布式发布订阅消息系统)将包含入参、出参、Entry、Trace、Index等的调用数据推送到用于提供回放服务(Repeat Service)的回放计算机设备10中，如图6所示。所述调用数据在随后被RepeatService异步消费后存入回放数据库(Repeat DB)14中。

如图7A～图7E所示，其为流量录制操作中的AOP拦截的一些示例数据流向图。

(1)拦截入口层(RestController)，如Spring rest(Representational StateTransfer，表述行状态转移)。

如图7A所示，Prod计算机设备2接收请求(request)，通过Spring rest对request进行数据转换，以得到转换后的参数并将所述转换后的参数提供给Service A1。ServiceA1接收该转换后的参数，基于该转换后的参数进行响应。在此期间，Copy Agent可以通过attach的方式被注入到Service A1中，从而获取Spring rest的调用数据(即，request)。这些调用数据在获取之后，通过MQ或DataBus或Kafka推送到用于提供Repeater service的回放计算机设备10中，以及被异步存储到Repeater DB中。

(2)拦截DB入口层(MyBatis.MapperProxy)。

如图7B所示，响应于所述转换后的参数，Service A1调用DB。在该期间，ServiceA1和DB之间进行网络交互，例如服务A向DB发送一个请求，DB响应于该请求并返回一个响应。在此期间，Copy Agent可以通过attach的方式被注入到Service A1中，从而获取DB入口层的调用数据(入参和出参)。这些调用数据在获取之后，通过MQ或DataBus或Kafka推送到用于提供Repeater service的回放计算机设备10中，以及被异步存储到Repeater DB中。

(3)拦截缓存入口层(AbstractOperations)。

如图7C所示，响应于所述转换后的参数，Service A1调用缓存Redis。在该期间，Service A1和Redis之间进行网络交互，例如Service A1向Redis发送一个请求，Redis响应于该请求并返回一个响应。在此期间，Copy Agent可以通过attach的方式被注入到ServiceA1中，从而获取缓存入口层的数据(入参和出参)。这些调用数据在获取之后，通过MQ或DataBus或Kafka推送到用于提供Repeater service的回放计算机设备10中，以及被异步存储到Repeater DB中。

(4)拦截远程调用入口层(FeignClient)。

如图7D所示，响应于所述转换后的参数，Service A1调用第三方服务(如，ServiceB)。在该调用期间，Service A1和Service B之间进行网络交互，例如Service A1向ServiceB发送一个请求，Service B响应于该请求并返回一个响应。在此期间，Copy Agent可以通过attach的方式被注入到Service A1中，从而获取远程调用入口层的数据(入参和出参)。这些调用数据在获取之后，通过MQ或DataBus或Kafka推送到用于提供Repeater service的回放计算机设备10中，以及被异步存储到Repeater DB中。

(5)拦截跨服务缓存入口层(AbstractOperations)。

如图7E所示，响应于Service A1提供的入参，Service B调用Redis。在该期间，Service B和Redis之间进行网络交互，例如Service B向Redis发送一个请求，Redis响应于该请求并返回一个响应。在此期间，Copy Agent可以通过attach的方式被注入到Service B中，从而获取拦截缓存入口层的数据(入参和出参)。这些调用数据在获取之后，通过MQ或DataBus或Kafka推送到用于提供Repeater service的回放计算机设备10中，以及被异步存储到Repeater DB中。

在示例性的实施例中，在入参/出参/及上文提到的调用编号均完备的情况下，可以通过JSON序列化(JavaScript Object Notation serialize)将调用数据转换为包含元数据(比如Class信息，数组或者集合的元素类型等)的字符串，并将该字符串推送至MQ/Databus/kafika中，以通过MQ/Databus/kafika将该字符串推送到Repeat Service中。

在现有技术中，简单的序列化对象，使用时动态的通过解析当前Method的ResultType来反序列化。但是，如果使用动态解析类型，会面临的特殊场景非常之多，比如泛型或抽象接口，又比如被代理后对象的解析，兼容所有场景的难度非常之大。相对于现有技术而言，本实施例通过JSON序列化，可以避免简单序列化所带来的复杂场景兼容性的问题。

在示例性的实施例中，优选通过Kafka推送调用数据。Kafka的优势如下：(1)相对于同步数据传递方式(如HTTP)，Kafka能够在传递数据的同时尽可能减少对业务的影响；(2)相对于Log Agent日志收集和异步消息队列的方式，Kafka落地成本更低。当然，在另一些实施例中，也可以使用Log Agent日志收集方式。另外，考虑到一定的容错场景，调用数据并不会直接推送至Kafka，而是首先会推送至由内部限容队列LinkedBlockingQueue，再通过限容Queue转发至Kafka，这么做也是为了防止即使Kafka产生了抖动，对业务系统并不会有过大的影响。

在示例性的实施例中，优选通过DB、MySQL等存储调用数据。

当前选择的还是MySQL进行存储，因为通过部署在集成测试环境进行集成测试后的流量采集，若干天后的数据约为百万条，存储容量为10G内。同时考虑到线上环境会对流量录制进行一定限制和优化：如非业务HTTP入口的流量不采集(过滤JOB)，按Trace ID进行百分比采样，数据存储前使用Snappy压缩等。目前以「会员购」探索的业务场景来说，使用MySQL存储"三天回放"的数据量并没有问题。当然同时我们也在尝试使用TiDB或其他时序数据库进行存储的可能。

【流量回放】

下文将提供示例性的技术手段，来实现图2提供的回放流程。

如图8所示，Copy Agent用于在生成环境中录制涉及Service A1的数据流量，以得到录制流量；并通过MQ/DataBus/Kafka等方式将录制流量推送至用于提供Repeat Service的回放计算机设备10中；Repeat Agent用于在测试环境中向Repeat Service请求录制流量并对Service A2执行流量回放操作。所述流量回放可以参照流量录制。例如：预先配置增强代码(Repeat Agent)。该增强代码继承自JVM Sandbox并用于流量回放，并且可以在录制流量同样的代码位置(即，端点的切入位置)进行代码织入(AOP)，这样做的目的是保证流量录制与流量回放时，双方的调用入口和调用编号是一致的。所述流量回放和所述流量录制区别在于，所述流量录制是序列化数据后推送Kafka；流量回放是反序列化数据，并将反序列化数据作为Method Result返回。这样执行流量回放后的系统，除了自身代码是实际运行的，诸如DB，Redis及其他服务的数据均是通过回放数据来进行的。

需要说明的是，流量录制过程中，生产环境下的Service A1的配套设备非常复杂，如包括用于提供DB服务的服务器4、用于提供Feign服务的服务器6、用于提供Redis服务的服务器8等。然而，考虑到成本等因素，测试环境中无法为Service A2配置与生产环境中相同的配套设备。本实施例所述的流量回放方法，在测试环境不配置DB、Redis、Feign等服务器的情况下，实现对Service A2的回归测试，从而有效简化了测试环境的架构和降低了测试成本。

在实际测试过程中，Service A2可能有多个测试项目。为了不影响其他测试项目，回访请求中预先配置有回放开关标识，从而快速识别出Service A2中的哪些请求属于回放请求，哪些请求不属于回放请求。

根据各个请求中的回放开关标识，获取回放请求。对于回放请求，则触发RepeatAgent进行拦截，并通过访问Repeat Service返回已经录制的数据。对于常规请求则不触发，从而保证回放服务对环境是无侵入的。

示例性的，如果是回放请求，则附带一个特定的HTTP Header，对于符合规则的请求(带特定Header)进入Endpoint时则开启流量回放，否则直接跳过。从目前的场景来看这个方法是满足需求且几乎无需改动的，但是考虑到一些定制化的回放场景，比如数据库有兼容性修改，仅需要回放HTTP和Redis但不回放DB等，依然是需要传递回放配置供RepeatAgent区分的。

如图9A～9E所示，其为流量回放操作的AOP拦截的一些示例数据流向图。需要说明的是，图9A～9E中的DB、Redis、Service B是为了便于理解而绘制，它们在测试环境中并不存在对应的物理实体。

(1)流量进入。

Repeat Agent通过attach的方式被注入到Service A2中。

如图9A所示，响应于携带Trace的回放请求，判断回放请求是否触发了RepeatAgent；如果该回放请求触发Repeat Agent，则触发Repeat Agent向Repeat Service请求录制流量中的相应的HTTP request，并将该相应的HTTP request进行流量回放操作。

(2)通过Repeat Agent进行回放DB数据(不访问DB)。

Repeat Agent通过attach的方式被注入到Service A2中。

如图9B所示，响应于Service A2调用MyBatis，触发Repeat Agent进行拦截并向Repeat Service请求录制流量中的相应的入参/出参等，并将该相应的入参/出参进行流量回放操作，从而避免从DB的访问。

(3)通过Repeat Agent进行回放Redis数据(不访问Redis)。

Repeat Agent通过attach的方式被注入到Service A2中。

如图9C所示，响应于Service A2调用Redis，触发Repeat Agent进行拦截并向Repeat Service请求录制流量中的相应的入参/出参等，并将该相应的入参/出参进行流量回放操作，从而避免从DB的访问。

(4)通过Repeat Agent进行回放Feign数据(不访问Service B)。

Repeat Agent通过attach的方式被注入到Service A2中。

如图9D所示，响应于Service A2调用Feign，触发Repeat Agent进行拦截并向Repeat Service请求录制流量中的相应的入参/出参等，并将该相应的入参/出参进行流量回放操作，从而避免从Feign的访问。

(5)通过Repeat Agent对外部输入(DB，Redis，Feign等)的数据回放，断言Reponse。

Repeat Agent通过attach的方式被注入到Service A2中。

如图9E所示，响应于Service B调用Feign，触发Repeat Agent进行拦截并向Repeat Service请求录制流量中的相应的入参/出参等，并将该相应的入参/出参进行流量回放操作。在Service A2所有外部输入采用回放的情况下，断言Service A2的Response应该与流量录制时Service A1的Response一致，从而达到将线上真实的数据流转化为覆盖全面的回归测试用例的用途。

在示例性的实施例中，还可以进行定制化的流量回放(即，允许跳过某些步骤的回放，允许编辑回放数据等)，个性化的Response断言(区分属性顺序和兼容性属性)，更多的系统集成(比如集成Jacoco提高测试覆盖率，比如集成Skywalking进行线上问题回放)。流量回放可以极大的减少开发和测试在浩瀚的祖传代码中上线新功能时回归负担，投入回报的价值会随着时间的推移越来越大。

下文将提供多个实施例，不难理解，下文提供的各个实施例可以用于解决上文提及到的至少部分问题。

实施例一

图10示意性示出了根据本申请实施例一的流量回放方法的流程图。可以理解，本方法实施例中的流程图不用于对执行步骤的顺序进行限定。下面以Prod计算机设备2为执行主体进行示例性描述。

如图10所示，该流量回放方法可以包括步骤S1000～S1002，其中：

步骤S1000，录制目标服务(Service A1)的数据流量以得到录制流量。

所述录制流量包括多个调用链路对应的多组调用链路数据，每组调用链路数据包括相应的调用链路中的多个调用事件对应的多组调用数据。

步骤S1002，将所述录制流量推送至回放计算机设备10，以通过所述回放计算机设备10将所述录制流量用于流量回放。

本实施例提供的录制流量，不仅包括Service A1入口流量(如，HTTP入口层的HTTPrequest和HTTP response)，而且包括调用链路内部的调用数据(如，调用链路内部对DB、Reids及Service B的Request/Response)。本实施例提供的录制流量，由于提供了整个调用链路的各个调用事件的调用数据，使得测试环境中的Service A2不需要和生产环境中的Service A1相同的配套环境(如DB、Service B、Redis等)，从而有效减少了测试环境中的Service A2所需的各种外部架构和各种设备间交互。

在示例性的实施例中，每组调用数据可以包括：

(1)相应的调用事件中的交互数据；

(2)调用链路标识，用于表示所述相应的调用事件所对应的调用链路；

(3)调用编号，用于表示所述相应的调用事件在所述对应的调用链路中的调用顺序；

(4)调用链路入口数据，用于表示所述相应的调用事件的调用入口。

Prod计算机设备2为每个调用链路分配一个具有唯一性的调用链路标识。一个调用链路调用链路标识，用于串联这个调用链路所有相关的调用事件的调用数据(适用于流量录制和流量回放)。例如，响应于一个HTTP request A，Service A1需要进行一系列的调用步骤，例如对DB的一次或多次调用、对Feign的一次或多次调用等。对于这一系列调用步骤中的关联数据都会有同一个调用链路标识。在后续的流量回放过程中，如果Service A2输入的是这个HTTP request A，则会找到与这个HTTP request A具有相同调用链路标识的其他调用数据，并将这些其他调用数据用于与HTTP request A关联的流量回放操作中。

Prod计算机设备2为每个调用链路中的每个调用事件配置一个调用编号。例如，响应于一个HTTP request A，Service A1为响应这个HTTP request需要涉及一系列的调用事件，这一序列的调用事件构成调用链路。Prod计算机设备2为这个调用链路中的各个调用事件分配配置一个调用编号(如，调用事件1、调用事件2、调用事件3、…)，以记录各个调用事件在这个调用链路中的调用顺序。在后续的流量回放过程中，如果Service A2输入的是这个HTTP request A，UAT计算机设备12则会找到与这个HTTP request A具有相同调用链路标识的其他调用数据(如，调用事件1对应的调用数据、调用事件2对应的调用数据、调用事件3对应的调用数据、…)，并将这些其他调用数据用于与HTTP request A关联的流量回放操作中。基于调用事件1、调用事件2和调用事件3各自对应的调用数据均包括相应的调用标识，UAT计算机设备12回放各个调用事件的调用数据和Prod计算机设备录制这个调用链路中的各个调用事件的调用数据，顺序是可以一一对应的，从而使得：在测试环境中，所述录制流量中的调用数据可以取代真实的DB、Redis、Feign等服务器返回的数据，将流量录制流量中的调用数据(如，在生产环境下录制的与DB、Redis、Feign等之间的Response等交互数据)作为响应返回给Service A2。这样做的好处在于，在测试环境不配置DB、Redis、Feign等服务器的情况下，实现对Service A2的回归测试，从而有效简化了测试环境的架构和降低了测试成本。

在示例性的实施例中，如图11所示，步骤S1000可以包括获取每个调用链路中各个调用事件对应的调用编号，其可以通过步骤S1100～S1102实现。步骤S1100，通过Trace传递组件获取计数器并通过所述计数器进行计数操作。步骤S1102，根据计数结果确定各个调用事件的调用编号；其中，所述计数器为基于Trace的计数器并被预先存储在全局ConcurrentHashMap中。这样做的好处在于可以实现对各个调用链路中的各个调用事件进行准确的调用编号，并避免了现有技术的以下问题：采用ThreadLocal绑定线程的计数过程中因基础组件限制导致的计数失败。

在示例性的实施例中，如图12所示，步骤S1000可以包括步骤S1200～S1202。步骤S1200，根据调用入口，将AOP代理拦截器(Copy Agent)注入到所述目标服务(Service A1)中；步骤S1202，通过所述AOP代理拦截器(Copy Agent)进行AOP拦截操作，以获取所述目标服务(Service A1)在各个调用事件中的交互数据。通过AOP拦截操作，Prod计算机设备2可以实现流量录制过程中的代码入侵入及对Service A1极低的性能损耗。

在示例性的实施例中，所述调用入口包括DB入口、Redis入口和Feign入口。本实施例在于提供优选的调用入口。需要说明的是，以上调用入口仅是示例性入口，不用于限制本实施例配置其他调用入口。

在示例性的实施例中，所述AOP代理拦截器(Copy Agent)为继承JVM Sandbox并用于流量录制的增强代码。所述JVM SandBox是一种基于JVM平台实时无侵入AOP框架容器。需要说明的是，所述AOP代理拦截器(Copy Agent)也可以是基于其他框架的无侵入式拦截器。

在示例性的实施例中，每组调用数据是经过JSON序列化得到的包括元数据的字符串。通过每组调用数据进行JSON序列化的优势在于，可以避免现有技术中的简单序列化所带来的复杂场景兼容性的问题。

在示例性的实施例中，如图13所示，步骤S1002可以通过步骤S1300实现：通过限容队列将所述录制流量转发至Kafka中，以便所述Kafka推送所述录制流量至所述回放计算机设备中。本实施例具有以下优势：在Kafka产生抖动的情况下，使得业务系统也不会有过大的影响，具有很好的容错性。

实施例二

图14示意性示出了根据本申请实施例二的流量回放系统的框图，该流量回放系统可以被分割成一个或多个程序模块，一个或者多个程序模块被存储于存储介质中，并由一个或多个处理器所执行，以完成本申请实施例。本申请实施例所称的程序模块是指能够完成特定功能的一系列计算机程序指令段，以下描述将具体介绍本实施例中各程序模块的功能。

如图14所示，该流量回放系统1400可以包括录制模块1410和推送模块1420，其中：

录制模块1410，用于录制目标服务的数据流量以得到录制流量；其中，所述录制流量包括多个调用链路对应的多组调用链路数据，每组调用链路数据包括相应的调用链路中的多个调用事件对应的多组调用数据；及

推送模块602，用于将所述录制流量推送至回放计算机设备，以通过所述回放计算机设备将所述录制流量用于流量回放。

在示例性的实施例中，每组调用数据包括：

(1)相应的调用事件中的交互数据；

在示例性的实施例中，所述录制模块1410，还用于：获取每个调用链路中各个调用事件对应的调用编号，包括：通过Trace传递组件获取计数器并通过所述计数器进行计数操作；及根据计数结果确定各个调用事件的调用编号；其中，所述计数器为基于Trace的计数器并被预先存储在全局ConcurrentHashMap中。

Trace传递组件为用于传递调用链路标识(Trace)。

在示例性的实施例中，所述录制模块1410，还用于：根据调用入口，将AOP代理拦截器注入到所述目标服务中；及通过所述AOP代理拦截器进行AOP拦截操作，以获取所述目标服务在各个调用事件中的交互数据。

在示例性的实施例中，所述调用入口包括DB入口、Redis入口和Feign入口。

在示例性的实施例中，所述AOP代理拦截器为继承JVM Sandbox并用于流量录制的增强代码。

在示例性的实施例中，每组调用数据是经过JSON序列化得到的包括元数据的字符串。

在示例性的实施例中，所述推送模块1420，还用于：通过限容队列将所述录制流量转发至Kafka中，以便所述Kafka推送所述录制流量至所述回放计算机设备中。

实施例三

图15示意性示出了根据本申请实施例三的适于实现流量回放方法的计算机设备2的硬件架构示意图。本实施例中，计算机设备2是一种能够按照事先设定或者存储的指令，自动进行数值计算和/或信息处理的设备。例如，可以是智能手机、平板电脑、笔记本电脑、台式计算机等终端设备。如图15所示，计算机设备2至少包括但不限于：可通过系统总线相互通信链接存储器1510、处理器1520、网络接口1530。其中：

存储器1510至少包括一种类型的计算机可读存储介质，可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，存储器1510可以是计算机设备2的内部存储模块，例如该计算机设备2的硬盘或内存。在另一些实施例中，存储器1510也可以是计算机设备2的外部存储设备，例如该计算机设备2上配备的插接式硬盘，智能存储卡(Smart Media Card，简称为SMC)，安全数字(Secure Digital，简称为SD)卡，闪存卡(FlashCard)等。当然，存储器1510还可以既包括计算机设备2的内部存储模块也包括其外部存储设备。本实施例中，存储器1510通常用于存储安装于计算机设备2的操作系统和各类应用软件，例如流量回放方法的程序代码等。此外，存储器1510还可以用于暂时地存储已经输出或者将要输出的各类数据。

处理器1520在一些实施例中可以是中央处理器(Central Processing Unit，简称为CPU)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器1520通常用于控制计算机设备2的总体操作，例如执行与计算机设备2进行数据交互或者通信相关的控制和处理等。本实施例中，处理器1520用于运行存储器1510中存储的程序代码或者处理数据。

网络接口1530可包括无线网络接口或有线网络接口，该网络接口1530通常用于在计算机设备2与其他计算机设备之间建立通信链接。例如，网络接口1530用于通过网络将计算机设备2与外部终端相连，在计算机设备2与外部终端之间的建立数据传输通道和通信链接等。网络可以是企业内部网(Intranet)、互联网(Internet)、全球移动通讯系统(GlobalSystem of Mobile communication，简称为GSM)、宽带码分多址(Wideband Code DivisionMultiple Access，简称为WCDMA)、4G网络、5G网络、蓝牙(Bluetooth)、Wi-Fi等无线或有线网络。

需要指出的是，图15仅示出了具有部件1510-1530的计算机设备，但是应理解的是，并不要求实施所有示出的部件，可以替代的实施更多或者更少的部件。

在本实施例中，存储于存储器1510中的流量回放方法还可以被分割为一个或者多个程序模块，并由一个或多个处理器(本实施例为处理器1520)所执行，以完成本申请实施例。

实施例四

本申请还提供一种计算机可读存储介质，计算机可读存储介质其上存储有计算机程序，计算机程序被处理器执行时实现实施例中的流量回放方法的步骤。

本实施例中，计算机可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，计算机可读存储介质可以是计算机设备的内部存储单元，例如该计算机设备的硬盘或内存。在另一些实施例中，计算机可读存储介质也可以是计算机设备的外部存储设备，例如该计算机设备上配备的插接式硬盘，智能存储卡(Smart Media Card，简称为SMC)，安全数字(Secure Digital，简称为SD)卡，闪存卡(Flash Card)等。当然，计算机可读存储介质还可以既包括计算机设备的内部存储单元也包括其外部存储设备。本实施例中，计算机可读存储介质通常用于存储安装于计算机设备的操作系统和各类应用软件，例如实施例中流量回放方法的程序代码等。此外，计算机可读存储介质还可以用于暂时地存储已经输出或者将要输出的各类数据。

实施例五

图16示意性示出了根据本申请实施例五的流量回放方法的流程图。下面以UAT计算机设备12为执行主体进行示例性描述。如图16所示，该流量回放方法可以包括步骤S1600～S1602，其中：

步骤S1600，基于录制流量，对目标服务进行流量回放操作；

其中，所述录制流量是在生产环境下预先录制得到的，所述录制流量包括多个调用链路对应的多组调用链路数据，每组调用链路数据包括相应的调用链路中的多个调用事件对应的多组调用数据。

基于所述多个调用链路对应的多组调用链路数据，所述流量回放操作在于：当在Service A2检测到对应于其中一个调用链路中的请求时，在录制流量中找到这个调用链路的调用链路数据中的相应的调用数据(如，HTTP response)，并将这个调用数据(如，这个调用数据中的response)作为Method Result返回给Service A2。这样在流量回放操作中，Service A2自身代码是实际运行的，Service A2在测试过程中所需输入的数据(诸如DB、Redis及其他服务的交互数据)均是从录制流量中获取的。

在示例性的实施例中，每组调用数据包括：

(1)相应的调用事件中的交互数据；

基于每组调用数据所包含的各种信息，UAT计算机设备在进行流量回放时，在录制流量同样的位置(调用入口)进行代码织入。这做法保证了流量录制与流量回放时，双方的调用入口和调用编号是一致的。

在示例性的实施例中，如图17所示，所述步骤S1600包括：

步骤S1700，判断所述目标服务中的请求是否触发AOP代理拦截器(RepeatAgent)；其中，所述AOP拦截器(Repeat Agent)被预先注入到所述目标服务中；步骤S1702，如果所述请求触发所述AOP代理拦截器(Repeat Agent)，则通过所述AOP代理拦截器(Repeat Agent)从录制流量中获取与所述请求属于同一调用链路中的相应调用事件的目标调用数据，并将所述目标调用数据(如，目标调用数据中的Response)作为响应回放至所述目标服务中。如果所述请求没有触发所述AOP代理拦截器(Repeat Agent)，则不执行回放操作。本实施例确保回放服务在测试环境中是无侵入式的。

在示例性的实施例中，所述AOP代理拦截器(Repeat Agent)为继承JVM Sandbox并用于流量回放的增强代码。

在示例性的实施例中，如图18所示，步骤S1700可以包括以下步骤：步骤S1800，判断所述请求中否携带回放开关标识(如，HTTP header中的回放开关标识)；步骤S1802，如果所述请求携带所述回放开关标识，则触发所述AOP代理拦截器(Repeat Agent)进行拦截操作。这种做法可以快速识别是否需要针对所述请求进行流量回放操作。

在示例性的实施例中，如图19所示，步骤S1700可以包括以下步骤：步骤S1900，判断所述请求中否携带跳跃标识，其中，所述跳跃标识用于指示针对所述请求不执行流量回放操作；步骤S1902，如果所述请求携带所述跳跃标识，则不触发所述AOP代理拦截器(Repeat Agent)的拦截操作。这种做法的目的在于定制化回放链路，以允许在流量回放操作中跳过某些步骤的回放，以优化测试。

在示例性的实施例中，还包括步骤S2000：编辑所述目标调用数据，并将编辑后的目标调用数据作为响应回放至所述目标服务中。这种做法的目的在于定制化回放链路，以允许在流量回放操作中编辑需要返回到Service A2中的目标调用数据，并将编辑后的目标调用数据返回值Service A2，以优化测试。

显然，本领域的技术人员应该明白，上述的本申请实施例的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本申请实施例不限制于任何特定的硬件和软件结合。

以上仅为本申请的优选实施例，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。

Claims

1.一种流量回放方法，其特征在于，所述方法包括：

录制目标服务的数据流量以得到录制流量；其中，所述录制流量包括多个调用链路对应的多组调用链路数据，每组调用链路数据包括相应的调用链路中的多个调用事件对应的多组调用数据；及

将所述录制流量推送至回放计算机设备，以通过所述回放计算机设备将所述录制流量用于流量回放。

2.根据权利要求1所述的流量回放方法，其特征在于，每组调用数据包括：

(1)相应的调用事件中的交互数据；

(2)调用链路标识Trace，用于表示所述相应的调用事件所对应的调用链路；

(3)调用编号Index，用于表示所述相应的调用事件在所述对应的调用链路中的调用顺序；

3.根据权利要求1所述的流量回放方法，其特征在于，录制目标服务的数据流量以得到录制流量，包括：

获取每个调用链路中各个调用事件对应的调用编号，包括：

通过Trace传递组件获取计数器并通过所述计数器进行计数操作；及

根据计数结果确定各个调用事件的调用编号；其中，所述计数器为基于Trace的计数器并被预先存储在全局ConcurrentHashMap中。

4.根据权利要求1所述的流量回放方法，其特征在于，录制目标服务的数据流量以得到录制流量，包括：

根据调用入口，将AOP代理拦截器注入到所述目标服务中；及

通过所述AOP代理拦截器进行AOP拦截操作，以获取所述目标服务在各个调用事件中的交互数据。

5.根据权利要求4所述的流量回放方法，其特征在于，所述调用入口包括DB入口、Redis入口和Feign入口。

6.根据权利要求4所述的流量回放方法，其特征在于，所述AOP代理拦截器为继承JVMSandbox并用于流量录制的增强代码。

7.根据权利要求1所述的流量回放方法，其特征在于，每组调用数据是经过JSON序列化得到的包括元数据的字符串。

8.根据权利要求1所述的流量回放方法，其特征在于，将所述录制流量推送至回放计算机设备，包括：

通过限容队列将所述录制流量转发至Kafka中，以便所述Kafka推送所述录制流量至所述回放计算机设备中。

9.一种流量回放系统，其特征在于，包括：

录制模块，用于录制目标服务的数据流量以得到录制流量；其中，所述录制流量包括多个调用链路对应的多组调用链路数据，每组调用链路数据包括相应的调用链路中的多个调用事件对应的多组调用数据；及

推送模块，用于将所述录制流量推送至回放计算机设备，以通过所述回放计算机设备将所述录制流量用于流量回放。

10.一种计算机设备，所述计算机设备包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时用于实现权利要求1～8中任一项所述方法的步骤。

11.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质内存储有计算机程序，所述计算机程序可被至少一个处理器所执行，以使所述至少一个处理器执行权利要求1～8中任一项所述方法的步骤。

12.一种用于回归测试的流量录制方法，其特征在于，所述方法包括：

基于录制流量，对目标服务进行流量回放操作；

13.根据权利要求12所述的流量回放方法，其特征在于，每组调用数据包括：

(1)相应的调用事件中的交互数据；

14.根据权利要求12所述的流量回放方法，其特征在于，对目标服务进行流量回放操作，包括：

判断所述目标服务中的请求是否触发AOP代理拦截器；其中，所述AOP拦截器被预先注入到所述目标服务中；及

如果所述请求触发所述AOP代理拦截器，则通过所述AOP代理拦截器从录制流量中获取与所述请求属于同一调用链路中的相应调用事件的目标调用数据，并将所述目标调用数据作为响应回放至所述目标服务中。

15.根据权利要求14所述的流量回放方法，其特征在于，所述AOP代理拦截器为继承JVMSandbox并用于流量回放的增强代码。

16.根据权利要求14所述的流量回放方法，其特征在于，判断所述目标服务中的请求是否触发AOP代理拦截器的拦截操作，包括：

判断所述请求中否携带回放开关标识；及

如果所述请求携带所述回放开关标识，则触发所述AOP代理拦截器进行拦截操作。

17.根据权利要求14所述的流量回放方法，其特征在于，判断所述目标服务中的请求是否触发AOP代理拦截器的拦截操作，包括：

判断所述请求中否携带跳跃标识，其中，所述跳跃标识用于指示针对所述请求不执行流量回放操作；及

如果所述请求携带所述跳跃标识，则不触发所述AOP代理拦截器的拦截操作。

18.根据权利要求14所述的流量回放方法，其特征在于，还包括：

编辑所述目标调用数据，并将编辑后的目标调用数据作为响应回放至所述目标服务中。