Traffic playback method and device, storage medium, electronic equipment and program product

Abstract

This application discloses a traffic replay method, apparatus, storage medium, electronic device, and program product. Relating to the field of distributed systems, the method includes: receiving a first call request generated during traffic replay; obtaining a traffic tree associated with the identification information from a distributed cache based on the identification information carried in the first call request, thus obtaining a first traffic tree. The distributed cache stores M traffic trees, and each service node in the traffic tree records: a transaction identifier, a node identifier of the service node, and a parent node identifier of the service node; caching the first traffic tree in a local cache; performing traffic replay based on the local cache and the first traffic tree, and removing the called service nodes from the local cache during the traffic replay process. This application solves the problem of high error rates in related technologies that use a method of sorting service nodes by call time for traffic replay.

Description

Technical Field

[0001] This application relates to the field of distributed systems, and more specifically, to a method, apparatus, storage medium, electronic device, and program product for traffic replay. Background Technology

[0002] In related technologies, during the playback of recorded traffic, the recording platform's backend typically performs simple time-based sorting of the recorded traffic. During playback, the application container calls the backend API (Application Programming Interface), and the backend matches the resource name and returns the recorded traffic. However, when the same resource is called multiple times, in different branches, or asynchronously, mismatched traffic can easily occur, leading to low efficiency. Related technologies also use a traceId+spanId mechanism on the recording / playback platform's backend for initial traffic hierarchy positioning, combining time sorting to match the resource name and return the recorded traffic. However, obtaining recorded traffic through the recording / playback platform's backend API involves repetitive traffic lookup operations, incurs network transmission costs, is inefficient, and can easily cause playback timeouts. If the same traffic instance is played back simultaneously, traffic consumption conflicts can occur.

[0003] There is currently no effective solution to the problem of high error rates in traffic replay caused by sorting service nodes by call time in related technologies. Summary of the Invention

[0004] The main objective of this application is to provide a traffic replay method, apparatus, storage medium, electronic device, and program product to solve the problem of high error rate in traffic replay when the traffic replay is performed by sorting service nodes according to the call time in related technologies.

[0005] To achieve the above objectives, according to one aspect of this application, a traffic replay method is provided. The method includes: receiving a first invocation request generated during traffic replay; obtaining a first traffic tree from a distributed cache based on identification information carried in the first invocation request, whereby the distributed cache caches M traffic trees, each traffic tree recording traffic generated during transaction processing; each service node in the traffic tree recording a transaction identifier, a node identifier of the service node, and a parent node identifier of the service node; the parent node identifier of each service node including the node identifier associated with the parent node that calls the service node; the first invocation request including an invocation request to call a service generated during traffic replay; caching the first traffic tree in a local cache, wherein the local cache is located differently from the distributed cache; performing traffic replay based on the local cache and the first traffic tree, and removing the called service nodes from the local cache during traffic replay.

[0006] Furthermore, each of the service nodes also includes: a resource identifier. Traffic replay is performed based on the local cache and the first traffic tree, and the invoked service node is removed from the local cache during the traffic replay process. This includes: performing traffic replay based on the local cache and the first traffic tree; determining the resource identifier associated with the currently invoked service node during the traffic replay process to obtain a first resource identifier; determining the service node containing the first resource identifier in the first traffic tree to obtain a first service node; invoking the first service node; and removing the first service node from the first traffic tree in the local cache after invoking the first service node.

[0007] Furthermore, each service node also includes a simulation identifier, which indicates whether calling the service node requires simulating return information. If the simulation identifier of any service node in the first traffic tree indicates that calling the service node requires simulating return information, the service node is a leaf node of the first traffic tree. If the simulation identifier of any service node in the first traffic tree indicates that calling the service node does not require simulating return information, the service node has child service nodes. The child service node refers to the service node actively called by the service node. In the process of calling the first service node, the method further includes: if the simulation identifier of the first service node indicates that calling the first service node requires simulating return information, returning simulated information; if the simulation identifier of the first service node indicates that calling the first service node does not require simulating return information, concatenating the node identifier in the identifier information and the node identifier of the first service node to obtain a concatenated node identifier, and generating a second call request based on the concatenated node identifier, wherein the second call request is used to request the call of the child service node of the first service node.

[0008] Furthermore, the concatenated node identifier includes at least a preset separator, which is used to separate the node identifier in the identifier information and the node identifier of the first service node. After removing the first service node from the first traffic tree in the local cache, the method further includes: responding to the second call request, segmenting the concatenated node identifier based on the preset separator to obtain a segmentation result; extracting the node identifier of the first service node from the segmentation result; obtaining the first service node and all its sub-service nodes from the distributed cache based on the node identifier of the first service node and the transaction identifier in the identifier information to obtain a second traffic tree, and caching the second traffic tree in the local cache; performing traffic replay based on the local cache and the second traffic tree, and removing the called service node from the local cache during the traffic replay process.

[0009] Furthermore, each of the service nodes also includes: input and output parameters recorded during traffic recording; during traffic replay based on the local cache and the first traffic tree, it further includes: during traffic replay, collecting input and output parameters generated during service calls through pre-established stubs to obtain replay data, wherein the stubs include: plugins for collecting input and output parameters generated during service calls; comparing the replay data with the input and output parameters recorded by the service nodes in the first traffic tree to obtain a comparison result, wherein the comparison result is used to analyze whether there are any anomalies in the transactions associated with the first traffic tree.

[0010] Further, based on the identification information carried in the first call request, the traffic tree associated with the identification information is obtained from the distributed cache to obtain the first traffic tree, including: reading the transaction identifier in the identification information, the first transaction identifier; determining the traffic tree in the distributed cache containing the first transaction identifier to obtain the initial traffic tree; reading the node identifier in the identification information to obtain the first node identifier; and extracting the service node associated with the first node identifier and all its sub-service nodes from the initial traffic tree to obtain the first traffic tree.

[0011] Furthermore, before obtaining the first traffic tree by retrieving the traffic tree associated with the identification information carried in the first call request from the distributed cache, the method further includes: reading the traffic obtained by recording the traffic generated during the transaction processing from the traffic recording and playback platform to obtain the target traffic; assembling the target traffic into a traffic tree, and uploading the traffic tree to the distributed cache with the transaction identifier associated with the traffic tree as the key and the traffic tree as the value of the key-value pair.

[0012] To achieve the above objectives, according to another aspect of this application, a traffic replay apparatus is provided. The apparatus includes: a processing unit, configured to receive a first call request generated during traffic replay, and based on identification information carried in the first call request, obtain a traffic tree associated with the identification information from a distributed cache to obtain a first traffic tree, wherein the distributed cache caches M traffic trees, each traffic tree being used to record traffic generated during each transaction processing process, and each service node in the traffic tree recording: a transaction identifier, a node identifier of the service node, and a parent node identifier of the service node, the parent node identifier of each service node including: a node identifier associated with the parent node that calls the service node, and the first call request including: a call request to call a service generated during traffic replay; a caching unit, configured to cache the first traffic tree in a local cache, wherein the local cache is located differently from the distributed cache; and a replay unit, configured to perform traffic replay based on the local cache and the first traffic tree, and remove the called service nodes from the local cache during the traffic replay process.

[0013] Furthermore, each of the service nodes further includes a resource identifier. The replay unit includes: a first determining subunit, used to perform traffic replay based on the local cache and the first traffic tree, and determine the resource identifier associated with the service node currently being called during the traffic replay process to obtain a first resource identifier; a second determining subunit, used to determine the service node containing the first resource identifier in the first traffic tree to obtain a first service node; and a first processing subunit, used to call the first service node, and after calling the first service node, remove the first service node from the first traffic tree in the local cache.

[0014] Furthermore, each service node also includes: a simulation identifier, which indicates whether calling the service node requires simulating return information. If the simulation identifier of any service node in the first traffic tree indicates that calling the service node requires simulating return information, the service node is a leaf node of the first traffic tree. If the simulation identifier of any service node in the first traffic tree indicates that calling the service node does not require simulating return information, the service node has child service nodes. The child service node refers to the service node actively called by the service node. The first processing subunit also includes: a return module, which is used to return simulated information when the simulation identifier of the first service node indicates that calling the first service node requires simulating return information during the process of calling the first service node; and a processing module, which is used to concatenate the node identifier in the identifier information and the node identifier of the first service node when the simulation identifier of the first service node indicates that calling the first service node does not require simulating return information, to obtain a concatenated node identifier, and to generate a second call request based on the concatenated node identifier, wherein the second call request is used to request to call the child service node of the first service node.

[0015] Furthermore, the concatenated node identifier includes at least a preset separator, which is used to separate the node identifier in the identifier information and the node identifier of the first service node. The replay unit further includes: a segmentation subunit, which, after removing the first service node from the first traffic tree in the local cache, responds to the second call request and segments the concatenated node identifier based on the preset separator to obtain a segmentation result; an extraction subunit, which extracts the node identifier of the first service node from the segmentation result; a second processing subunit, which, based on the node identifier of the first service node and the transaction identifier in the identifier information, obtains the first service node and all its sub-service nodes from the distributed cache to obtain a second traffic tree and caches the second traffic tree in the local cache; and a third processing subunit, which performs traffic replay based on the local cache and the second traffic tree and removes the called service node from the local cache during the traffic replay process.

[0016] Furthermore, each service node also includes: input and output parameters recorded during traffic recording; the playback unit further includes: a collection subunit, used to collect input and output parameters generated during service calls through pre-established stubs during traffic playback based on the local cache and the first traffic tree, to obtain playback data, wherein the stubs include: a plugin for collecting input and output parameters generated during service calls; and a comparison subunit, used to compare the playback data with the input and output parameters recorded by the service nodes in the first traffic tree to obtain a comparison result, wherein the comparison result is used to analyze whether there are any anomalies in the transactions associated with the first traffic tree.

[0017] Further, the processing unit includes: a first reading subunit, used to read the transaction identifier in the identification information, the first transaction identifier; a determining subunit, used to determine the traffic tree containing the first transaction identifier in the distributed cache, to obtain an initial traffic tree; a second reading subunit, used to read the node identifier in the identification information, to obtain a first node identifier; and a intercepting subunit, used to intercept the service node associated with the first node identifier and all its sub-service nodes in the initial traffic tree, to obtain the first traffic tree.

[0018] Furthermore, the traffic playback device also includes: a reading unit, configured to, based on the identification information carried in the first call request, obtain the traffic tree associated with the identification information from the distributed cache, and before obtaining the first traffic tree, read the traffic recorded by the traffic recording and playback platform to obtain the target traffic; and an uploading unit, configured to assemble the target traffic into a traffic tree, and upload the traffic tree to the distributed cache with the transaction identifier associated with the traffic tree as the key and the traffic tree as the value of the key-value pair.

[0019] According to another aspect of this application, a computer-readable storage medium is provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is executed, it controls the device where the computer-readable storage medium is located to perform the traffic playback method.

[0020] According to another aspect of this application, an electronic device is provided, comprising: a memory storing an executable program; and a processor for running the program, wherein the program executes the traffic playback method during runtime.

[0021] According to another aspect of this application, a computer program product is provided, including computer instructions that, when executed by a processor, implement the steps of the traffic playback method.

[0022] In this embodiment, a first call request generated during traffic replay is received. Based on the identification information carried in the first call request, a traffic tree associated with the identification information is obtained from the distributed cache to obtain a first traffic tree. The distributed cache caches M traffic trees, which are used to record the traffic generated during each transaction processing. Each service node in the traffic tree records a transaction identifier, a node identifier of the service node, and a parent node identifier of the service node. The parent node identifier of each service node includes the node identifier associated with the parent node that calls the service node. The first call request includes a call request to call the service generated during traffic replay. The first traffic tree is cached in a local cache, where the local cache and the distributed cache are located in different places. Traffic replay is performed based on the local cache and the first traffic tree, and the called service nodes are removed from the local cache during traffic replay. This solves the technical problem of high error rate in traffic replay caused by sorting service nodes by call time in related technologies.

[0023] In this invention, the corresponding traffic tree is obtained from the distributed cache based on the identification information of the call request, and the traffic tree is cached in the local cache for traffic replay. This avoids the method of sorting service nodes by call time in related technologies for traffic replay. When the same service node is called multiple times, in different branches, or in asynchronous scenarios, it is easy to encounter the situation of mismatched traffic, thereby achieving the technical effect of improving the accuracy of traffic replay. Attached Figure Description

[0024] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings:

[0025] Figure 1 A hardware structure block diagram of a computer terminal for implementing a traffic playback method is shown.

[0026] Figure 2 This is a flowchart of the traffic replay method provided according to the embodiments of this application;

[0027] Figure 3 This is a structural diagram of a traffic playback system provided according to an embodiment of this application;

[0028] Figure 4 This is a service call chain diagram provided according to the embodiments of this application;

[0029] Figure 5 This is a service call chain diagram including stubs provided according to the embodiments of this application;

[0030] Figure 6 This is a schematic diagram of a traffic playback device provided according to an embodiment of this application;

[0031] Figure 7 This is a structural block diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0032] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0033] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0034] First, some nouns or terms that appear in the description of the embodiments of this application shall be interpreted as follows:

[0035] Mock: Simulation, that is, simulating the information returned by an interface and replacing the information it needs to return with existing information. For example, for certain unstable, difficult-to-construct, or incomplete object interfaces, pre-set mock data can be returned to enable testing.

[0036] traceId: Transaction identifier. In a single transaction, the traceId of all service nodes is consistent and unique, meaning that a specific transaction can be located through the traceId.

[0037] spanId, the service node identifier. In a transaction, each service node that is invoked will generate a spanId, which is equivalent to a unique identifier for each service node in this transaction.

[0038] `parentSpanId`: The spanId of the parent node of the current service node. This allows us to construct the call tree graph for this transaction using `traceId`, `spanId`, and `parentSpanId`. Note that the `parentSpanId` of the first node is empty because it has no parent node.

[0039] Traffic: In traffic recording and playback, traffic mainly refers to the input and output messages and other additional information generated by calls between service nodes.

[0040] Traffic recording and playback: Traffic recording involves persistently saving the input and output packets and additional information of each service node to a database during normal transactions. During playback, the same transaction is initiated, but certain flags are used to declare that this is a replay transaction. When encountering certain service nodes that require mocking, the recorded traffic output is returned without any actual service node calls.

[0041] It should be noted that the information collected in this application (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for display, data used for analysis, etc.) are information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of this data all comply with relevant laws, regulations, and standards, necessary confidentiality measures have been taken, and they do not violate public order and good morals. Corresponding access points are provided for users to choose to authorize or refuse. For example, interfaces are set up between this system and relevant users or organizations, providing users with corresponding access points to choose to agree to or refuse automated decision-making results; if the user chooses to refuse, the process proceeds to the expert decision-making stage.

[0042] Example 1

[0043] According to an embodiment of this application, a method embodiment of a traffic replay method is also provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0044] The method embodiment provided in Embodiment 1 of this application can be executed in a mobile terminal, computer terminal or similar computing device. Figure 1 A hardware block diagram of a computer terminal (or mobile device) for implementing a traffic replay method is shown. Figure 1 As shown, the computer terminal 10 (or mobile device) may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0045] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits can be implemented wholly or partially as software, hardware, firmware, or any other combination. Furthermore, the data processing circuits can be a single, independent processing module, or wholly or partially integrated into any other element in the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuit serves as a processor control (e.g., selection of a variable resistor terminal path connected to an interface). The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the traffic playback method in the embodiments of this application. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby implementing the aforementioned traffic playback method. The memory 104 may include high-speed random access memory and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, which can be connected to the computer terminal 10 via a network. Examples of the aforementioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. The transmission device 106 is used to receive or send data via a network. Specific examples of the aforementioned networks may include wireless networks provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In one example, the transmission device 106 may be a Radio Frequency (RF) module for wireless communication with the Internet. The display may be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 10 (or mobile device).

[0046] Under the aforementioned operating environment, this application provides the following: Figure 2 The traffic replay method shown. Figure 2 This is a flowchart of the traffic replay method according to Embodiment 1 of this application.

[0047] Step S201: Receive the first call request generated during the traffic replay process. Based on the identification information carried in the first call request, obtain the traffic tree associated with the identification information from the distributed cache to obtain the first traffic tree. The distributed cache caches M traffic trees. The traffic trees are used to record the traffic generated during the transaction processing process of each transaction. Each service node in the traffic tree records: transaction identifier, node identifier of the service node, and parent node identifier of the service node. The parent node identifier of each service node includes: the node identifier associated with the parent node that calls the service node. The first call request includes: a call request to call the service generated during the traffic replay process.

[0048] The first call request mentioned above may include: a call request to invoke a service generated during the traffic replay process, such as a call request from the traffic recording and playback platform to invoke the first node (root service node) of the traffic tree of a transaction. The request context of the first call request may include a replay identifier, a replay result ID, a recorded traceId (i.e., transaction identifier), and spanIdLink (spanId of the first node (node ​​identifier)). For example, if the context of the first call request shows a replay flag, it indicates that it is an external call to itself, so traffic initialization is required. (Determining whether it is an external call to itself can be done through stub type or context. For example, in the Dubbo (distributed service framework) plugin, the remote procedure call proxy abstract caller can intercept the called request, or it can be determined from the address information of the remote peer (remote caller). Then, the recorded traceId (transaction identifier) ​​can be obtained from the context of the first call request. Then, the caching utility class is called to read the traffic tree JSON corresponding to the traceId from the distributed cache. After that, the traffic tree level is located based on the spanIdLink of the context of the first call request. The obtained current level traffic tree is the first traffic tree.)

[0049] Step S202: Cache the first traffic tree in the local cache, where the local cache and the distributed cache are located in different places.

[0050] In this embodiment, the first traffic tree can be cached in a local cache container memory to avoid traffic consumption conflicts caused by multiple replays of the same case and synchronous calls of multiple services; at the same time, it can also reduce traffic level matching, traffic node matching and network transmission consumption.

[0051] Step S203: Perform traffic replay based on the local cache and the first traffic tree, and remove the called service nodes from the local cache during the traffic replay process.

[0052] In this embodiment, traffic replay can be performed based on the local cache and the first traffic tree. After a successful match, the traffic node can be removed from the local cache of the current level traffic tree, thus avoiding the problem of multiple matches when the same node is called repeatedly.

[0053] In this embodiment, through the above steps, the corresponding traffic tree is obtained from the distributed cache based on the identifier information of the call request, and the traffic tree is cached in the local cache for traffic replay. This avoids the problem in related technologies where service nodes are sorted by call time for traffic replay. In such cases, multiple calls to the same service node, different branches, or asynchronous calls can easily lead to mismatched traffic, thus improving the accuracy of traffic replay. This solves the technical problem of high error rates in traffic replay when using methods that sort service nodes by call time for traffic replay.

[0054] Figure 3 This is a structural diagram of the traffic playback system provided in the embodiments of this application, such as... Figure 3 As shown, the process includes: 1. The user triggers traffic playback to the recording and playback platform backend; 2. The recording and playback platform backend uploads the recorded traffic to the distributed cache, reads the recorded traffic from the recording and playback platform's database, assembles the recorded traffic into a JSON-formatted traffic tree, sorts it by the recording start timestamp, and then uploads it to the distributed cache, with the key being the traceId of the recorded traffic; 3. The recording and playback platform backend initiates a first-node playback call; 4. Application container 1 reads the recorded traffic from the distributed cache; 5. Container 1 calls the service of container 2; 6. Application container 2 reads the recorded traffic from the distributed cache; 7. The first-node playback output is returned.

[0055] Figure 4 This is a service call chain diagram provided according to the embodiments of this application, such as... Figure 4 As shown, the first node is service 1 of container 1; service 1 calls database operation 3 of container 1 and service 2 of container 2; service 2 of container 2 calls database operation 4 of container 2. Figure 5 This is a service call chain diagram including stubs provided according to the embodiments of this application, such as... Figure 5 As shown, the nodes enclosed by the rectangles all deploy the code of the containers within those rectangles. When Service 1 calls Service 2, it passes through two Dubbo stubs. The mock actions all occur when other service nodes are called, for example... Figure 5 Two database stubs and a Dubbo stub when service 1 calls service 2.

[0056] In this embodiment, with Figure 5 Taking the traffic tree corresponding to the service call chain shown as an example, the process of traffic replay will be explained. Figure 5The traffic tree corresponding to the service call chain shown is as follows:

[0057]

[0058]

[0059]

[0060] Based on the information of the first node, the backend of the recording and playback platform initiates a service call (first call request) to the playback environment. At this time, the context of the first call request can include the playback identifier, playback result ID, recording traceId, and spanIdLink (spanId of the first node).

[0061] In the example of the traffic tree provided in this embodiment:

[0062] Recorded traceId: 650828fdaaaaaaaaaaaaaaa54ed0037;

[0063] spanIdLink:6bfe5ccccccc0037.

[0064] Container 1 Service 1 receives a service call request and finds that the request context contains a replay identifier, indicating that mock processing is required. It retrieves the recorded traffic from the distributed cache based on the recorded traceId. Container 1 Service 1 then performs mock processing based on the retrieved traffic and the actual sub-calls that occurred during the replay, finally returning the service call result. Container 2 Service 2's processing logic is basically the same as Service 1, except that the caller changes from the recording and playback platform to Service 1. The following example of the traffic tree above will explain in detail what specific operations occur in Container 1 Service 1 and Container 2 Service 2.

[0065] 1. Specific operations of container 1:

[0066] (1) Container 1 receives the call request from Service 1. The request is captured by the Dubbo framework plugin. The context shows that it has a replay flag, indicating that it is an external call to itself. Therefore, traffic initialization is required. (Whether it is an external call to itself can be determined by the stub type or context. For example, the Dubbo framework plugin can intercept the called request in com.alibaba.dubbo.rpc.proxy.AbstractProxyInvoker, or it can be determined from the RpcContext.attachments.remotePeer value).

[0067] (2) Traffic initialization: First, obtain the recorded traceId from the context, and then call the caching utility class to read the traffic tree JSON corresponding to the traceId from the distributed cache;

[0068] (3) Locate the traffic tree level based on the spanIdLink in the context. At this time, spanIdLink = 6bfe5cccccccc0037, which corresponds to the spanId of the first node service 1. Therefore, the obtained current level traffic tree 1 is the subInvocations of the first node:

[0069]

[0070]

[0071] (4) Encapsulate the recorded traceId, spanIdLink, replay result ID, and current level traffic tree into a mockContext object, and then call the public method MockContextHolder.set(mockContext) (a method in the traffic replay system for managing and configuring simulation data and configuration information related to service calls) to complete local traffic caching. The MockContextHolder.set method first obtains the replay spanId of the current node and sets it as the key in a ConcurrentMap type Map object. It should be noted that using the replay spanId as the key is to solve the problem of traffic caching and consumption anomalies caused by key value conflicts in scenarios such as simultaneous replay of the same case or simultaneous calls to a container by the same case. The Map object can be declared as a ConcurrentMap.<String,MockContext> CURRENT_MOCK_CONTEXT (a concurrent mapping table used to store simulation context information of the current replay case in traffic replay or simulation test scenarios) uses the ConcurrentMap type (used to cache and manage simulation context information during replay in traffic replay technology) to solve problems such as deadlock and dirty reads that may occur in multi-threaded environments.

[0072] Optionally, each service node further includes: a resource identifier. Traffic replay is performed based on the local cache and the first traffic tree, and the invoked service node is removed from the local cache during the traffic replay process. This includes: performing traffic replay based on the local cache and the first traffic tree; determining the resource identifier associated with the service node invoked at the current moment during the traffic replay process to obtain the first resource identifier; determining the service node containing the first resource identifier in the first traffic tree to obtain the first service node; invoking the first service node; and removing the first service node from the first traffic tree in the local cache after invoking the first service node.

[0073] Taking the record traceId (transaction identifier) ​​of the first traffic tree as an example: 650828fdaaaaaaaaaaaaaaa54ed0037, spanIdLink: 6bfe5ccccccc0037, we will illustrate this example.

[0074] (1) Since service 1 does not need mocking, it begins executing its own logic. Service 1 first calls database operation 3;

[0075] (2) The database plugin stub intercepts the call to operation 3 and calls the MockContextHolder.getByCurrSpanId() method (a method used to obtain Mock data related to the current service call), obtains the current replay spanId, and gets the mockContext (simulated context) cached locally. Since the database plugin's newSpanId function has not been called yet, the current replay spanId is still the spanId used when the first node initializes the mockContext.

[0076] (3) Traverse the current level traffic tree 1 (corresponding to the first traffic tree) and find the first node whose recorded resource name (i.e., resource identifier) ​​matches the currently invoked resource name; here, the resource name is database operation 3, so the recorded traffic node (corresponding to the first service node) obtained is:

[0077]

[0078] (4) Remove the successfully matched node (or the node called during traffic replay, i.e., the first service node) from the current level traffic tree 1 to avoid the problem of traffic reuse caused by the possibility of calling database operation 3 again in the future, and reduce the number of times traffic is repeatedly matched; the current level traffic tree 1 becomes:

[0079]

[0080]

[0081] After calling the first service node, the first service node is removed from the locally cached first traffic tree to avoid the problem of traffic reuse caused by the first service node being called again in the future, and to reduce the number of times traffic is repeatedly matched.

[0082] Optionally, in the traffic replay method provided in this application embodiment, each service node further includes: a simulation identifier, which is used to indicate whether calling the service node requires simulating return information. If the simulation identifier of any service node in the first traffic tree indicates that calling the service node requires simulating return information, the service node is a leaf node of the first traffic tree. If the simulation identifier of any service node in the first traffic tree indicates that calling the service node does not require simulating return information, the service node has a child service node. The child service node refers to the service node actively called by the service node. In the process of calling the first service node, the method further includes: if the simulation identifier of the first service node indicates that calling the first service node requires simulating return information, returning simulated information; if the simulation identifier of the first service node indicates that calling the first service node does not require simulating return information, concatenating the node identifier in the identifier information and the node identifier of the first service node to obtain a concatenated node identifier, and generating a second call request based on the concatenated node identifier, wherein the second call request is used to request the call of the child service node of the first service node.

[0083] For example, the value of needMock (corresponding to the simulation identifier) ​​in the traffic node (i.e., service node) of database operation 3 is true, indicating that mocking is required. The return value of database operation 3 is set to the responseRecord value of the recorded traffic (corresponding to the simulation information), skipping the actual execution of database operation 3 and directly returning the mock value. Before returning the mock value of database operation 3, the actual input parameters and mock status of this database operation 3 can be packaged into a queue message and pushed to the recording and playback platform for comparison. After service 1 obtains the return (Mock) of database operation 3, it continues execution, invoking service 2 (Dubbo type container 2). The Dubbo plugin stub of container 1 intercepts the call to service 2. The MockContext is obtained through the current playback spanId, and the recorded traffic of service 2 is found by traversing the current level traffic tree 1.

[0084]

[0085]

[0086] Remove the traffic node of service 2 from the current level traffic tree 1, and the current level traffic tree 1 becomes an empty array;

[0087] The value of needMock in the traffic node of service 2 is false, indicating that mock is not needed. Update the spanIdLink in the context and concatenate the recorded spanId of service 2. At this time, spanIdLink changes from 6bfe5ccccccc0037 with only the spanId of the first node to 6bfe5ccccccc0037 &&ed8bbbbbbbbb3f1c with the spanId of the first node concatenated with the spanId of service 2 (corresponding to the concatenated node identifier); (&& is used as a separator to facilitate subsequent segmentation, it does not have to be used, as long as it is easy to distinguish).

[0088] Initiate the actual call request for Service 2 (corresponding to the second call request), and then set the return of Service 2 to replay the return message obtained from the actual call;

[0089] The actual input messages, actual output messages, mock status, and other information of Service 2 are packaged into a queue message and pushed to the recording and playback platform for comparison and processing to analyze whether there are any anomalies in the transaction.

[0090] After Service 1 receives the actual call return from Service 2, all logic processing in Service 1 ends, and the `MockContextHolder.remove()` method (a method used to clean up the mock data context related to the current service call) is called. This removes the cached local traffic mockContext from `CURRENT_MOCK_CONTEXT` (the current mock context) (i.e., removes the first traffic tree from the local cache). Before calling the next level node, the recording spanId of the current node is concatenated to `spanIdLink`. This concatenates the node identifier in the identification information with the node identifier of the first service node, effectively caching the current replay traffic level. This reduces the number of traffic matching attempts and improves traffic replay efficiency.

[0091] Optionally, the concatenated node identifier includes at least a preset separator, which is used to separate the node identifier in the identifier information from the node identifier of the first service node. After removing the first service node from the first traffic tree in the local cache, the method further includes: responding to the second call request, dividing the concatenated node identifier based on the preset separator to obtain a division result; extracting the node identifier of the first service node from the division result; obtaining the first service node and all its child service nodes from the distributed cache based on the node identifier of the first service node and the transaction identifier in the identifier information to obtain a second traffic tree, and caching the second traffic tree in the local cache; performing traffic replay based on the local cache and the second traffic tree, and removing the called service node from the local cache during the traffic replay process. The following uses the specific operation of container 2 as an example for illustration:

[0092] (1) Container 2 receives the call request from Service 2. The request is captured by the Dubbo framework plugin. From the context of the second call request, it is found that there is a replay identifier, and it is determined that it is an external call to itself, so traffic initialization is required.

[0093] (2) Traffic initialization: First, obtain the recorded traceId from the context, and then call the caching utility class to read the traffic tree JSON corresponding to the traceId from the distributed cache;

[0094] (3) Locate the traffic tree level based on the spanIdLink in the context. At this time, the spanIdLink value is 6bfe5cccccccc0037&&ed8bbbbbbbb3f1c. Cut the spanIdLink by && (corresponding to the preset delimiter), first get the subInvocations corresponding to the first spanId, which is the subInvocations of service 1; then look for the subInvocations of the second spanId in the subInvocations of service 1, which is the subInvocations of service 2; so the obtained current level traffic tree 2 (corresponding to the second traffic tree) is the subInvocations of service 2;

[0095]

[0096] (4) Encapsulate the recorded traceId, spanIdLink, playback result ID, and current level traffic tree 2 into a MockContext object, and then call the public method MockContextHolder.set(mockContext) to complete local traffic caching. Then, service 2 calls database operation 4. The database plugin stub intercepts the call to operation 4, traverses the current level traffic tree 2, and finds the first node whose recorded resource name matches the currently called resource name; here, the resource name is database operation 4, so the recorded traffic node obtained is:

[0097]

[0098]

[0099] (5) Remove the successfully matched node database operation 4 from the current level traffic tree 2;

[0100] (6) The value of needMock in the traffic node of database operation 4 is true, which means that mock is needed; set the return of database operation 4 to the responseRecord value of the recorded traffic, skip the actual execution of database operation 4, and directly return the mock value;

[0101] (7) Before returning the mock value of database operation 4, package the actual input parameters, mock status and other information of this database operation 4 into a queue message and push it to the recording and playback platform for comparison processing.

[0102] (8) After Service 2 obtains the return (mock) of Database Operation 4, it ends the logic processing, removes the local cached mockContext, and returns the output message of Service 2.

[0103] In this embodiment, the next-layer node calls the data to replay the traffic based on the recorded spanId of the current node to spanIdLink, thus avoiding traffic matching errors and achieving the technical effect of reducing the error rate of traffic replay.

[0104] Optionally, each service node also includes: input and output parameters recorded during traffic recording; during traffic replay based on local caching and the first traffic tree, it further includes: during traffic replay, collecting input and output parameters generated during service calls through pre-established stubs to obtain replay data, wherein the stubs include: plugins for collecting input and output parameters generated during service calls; comparing the replay data with the input and output parameters recorded by the service nodes in the first traffic tree to obtain comparison results, wherein the comparison results are used to analyze whether there are any anomalies in the transactions associated with the first traffic tree.

[0105] like Figure 5 As shown in this embodiment, corresponding plugins can be created according to the framework that needs to be monitored. The plugin can declare which methods need to be stubbed, and the stubbed methods will record their input and output parameters. For example, if it is necessary to record calls to Dubbo services, a Dubbo plugin can be created, with the stub declared as xx.dubbo.monitor.support.MonitorFilter (Dubbo filter). The stub is not unique; it just needs to be passed through by all service calls. For example, if a traffic monitoring station needs to be built on a highway, the monitoring station should be built at a location that vehicles definitely pass through on the highway, not on ramps or non-highway urban roads.

[0106] When Service 1 calls Service 2, it passes through two Dubbo stubs. This is because both Service 1's invocation of Service 2 and Service 2's receipt of Service 1's call are through the Dubbo framework's API and both pass through the MonitorFilter stub. Traffic initialization occurs when a service is invoked; for example, traffic initialization is performed at the first Dubbo stub before Service 1 and before Service 2. Mock actions occur when other service nodes are invoked, such as the two database stubs and the Dubbo stub when Service 1 invokes Service 2. In this embodiment, the replay data can be compared with the input and output parameters recorded in the traffic recording to obtain the comparison result. Based on the differences between the replay data and the data recorded during the traffic recording process, it can be determined whether there are any anomalies in the transaction, such as whether the transaction has errors, thus achieving the purpose of accurately verifying whether anomalies have occurred in the transaction.

[0107] Optionally, in the traffic replay method provided in this application embodiment, based on the identification information carried in the first call request, the traffic tree associated with the identification information is obtained from the distributed cache to obtain the first traffic tree, including: reading the transaction identifier in the identification information, the first transaction identifier; determining the traffic tree in the distributed cache containing the first transaction identifier to obtain the initial traffic tree; reading the node identifier in the identification information to obtain the first node identifier; and extracting the service node associated with the first node identifier and all its sub-service nodes from the initial traffic tree to obtain the first traffic tree.

[0108] In this embodiment, the recorded traceId (corresponding to the first transaction identifier) ​​can first be obtained from the context of the first call request. Then, the caching utility class is called to read the traffic tree JSON corresponding to the traceId from the distributed cache. The traffic tree level is located based on the spanIdLink of the context (corresponding to the first node identifier). At this time, spanIdlink = 6bfe5cccccccc0037, which corresponds to the spanId of the first node service 1. Therefore, the obtained current level traffic tree 1 (corresponding to the first traffic tree) is the subInvocations of the first node.

[0109]

[0110]

[0111] The recorded traceId, spanIdLink, playback result ID, and current traffic tree are encapsulated into a MockContext object. Then, the public method MockContextHolder.set(mockContext) is called to complete local traffic caching. The MockContextHolder.set method first obtains the playback spanId of the current node and sets it in a ConcurrentMap object using the playback spanId as the key. By locating the traffic level using traceId and spanId, the corresponding traffic tree for the call request is obtained, achieving the technical effect of traffic localization.

[0112] Optionally, in the traffic replay method provided in this application embodiment, before obtaining the traffic tree associated with the identifier information from the distributed cache based on the identifier information carried in the first call request, the method further includes: reading the traffic obtained by recording the traffic generated during the transaction processing from the traffic recording and playback platform to obtain the target traffic; assembling the target traffic into a traffic tree, and uploading the traffic tree to the distributed cache with the transaction identifier associated with the traffic tree as the key and the traffic tree as the value of the key-value pair.

[0113] For example, such as Figure 3 As shown, users can select the traffic case they want to replay on the recording and playback platform's web interface, triggering immediate or scheduled replay. Upon receiving the replay request, the platform first reads the recorded traffic from its database, then assembles the recorded traffic into a JSON-formatted traffic tree, sorts it by the recording start timestamp, and uploads it to a distributed cache. The key is the recorded traffic's traceId (transaction identifier), and the value is the traffic tree. Caches the recorded traffic in the distributed cache using the recorded traceId as the key, facilitating retrieval by various containers and improving the efficiency of traffic replay.

[0114] In this embodiment, the recorded traceId+spanIdLink mechanism is used to cache the recorded traffic to a distributed cache using the recorded traceId as the key, which facilitates reading by various containers. The recorded traceId and spanIdLink are passed through the context, which ensures that the recorded traffic obtained by each container and node through the replay is consistent. Before calling the next level node, the recorded spanId of the current node is concatenated to the spanIdLink, which is equivalent to caching the current replay traffic level and reducing the number of traffic matching operations.

[0115] In this embodiment, the local cache and the spanId of the playback parent node are used as the key. Local traffic caching is initialized when a node is invoked (e.g., the recording / playback platform invokes service 1, and service 1 invokes service 2). Caching traffic locally reduces network transmission consumption. The traffic node in the current level of the local cache is removed after a successful match, preventing multiple matches when the same node is repeatedly invoked. Using the spanId of the parent node (entry node, such as service 1 or service 2) during playback as the cache key avoids traffic consumption conflicts (using the recording traceId as the key and the recording spanId as the key). Simultaneous replay of the same case will cause conflicts; replay traceID: synchronous calls from multiple services in the same container will cause conflicts; local caching is performed using the parent node's spanId as the key during replay. Before calling newSpanId, the child node (i.e., the child service node) first obtains the current spanId; since newSpanId has not yet been called, the current spanId obtained by the child node is still the parent node's replay spanId; therefore, the local traffic cache obtained by the child node through the current spanId and the local cache written by the parent node are the same, thus realizing traffic sharing between parent and child nodes, and between sibling child nodes.

[0116] In this embodiment, traffic levels are located using traceId+spanId, and combined with timestamp sorting and resource name matching, normal replays can match the correct traffic 100% of the time. Traffic is cached in container memory using the current replay's spanId, which avoids traffic consumption conflicts caused by multiple replays of the same case or simultaneous calls to multiple services. It also reduces traffic level matching, traffic node matching, and network transmission overhead, making mock efficiency significantly higher than the backend API method. spanIdLink is equivalent to caching the traffic level of the current replay, which can reduce the number of traffic matching attempts. The parent node initializes the local traffic cache after calling newSpanId, and the child node obtains the local traffic cache before calling newSpanId, which solves the problem of traffic sharing between parent and child nodes and sibling nodes.

[0117] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0118] Example 2

[0119] This application also provides a traffic playback device. It should be noted that the traffic playback device of this application can be used to execute the traffic playback method provided in this application. The traffic playback device provided in this application is described below.

[0120] According to an embodiment of this application, an apparatus for implementing the above-described traffic playback method is also provided. Figure 6 This is a schematic diagram of a traffic playback device provided according to an embodiment of this application, such as... Figure 6 As shown, the device includes a processing unit 61, a buffer unit 62, and a playback unit 63.

[0121] In the traffic replay apparatus provided in this application embodiment, the processing unit 61 is used to receive a first call request generated during the traffic replay process, and obtain a traffic tree associated with the identifier information from the distributed cache based on the identifier information carried in the first call request, thereby obtaining a first traffic tree. The distributed cache caches M traffic trees, which record the traffic generated during each transaction processing. Each service node in the traffic tree records a transaction identifier, a node identifier of the service node, and a parent node identifier of the service node. The parent node identifier of each service node includes the node identifier associated with the parent node that calls the service node. The first call request includes a call request to invoke the service generated during the traffic replay process. The caching unit 62 is used to cache the first traffic tree in a local cache, wherein the local cache and the distributed cache are located in different places. The replay unit 63 is used to perform traffic replay based on the local cache and the first traffic tree, and remove the invoked service nodes from the local cache during the traffic replay process. This solves the technical problem of high error rates in traffic replay caused by sorting service nodes by call time in related technologies. In this embodiment, the corresponding traffic tree is obtained from the distributed cache according to the identification information of the call request, and the traffic tree is cached in the local cache for traffic replay. This avoids the method of sorting service nodes by call time in related technologies for traffic replay. When the same service node is called multiple times, in different branches, or in asynchronous scenarios, it is easy to encounter the situation of mismatched traffic, thereby achieving the technical effect of improving the accuracy of traffic replay.

[0122] Optionally, in the traffic replay apparatus provided in this application embodiment, each service node further includes: a resource identifier; the replay unit includes: a first determining subunit, used to perform traffic replay based on local cache and a first traffic tree, and determine the resource identifier associated with the service node currently being called during the traffic replay process to obtain a first resource identifier; a second determining subunit, used to determine the service node containing the first resource identifier in the first traffic tree to obtain a first service node; and a first processing subunit, used to call the first service node, and after calling the first service node, remove the first service node from the locally cached first traffic tree.

[0123] Optionally, in the traffic replay device provided in this application embodiment, each service node further includes: a simulation identifier, which is used to indicate whether calling the service node requires simulating return information. When the simulation identifier of any service node in the first traffic tree indicates that calling the service node requires simulating return information, the service node is a leaf node of the first traffic tree. When the simulation identifier of any service node in the first traffic tree indicates that calling the service node does not require simulating return information, the service node has a sub-service node. The sub-service node refers to the service node actively called by the service node. The first processing sub-unit further includes: a return module, which is used to return simulated information when the simulation identifier of the first service node indicates that calling the first service node requires simulating return information during the process of calling the first service node; and a processing module, which is used to concatenate the node identifier in the identifier information and the node identifier of the first service node when the simulation identifier of the first service node indicates that calling the first service node does not require simulating return information, to obtain a concatenated node identifier, and generate a second call request based on the concatenated node identifier, wherein the second call request is used to request to call the sub-service node of the first service node.

[0124] Optionally, in the traffic replay apparatus provided in this application embodiment, the concatenated node identifier includes at least a preset separator, which is used to separate the node identifier in the identifier information and the node identifier of the first service node. The replay unit further includes: a segmentation subunit, which, after removing the first service node from the first traffic tree in the local cache, responds to the second call request and segments the concatenated node identifier based on the preset separator to obtain a segmentation result; an extraction subunit, which extracts the node identifier of the first service node from the segmentation result; a second processing subunit, which, based on the node identifier of the first service node and the transaction identifier in the identifier information, obtains the first service node and all its sub-service nodes from the distributed cache to obtain a second traffic tree and caches the second traffic tree in the local cache; and a third processing subunit, which performs traffic replay based on the local cache and the second traffic tree and removes the called service node from the local cache during the traffic replay process.

[0125] Optionally, in the traffic replay device provided in this application embodiment, each service node further includes: input and output parameters recorded during traffic recording; the replay unit further includes: a collection subunit, used to collect input and output parameters generated during service calls through pre-established stubs during traffic replay based on local cache and the first traffic tree, to obtain replay data, wherein the stubs include: a plug-in for collecting input and output parameters generated during service calls; and a comparison subunit, used to compare the replay data with the input and output parameters recorded by the service nodes in the first traffic tree to obtain a comparison result, wherein the comparison result is used to analyze whether there are any anomalies in the transactions associated with the first traffic tree.

[0126] Optionally, in the traffic replay apparatus provided in this application embodiment, the processing unit includes: a first reading subunit, used to read the transaction identifier in the identification information, the first transaction identifier; a determining subunit, used to determine the traffic tree containing the first transaction identifier in the distributed cache, and obtain an initial traffic tree; a second reading subunit, used to read the node identifier in the identification information, and obtain a first node identifier; and a interception subunit, used to intercept the service node associated with the first node identifier and all sub-service nodes of the service node in the initial traffic tree, and obtain the first traffic tree.

[0127] Optionally, in the traffic playback device provided in the embodiments of this application, the traffic playback device further includes: a reading unit, used to obtain the traffic tree associated with the identification information from the distributed cache based on the identification information carried in the first call request, and before obtaining the first traffic tree, read the traffic recorded by the traffic recording and playback platform to obtain the target traffic; and an uploading unit, used to assemble the target traffic into a traffic tree, and upload the traffic tree to the distributed cache with the transaction identifier associated with the traffic tree as the key and the traffic tree as the value of the key-value pair.

[0128] It should be noted that the processing unit 61, cache unit 62, and playback unit 63 mentioned above correspond to steps S201 to S203 in Embodiment 1. The two modules and the corresponding steps implement the same instances and application scenarios, but are not limited to the content disclosed in Embodiment 1. It should be noted that the above modules or units can be hardware or software components stored in memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The above modules can also be part of the device and run in the computer terminal 10 provided in Embodiment 1.

[0129] Example 3

[0130] Embodiments of this application may provide an electronic device. Figure 7This is a structural block diagram of an electronic device according to an embodiment of this application. Figure 7 As shown, the electronic device may include: one or more ( Figure 7 (Only one is shown) a processor 702, a memory 704, a storage controller, and a peripheral interface, wherein the peripheral interface is connected to the radio frequency module, the audio module, and the display. The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the methods and apparatus in this embodiment. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby implementing the aforementioned methods. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof. The processor can call the information and application programs stored in the memory through a transmission device to execute the traffic playback method provided in Embodiment 1 of this invention.

[0131] This application provides a traffic replay scheme. Based on the identifier information of the call request, the corresponding traffic tree is retrieved from the distributed cache and cached locally for traffic replay. This avoids the problem of mismatched traffic when the same service node is called multiple times, on different branches, or asynchronously in related technologies, as this can easily lead to such calls. This improves the accuracy of traffic replay. Furthermore, it solves the technical problem of high error rates in traffic replay when using methods that sort service nodes by call time.

[0132] Those skilled in the art will understand that Figure 7 The structure shown is for illustrative purposes only. Electronic devices can also be smartphones, tablets, handheld computers, mobile internet devices (MIDs), PADs, and other terminal devices. Figure 7 This does not limit the structure of the aforementioned electronic device. For example, electronic devices may also include components that are more... Figure 7 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 7 The different configurations shown.

[0133] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0134] Example 4

[0135] Embodiments of this application also provide a storage medium. Optionally, in this embodiment, the storage medium can be used to store the program code executed by the traffic playback method provided in Embodiment 1. Optionally, in this embodiment, the storage medium can be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.

[0136] This application also provides a computer program product that, when executed on a data processing device, is adapted to perform the steps of a traffic replay method.

[0137] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0138] In the above embodiments of this application, the descriptions of each embodiment have their own emphasis. Parts not described in detail in a certain embodiment can be referred to in the relevant descriptions of other embodiments. It should be understood that the disclosed technical content can be implemented in other ways in the several embodiments provided in this application. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling or direct coupling or communication connection may be through some interfaces, or the indirect coupling or communication connection of units or modules may be electrical or other forms.

[0139] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, the functional units in the various embodiments of this application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The integrated units described above can be implemented in hardware or as software functional units.

[0140] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0141] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for playback of streaming data, characterized in that, include: The system receives a first call request generated during traffic replay. Based on the identification information carried in the first call request, it retrieves the traffic tree associated with the identification information from the distributed cache to obtain a first traffic tree. The distributed cache caches M traffic trees, which are used to record the traffic generated during each transaction processing. Each service node in the traffic tree records a transaction identifier, a node identifier of the service node, and a parent node identifier of the service node. The parent node identifier of each service node includes the node identifier associated with the parent node that calls the service node. The first call request includes a call request to invoke the service generated during traffic replay. The first traffic tree is cached in a local cache, wherein the local cache is located in a different place than the distributed cache; Traffic replay is performed based on the local cache and the first traffic tree, and the invoked service nodes are removed from the local cache during the traffic replay process.

2. The traffic playback method according to claim 1, characterized in that, Each of the service nodes further includes: a resource identifier, performing traffic replay based on the local cache and the first traffic tree, and removing the invoked service node from the local cache during the traffic replay process, including: Based on the local cache and the first traffic tree, traffic replay is performed. During the traffic replay process, the resource identifier associated with the service node called at the current moment is determined to obtain the first resource identifier. In the first traffic tree, a service node containing the first resource identifier is determined to obtain the first service node; Invoke the first service node, and after invoking the first service node, remove the first service node from the first traffic tree cached locally.

3. The traffic playback method according to claim 2, characterized in that, Each service node further includes: a simulation identifier, which indicates whether calling the service node requires simulating a return message. If the simulation identifier of any service node in the first traffic tree indicates that calling the service node requires simulating a return message, then that service node is a leaf node of the first traffic tree. If the simulation identifier of any service node in the first traffic tree indicates that calling the service node does not require simulating a return message, then that service node has child service nodes. The child service nodes are service nodes actively called by the service node. The process of calling the first service node also includes: If the simulation identifier of the first service node indicates that calling the first service node requires simulation return information, then return the simulation information; When the simulated identifier of the first service node indicates that calling the first service node does not require simulated return information, the node identifier in the identifier information and the node identifier of the first service node are concatenated to obtain the concatenated node identifier, and a second call request is generated based on the concatenated node identifier, wherein the second call request is used to request a call to the sub-service node of the first service node.

4. The traffic playback method according to claim 3, characterized in that, The concatenated node identifier includes at least: a preset separator, which is used to separate the node identifier in the identifier information from the node identifier of the first service node. After removing the first service node from the first traffic tree in the local cache, it also includes: In response to the second call request, the concatenated node identifier is segmented based on the preset delimiter to obtain the segmentation result; Extract the node identifier of the first service node from the segmentation result; Based on the node identifier of the first service node and the transaction identifier in the identifier information, the first service node and all its sub-service nodes are obtained from the distributed cache to obtain the second traffic tree, and the second traffic tree is cached in the local cache. Traffic replay is performed based on the local cache and the second traffic tree, and the invoked service nodes are removed from the local cache during the traffic replay process.

5. The traffic playback method according to claim 1, characterized in that, Each of the service nodes also includes: input and output parameters recorded during traffic recording; and during traffic playback based on the local cache and the first traffic tree, it also includes: During the traffic replay process, the replay data is obtained by collecting the input and output parameters generated during the service call through pre-established piling points. The piling points include: plugins for collecting the input and output parameters generated during the service call. The replay data is compared with the input and output parameters recorded by the service nodes in the first traffic tree to obtain a comparison result, wherein the comparison result is used to analyze whether there are any anomalies in the transactions associated with the first traffic tree.

6. The traffic playback method according to claim 1, characterized in that, Based on the identification information carried in the first call request, the traffic tree associated with the identification information is obtained from the distributed cache to obtain the first traffic tree, including: Read the transaction identifier, the first transaction identifier, from the identification information; Determine the traffic tree containing the first transaction identifier in the distributed cache to obtain the initial traffic tree; Read the node identifier from the identification information to obtain the first node identifier; In the initial traffic tree, the service node associated with the first node identifier and all its child service nodes are extracted to obtain the first traffic tree.

7. The traffic playback method according to claim 1, characterized in that, Before obtaining the first traffic tree by retrieving the traffic tree associated with the identification information carried in the first call request from the distributed cache, the process further includes: The target traffic is obtained by reading the traffic recorded during the transaction processing from the traffic recording and playback platform. The target traffic is assembled into a traffic tree, and the traffic tree is uploaded to the distributed cache with the transaction identifier associated with the traffic tree as the key and the traffic tree as the value of the key-value pair.

8. A flow playback device, characterized in that, include: The processing unit is configured to receive a first call request generated during traffic replay, and based on the identification information carried in the first call request, obtain the traffic tree associated with the identification information from the distributed cache to obtain a first traffic tree. The distributed cache caches M traffic trees, which are used to record the traffic generated during the transaction processing process of each transaction. Each service node in the traffic tree records: a transaction identifier, a node identifier of the service node, and a parent node identifier of the service node. The parent node identifier of each service node includes: the node identifier associated with the parent node that calls the service node. The first call request includes: a call request to call the service generated during traffic replay. A caching unit is used to cache the first traffic tree in a local cache, wherein the local cache is located in a different place than the distributed cache; The replay unit is used to perform traffic replay based on the local cache and the first traffic tree, and remove the invoked service nodes from the local cache during the traffic replay process.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored executable program, wherein, when the executable program is executed, it controls the device on which the computer-readable storage medium is located to perform the traffic playback method according to any one of claims 1 to 7.

10. An electronic device, characterized in that, include: Memory, which stores executable programs; A processor for running the program, wherein the program executes the traffic replay method according to any one of claims 1 to 7 when it runs.

11. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the steps of the traffic replay method according to any one of claims 1 to 7.

Images