Traffic playback method and device, computer device, storage medium and computer program product

Abstract

This application provides a traffic replay method, apparatus, computer device, storage medium, and computer program product. The method includes: determining the latest traffic file to be replayed from a traffic replay task queue; sending the latest traffic file to be replayed to a new code execution node and an old code execution node for traffic replay, obtaining a traffic replay result; the new code execution node running a new version of the target application's code; the old code execution node running an old version of the target application's code; and, if the traffic replay result shows failed traffic replay records, determining a processing strategy for the failed traffic replay records based on the differences between the new and old code versions. This method can improve the efficiency of traffic replay verification.

Description

Technical Field

[0001] This application relates to the field of software testing technology, and in particular to a traffic playback method, apparatus, computer equipment, storage medium, and computer program product. Background Technology

[0002] Traffic replay is an important technique in software testing and quality assurance. It records real request traffic in the production environment and re-executes it in the test environment to verify whether the behavior of the system after changes meets expectations.

[0003] Currently, existing methods for traffic replay typically rely on one-time, static, existing traffic files. However, this approach means that after a replay test is completed, newly generated real traffic cannot be promptly included in the verification scope before a new traffic capture and replay task is actively initiated. This also hinders the rapid processing of failed traffic replay records, causing traffic replay verification to lag behind the rapid code iteration of the business system.

[0004] Therefore, traditional technologies suffer from the technical problem that the verification efficiency of traffic replay cannot match the rapid iteration pace of business system code. Summary of the Invention

[0005] Based on this, the purpose of this application is to at least solve one of the above-mentioned technical defects, especially the technical defect that the verification efficiency of traffic replay in the prior art cannot match the rapid iteration rhythm of business system code. This application provides a traffic replay method, apparatus, computer equipment, computer-readable storage medium and computer program product that can improve the verification efficiency of traffic replay.

[0006] Firstly, this application provides a traffic replay method, including:

[0007] Determine the latest traffic file to be replayed from the traffic replay task queue;

[0008] The latest traffic file to be replayed is sent to both the new code execution node and the old code execution node for traffic replay to obtain the traffic replay results; the new code execution node runs the new version of the code containing the target application; the old code execution node runs the old version of the code containing the target application.

[0009] If the traffic replay results show that there are failed traffic replay records, determine the handling strategy for the failed traffic replay records based on the differences between the new version code and the old version code.

[0010] In one embodiment, the traffic replay task queue records the batch numbers of traffic files corresponding to multiple application containers; the traffic files of the multiple application containers are captured using a rolling capture method; determining the latest traffic file to be replayed from the traffic replay task queue includes:

[0011] Determine the latest batch number to be replayed from the traffic replay task queue;

[0012] Based on the latest batch number to be replayed, determine the latest traffic file to be replayed.

[0013] In one embodiment, the traffic file to be replayed includes at least one original request. The latest traffic file to be replayed is sent to the new code execution node and the old code execution node for traffic replay, and the traffic replay result is obtained, including:

[0014] Send the latest traffic file to be replayed to the new code execution node and the old code execution node, and obtain the replay result data generated by the new code execution node and the old code execution node in processing each original request;

[0015] Based on the replay results generated by the new code execution node and the old code execution node in processing each original request, a traffic replay result is generated.

[0016] In one embodiment, the replay result data includes request-response data and performance metric data. Based on the replay result data generated from processing each original request by the new code execution node and the old code execution node, a traffic replay result is generated, including:

[0017] The request and response data generated by the new code running node in processing each original request are compared with the request and response data generated by the old code running node in processing each original request to obtain the comparison results of the request and response data of each original request. In addition, the performance index data of the new code running node in processing each original request are compared with the performance index data of the old code running node in processing each original request to obtain the comparison results of the performance index data of each original request.

[0018] The traffic replay results are obtained by summarizing the comparison results of request and response data and performance index data corresponding to each original request.

[0019] In one embodiment, a processing strategy for failed traffic replay records is determined based on the differences between the new and old versions of the code, including:

[0020] Based on the differences between the new and old versions of the code, determine whether the failed traffic replay records match the expected differences.

[0021] If a failed traffic replay record matches the expected difference result, the failed traffic replay record is marked as an ignoreable record;

[0022] If a failed traffic replay record does not meet the expected difference results, generate an issue report for the failed traffic replay record and identify the code module associated with the failed traffic replay record in both the new and old versions of the code.

[0023] In one embodiment, the method further includes:

[0024] The new and old versions of the code are displayed in the traffic playback monitoring interface, and the code modules are highlighted in the display areas of the new and old versions.

[0025] Secondly, this application provides a flow playback device, comprising:

[0026] The determination module is used to determine the latest traffic file to be replayed from the traffic replay task queue;

[0027] The replay module is used to send the latest traffic file to be replayed to the new code execution node and the old code execution node for traffic replay and to obtain the traffic replay result; the new code execution node runs the new version of the target application code; the old code execution node runs the old version of the target application code.

[0028] The comparison module is used to determine the processing strategy for failed traffic replay records based on the differences between the new and old versions of the code, when the traffic replay results show that there are failed traffic replay records.

[0029] Thirdly, this application provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the above-described method.

[0030] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described method.

[0031] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described method.

[0032] As can be seen from the above technical solutions, the embodiments of this application have the following advantages:

[0033] The traffic replay method, apparatus, computer equipment, storage medium, and computer program product provided in this application determine the latest traffic file to be replayed from the traffic replay task queue; send the latest traffic file to be replayed to both the new code execution node and the old code execution node for traffic replay to obtain the traffic replay result; the new code execution node runs the new version of the code with the target application; the old code execution node runs the old version of the code with the target application; if the traffic replay result shows that there are failed traffic replay records, a processing strategy for the failed traffic replay records is determined based on the differences between the new version code and the old version code; thus, by automatically pulling the latest traffic from the queue, the verification data is ensured to be synchronized with the online scenario; by replaying in parallel to both the new and old version nodes, the request behavior results before and after the code change are compared; when inconsistencies in the request behavior results before and after the code change are found, the code differences are automatically associated to determine the processing strategy, reducing the time for manual judgment and investigation, and enabling continuous and rapid verification of real online traffic in rapid code iteration, so that the verification efficiency of traffic replay can match the rapid iteration rhythm of business system code. Attached Figure Description

[0034] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0035] Figure 1 This is a flowchart illustrating a traffic replay method in one embodiment;

[0036] Figure 2 This is a flowchart illustrating a traffic replay method in another embodiment;

[0037] Figure 3 This is a structural block diagram of a flow playback device in one embodiment;

[0038] Figure 4 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0039] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0040] When a business system undergoes significant changes, it is necessary to continuously use large-scale production traffic to test and compare the old and new versions of the code, thereby more efficiently ensuring the accuracy of the changed business system. Currently, traffic replay systems only support retrieving specified existing traffic data and cannot continuously replay it. Therefore, this application proposes a sustainable traffic replay system, employing the following traffic replay method.

[0041] In one exemplary embodiment, such as Figure 1 As shown, a traffic replay method is provided, which can be applied to a traffic replay system. The traffic replay system can include new code execution nodes and old code execution nodes. Taking the application of this method to a traffic replay system as an example, the method includes the following steps S102 to S106. Wherein:

[0042] Step S102: Determine the latest traffic file to be replayed from the traffic replay task queue.

[0043] The traffic replay task queue is a list of pending tasks organized by time, with each task corresponding to a traffic file to be replayed.

[0044] The latest traffic file to be replayed refers to the original request data file generated in the most recent traffic capture, which has not yet been processed by the traffic replay process, in the sequence of traffic files generated by continuously collecting real online traffic using the rolling traffic capture method and generating serial numbers (traffic capture batch numbers). This file contains a batch of real user request snapshots processed by the target application in the latest time period.

[0045] Optionally, the traffic replay system continuously monitors or periodically polls the traffic replay task queue and automatically selects the latest added traffic file.

[0046] Step S104: Send the latest traffic file to be replayed to the new code running node and the old code running node for traffic replay to obtain the traffic replay result; the new code running node runs the new version of the target application code; the old code running node runs the old version of the target application code.

[0047] Traffic replay refers to the testing process of resending real user requests recorded in the production environment to the application service running in the test environment in order to verify the service behavior.

[0048] The new code execution node and the old code execution node are independent and isolated computing environments (such as containers and virtual machines), which respectively deploy the new version (i.e. the version to be launched) and the old version (baseline version) of the target application.

[0049] The traffic replay result is a comprehensive summary of information comparing the response content and performance metrics of the old and new versions when processing the same request. The traffic replay result may include input parameters, return messages, message comparison results, success rate, etc. The messages are generally in JSON format. By comparing the differences in the JSON messages, the test pass or fail is determined.

[0050] Optionally, the traffic replay system sends the traffic file simultaneously and in parallel to independent nodes running both the old and new versions of the service. After the two nodes independently process all requests, the server collects and compares their processing results.

[0051] Step S106: If the traffic replay results show that there are failed traffic replay records, determine the processing strategy for the failed traffic replay records based on the differences between the new version code and the old version code.

[0052] Among them, failed traffic replay records refer to single request processing records where the output of the new code running node and the old code running node are inconsistent or the performance indicators are significantly degraded.

[0053] Among them, the handling strategy refers to the follow-up action plan formulated for inconsistent results, such as ignoring, issuing an alert, or locating the problem.

[0054] Optionally, if any inconsistency is found during the comparison, the code changes that caused the difference will be automatically analyzed, and based on the semantics of the changes (such as whether they are intentional modifications to a feature), a smart decision will be made on how to handle the failed traffic replay record, whether to mark it as "expected" or "potential defect", and corresponding processing suggestions will be output.

[0055] In the aforementioned traffic replay method, the latest traffic file to be replayed is determined from the traffic replay task queue; this file is then sent to both the new and old code execution nodes for replay, yielding the replay results; the new code execution node runs the new version of the target application's code; and the old code execution node runs the old version of the target application's code. If the replay results show failed replay records, a processing strategy is determined based on the differences between the new and old code versions. This automatically retrieves the latest traffic from the queue, ensuring that verification data is synchronized with the online scenario. Parallel replay to both new and old version nodes allows for a comparison of request behavior results before and after code changes. When inconsistencies are found, the code differences are automatically correlated to determine the processing strategy, reducing the time spent on manual judgment and investigation. This enables continuous and rapid verification of real online traffic during rapid code iteration, ensuring that the verification efficiency of traffic replay matches the rapid iteration pace of the business system's code.

[0056] In an exemplary embodiment, the traffic replay task queue records the capture batch numbers corresponding to the traffic files of multiple application containers; the traffic files of the multiple application containers are captured using a rolling capture method; determining the latest traffic file to be replayed from the traffic replay task queue includes: determining the latest batch number to be replayed from the traffic replay task queue; and determining the latest traffic file to be replayed based on the latest batch number to be replayed.

[0057] Among them, the rolling traffic capture method refers to the method of capturing traffic from different application container instances in a distributed application deployment according to a predetermined order or strategy, so as to avoid putting too much pressure on a single instance and to cover the behavior of all instances.

[0058] The batch number is a unique sequence identifier generated for each capture operation, used to mark and sort traffic files captured from different containers and at different times.

[0059] It should be noted that each traffic file to be replayed contains the traffic of one application container. This application can support multiple application containers to capture traffic simultaneously and generate multiple traffic files.

[0060] Optionally, the server fetches user request data from multiple application container instances in a rolling manner in the production environment, generates a batch number for each complete fetch cycle, stores all traffic files of the corresponding batch in the storage system, and pushes the batch number as a task item into the traffic replay task queue. When traffic replay needs to be performed, the traffic replay system can read the latest batch number from the task queue, and then find and load all traffic files belonging to that batch in the specified storage path according to the batch number as input for this traffic replay.

[0061] In this embodiment, the traffic file collection and organization method based on rolling flow capture and batch number management enables the traffic playback system to automatically identify and select the latest traffic file for playback, realizing the automation and seamless connection between the verification process and online traffic generation. This ensures that the traffic used for testing can reflect the latest user behavior patterns in real time, thereby making the verification results more timely and representative, and supporting rapid and secure code iteration.

[0062] In an exemplary embodiment, the traffic file to be replayed includes at least one original request. The step of sending the latest traffic file to be replayed to the new code execution node and the old code execution node for traffic replay to obtain a traffic replay result includes: sending the latest traffic file to be replayed to the new code execution node and the old code execution node; obtaining the replay result data generated by the new code execution node and the old code execution node in processing each of the original requests; and generating the traffic replay result based on the replay result data generated by the new code execution node and the old code execution node in processing each of the original requests.

[0063] The original request refers to real user request data that has been captured from a real production environment without any modification. It usually includes information such as HTTP / HTTPS request headers, request body, and URL parameters.

[0064] Among them, replay result data refers to the set of all data that can characterize the processing behavior and its results generated when the new code running node or the old code running node receives the original request in the traffic file to be replayed and processes and responds to the request.

[0065] Optionally, the traffic replay system reads the traffic file to be replayed, parses out the original requests contained therein, and then sends these requests to the new code execution node and the old code execution node concurrently. While the two nodes are processing the original requests, the replay result data of each original request is collected. After all requests have been processed, the collected replay result data is organized to obtain the traffic replay results, which prepares for the next step of comparative analysis.

[0066] In this embodiment, by automatically executing request replay and synchronously collecting response data and performance metrics data, a comprehensive assessment of the impact of code changes is achieved. Automated data collection enables each code iteration to obtain immediate and objective feedback on functional correctness and performance, providing dual data support for quickly determining whether a new version meets the launch standards.

[0067] In an exemplary embodiment, the replay result data includes request-response data and performance metric data. Based on the replay result data generated by the new code execution node and the old code execution node in processing each original request, a traffic replay result is generated, including: comparing the request-response data generated by the new code execution node in processing each original request with the request-response data generated by the old code execution node in processing each original request to obtain a request-response data comparison result for each original request; comparing the performance metric data of the new code execution node in processing each original request with the performance metric data of the old code execution node in processing each original request to obtain a performance metric data comparison result for each original request; and summarizing the request-response data comparison result and the performance metric data comparison result for each original request to obtain the traffic replay result.

[0068] The request-response data is used to verify the correctness of the target application's functionality. It may include the response body, response headers, and response status codes returned by the running node in response to the original request. It may also include the call parameters and results of databases, caches, and external service interfaces during the request processing, as well as the generated key logs and business error codes.

[0069] Among them, performance metrics data are used to evaluate the application's performance and resource usage, and may include the time spent processing the request, resource consumption, and system status indicators (such as GC counts and thread pool activity).

[0070] The request-response data comparison result is a conclusion drawn from a point-by-point comparison of the response content (such as JSON structure, field values, and status codes) returned by the new version code and the old version code for the same request. The result may be "consistent", "inconsistent", or detailed differences.

[0071] Among them, the performance indicator data comparison results are the conclusions drawn from the comparative analysis of the performance indicator values ​​of the new and old versions when processing the same request, such as "response time increased by 15%" and "memory usage did not change significantly".

[0072] Optionally, for each original request, the response data returned by the new code execution node and the old code execution node are compared, the difference or ratio of key performance indicators between the new code execution node and the old code execution node is calculated, and then the two types of comparison results (whether they are consistent, details of the differences, and performance changes) of each original request are formatted and recorded. Finally, the comparison records of all requests are aggregated to generate a structured traffic replay result report, which clearly lists all inconsistent requests, performance-degraded requests and their detailed information.

[0073] In this embodiment, request response data and performance index data together constitute multi-dimensional replay result data. By comparing these two types of data separately, a structured analysis report can be generated. This report can not only accurately locate the specific request that caused the functional difference, but also quantitatively assess the impact of code changes on system performance. Presented in the form of a structured report, it enables development and quality assurance personnel to quickly focus on the problem and shorten the verification cycle.

[0074] In one exemplary embodiment, a processing strategy for failed traffic replay records is determined based on the differences between the new and old versions of the code, including: determining whether the failed traffic replay records meet the expected difference results based on the differences between the new and old versions of the code; if the failed traffic replay records meet the expected difference results, marking the failed traffic replay records as ignoreable records; if the failed traffic replay records do not meet the expected difference results, generating a problem report for the failed traffic replay records, and identifying the code modules associated with the failed traffic replay records in both the new and old versions of the code.

[0075] The expected difference result refers to the acceptable request response or acceptable performance change caused by this code change (such as new feature development, defect fixing, interface adjustment).

[0076] Among them, negligible records refer to failed replay records that are judged to meet the expected differences and do not require manual intervention.

[0077] Among them, code modules refer to the basic code units that make up an application system, such as a class or function.

[0078] Optionally, when the traffic replay system detects a failed traffic replay record, it automatically obtains the code differences between the old and new versions of the current iteration. Then, it analyzes the request interface and changed content corresponding to the failed record to determine whether it was caused by an intentional modification in the code differences. If so, it marks it as "ignorable". If not, it is determined to be an unexpected behavior. Then, it automatically analyzes and locates the specific module (such as a class or function) in the old and new code that is most likely to cause the problem, and generates a problem report containing the problem request, the difference behavior, and the location of the suspicious code.

[0079] In this embodiment, by associating code differences with replay failure results, it is possible to distinguish between expected and unexpected failures, thereby improving the efficiency of handling code defects, automatically locating suspicious code modules, shortening the investigation time for failure issues, and improving the efficiency of traffic replay verification.

[0080] In an exemplary embodiment, the method further includes: displaying the new version code and the old version code in the traffic playback monitoring interface, and highlighting the code module in the display area of ​​the new version code and the display area of ​​the old version code.

[0081] The traffic replay monitoring interface is an interactive interface used to visually display the status of traffic replay tasks, comparison results, and detailed information.

[0082] Highlighting refers to using special colors, backgrounds, borders, and other visual styles to highlight specific text or code blocks in the traffic playback monitoring interface, which can quickly attract the attention of testers.

[0083] Optionally, after generating a problem report, detailed traffic replay results can be displayed through the front-end traffic replay monitoring interface. When a user clicks to view a specific unexpected failure record, the traffic replay monitoring interface will display the source code views of the old and new versions side by side, and automatically highlight the corresponding line numbers or code blocks in the two source code views to clearly indicate the possible code locations that caused the differences.

[0084] In this embodiment, the code module location results obtained from automatic analysis are presented intuitively in a highlighted form in the code comparison view of the traffic playback monitoring interface, enabling developers to quickly address the problems in the code after receiving a problem report, thus shortening the processing time.

[0085] The traffic replay method presented in this application addresses the pain point of existing traffic replay systems that only support existing traffic and cannot continuously verify it. Through a rolling traffic capture design, it enables uninterrupted acquisition and replay of production traffic, adapting to the frequent changes in business systems. Furthermore, this application employs a queued traffic file management and real-time consumption mechanism, overcoming the limitation of traditional traffic replay systems that only support single replay of existing data, achieving highly available continuous traffic replay and accurate comparison.

[0086] To facilitate understanding by those skilled in the art, the following exemplifies the data interaction process between a traffic capture system and a traffic replay system. The traffic capture system employs a rolling capture method, supporting the capture of traffic from multiple application containers. It automatically starts the next capture immediately after the previous one ends, enabling continuous acquisition of production traffic. For each captured traffic file, a batch number is recorded in a queue, awaiting consumption by the traffic replay system. The traffic replay system periodically queries the queue for traffic file data, consumes the latest traffic file, and sends the traffic to machines running the new version of the code and those running the old version for comparison. Replay terminates only when the user-defined stopping conditions (duration or total number of replays) are met. Users can obtain the total number of replays, success rate, and specific data on failed traffic from the traffic replay result report, which supports the replay of failed traffic.

[0087] Regarding the stopping conditions, they can be determined based on two dimensions: the number of replays and the replay duration. For example, the stopping conditions could be that the replay traffic reaches 1 million records or the replay duration reaches 3 days; if either condition is met, the replay will automatically stop. The stopping conditions are determined based on the degree of business changes, specifically the replay traffic threshold and the replay duration threshold. Generally, the greater the code changes, the more replays, and the longer the duration.

[0088] In another embodiment, such as Figure 2 As shown, a traffic replay method is provided. Taking the application of this method in a traffic replay system as an example, the method includes the following steps:

[0089] Step S202: Determine the latest traffic file to be replayed from the traffic replay task queue.

[0090] Step S204: Send the latest traffic file to be replayed to the new code execution node and the old code execution node, and obtain the replay result data generated by the new code execution node and the old code execution node in processing each original request.

[0091] Step S206: Generate traffic replay results based on the replay result data generated by the new code running node and the old code running node in processing each original request.

[0092] Step S208: If the traffic replay results show that there are failed traffic replay records, determine the processing strategy for the failed traffic replay records based on the differences between the new version code and the old version code.

[0093] It should be noted that the specific limitations of the above steps can be found in the specific limitations of a traffic replay method described above.

[0094] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0095] The following describes the traffic playback device provided in the embodiments of this application. The traffic playback device has the same inventive concept as the traffic playback method described above. The solution to the problem provided by the device is similar to the solution described in the above method. Therefore, the specific limitations of one or more traffic playback device embodiments provided below can be referred to the limitations of the traffic playback method above. The traffic playback device described below and the traffic playback method described above can be referred to each other, and will not be repeated here.

[0096] In one exemplary embodiment, Figure 3 This is a schematic diagram of the structure of a flow playback device provided in an embodiment of this application, as shown below. Figure 3 As shown, the flow playback device includes: a determination module 302, a playback module 304, and a comparison module 306, wherein:

[0097] Module 302 is used to determine the latest traffic file to be replayed from the traffic replay task queue;

[0098] The replay module 304 is used to send the latest traffic file to be replayed to the new code execution node and the old code execution node for traffic replay to obtain the traffic replay result; the new code execution node runs the new version of the target application code; the old code execution node runs the old version of the target application code.

[0099] The comparison module 306 is used to determine the processing strategy for the failed traffic replay records based on the differences between the new version code and the old version code when the traffic replay results show that there are failed traffic replay records.

[0100] In an exemplary embodiment, the traffic replay task queue records the capture batch numbers corresponding to the traffic files of multiple application containers; the traffic files of the multiple application containers are captured using a rolling capture method; the determining module 302 is specifically used to determine the latest batch number to be replayed from the traffic replay task queue; and determine the latest traffic file to be replayed based on the latest batch number to be replayed.

[0101] In an exemplary embodiment, the traffic file to be replayed includes at least one original request. The replay module 304 is specifically used to send the latest traffic file to be replayed to the new code execution node and the old code execution node, obtain the replay result data generated by the new code execution node and the old code execution node in processing each original request, and generate a traffic replay result based on the replay result data generated by the new code execution node and the old code execution node in processing each original request.

[0102] In an exemplary embodiment, the replay result data includes request-response data and performance indicator data. The replay module 304 is specifically used to compare the request-response data generated by the new code running node in processing each original request with the request-response data generated by the old code running node in processing each original request to obtain the request-response data comparison result of each original request; and to compare the performance indicator data of the new code running node in processing each original request with the performance indicator data of the old code running node in processing each original request to obtain the performance indicator data comparison result of each original request; and to summarize the request-response data comparison result and the performance indicator data comparison result corresponding to each original request to obtain the traffic replay result.

[0103] In an exemplary embodiment, the comparison module 306 is specifically configured to determine whether the failed traffic replay record meets the expected difference results based on the differences between the new version code and the old version code; if the failed traffic replay record meets the expected difference results, mark the failed traffic replay record as an ignoreable record; if the failed traffic replay record does not meet the expected difference results, generate a problem report for the failed traffic replay record, and identify the code module associated with the failed traffic replay record in the new version code and the old version code.

[0104] In an exemplary embodiment, the comparison module 306 is further configured to display the new version code and the old version code in the traffic playback monitoring interface, and to highlight the code module in the display area of ​​the new version code and the display area of ​​the old version code.

[0105] In one exemplary embodiment, this application also provides a computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the steps of any of the traffic playback methods described above.

[0106] In one exemplary embodiment, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of any of the traffic playback methods described above.

[0107] In one exemplary embodiment, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the traffic replay methods described in the above embodiments.

[0108] Indicatively, such as Figure 4 As shown, Figure 4 This is a schematic diagram of the internal structure of a computer device 400 provided in an embodiment of this application. The computer device 400 can be provided as a server. (Refer to...) Figure 4 The computer device 400 includes a processing component 402, which further includes one or more processors, and memory resources represented by memory 401 for storing instructions, such as application programs, that can be executed by the processing component 402. The application programs stored in memory 401 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 402 is configured to execute instructions to perform the traffic playback method of any of the above embodiments.

[0109] The computer device 400 may also include a power supply component 403 configured to perform power management of the computer device 400, a wired or wireless network interface 404 configured to connect the computer device 400 to a network, and an input / output (I / O) interface 405. The computer device 400 may operate on an operating system stored in memory 401, such as Windows Server™, Mac OS X™, Unix™, Linux™, Free BSD™, or similar.

[0110] Those skilled in the art will understand that Figure 4 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0111] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0112] The various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can be referred to each other.

[0113] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for playback of streaming data, characterized in that, The method includes: Determine the latest traffic file to be replayed from the traffic replay task queue; The latest traffic file to be replayed is sent to the new code execution node and the old code execution node for traffic replay to obtain the traffic replay result; the new code execution node runs the new version of the target application code; the old code execution node runs the old version of the target application code; If the traffic replay results show that there are failed traffic replay records, a processing strategy for the failed traffic replay records is determined based on the differences between the new version code and the old version code.

2. The method according to claim 1, characterized in that, The traffic replay task queue records the batch numbers of traffic files corresponding to multiple application containers; the traffic files of the multiple application containers are captured using a rolling capture method. The step of determining the latest traffic file to be replayed from the traffic replay task queue includes: Determine the latest batch number to be replayed from the traffic replay task queue; Based on the latest batch number to be replayed, determine the latest traffic file to be replayed.

3. The method according to claim 1, characterized in that, The traffic file to be replayed includes at least one original request. Sending the latest traffic file to the new code execution node and the old code execution node for traffic replay to obtain the traffic replay result includes: The latest traffic file to be replayed is sent to the new code execution node and the old code execution node, and the replay result data generated by the new code execution node and the old code execution node in processing each of the original requests is obtained; The traffic replay result is generated based on the replay result data generated by the new code execution node and the old code execution node in processing each of the original requests.

4. The method according to claim 3, characterized in that, The replay result data includes request-response data and performance metric data. Generating the traffic replay result based on the replay result data generated by the new code execution node and the old code execution node processing each of the original requests includes: The request response data generated by the new code running node in processing each of the original requests is compared with the request response data generated by the old code running node in processing each of the original requests to obtain the request response data comparison result of each of the original requests. In addition, the performance index data of the new code running node in processing each of the original requests is compared with the performance index data of the old code running node in processing each of the original requests to obtain the performance index data comparison result of each of the original requests. The traffic replay result is obtained by summarizing the comparison results of request-response data and performance indicator data corresponding to each original request.

5. The method according to claim 1, characterized in that, The step of determining a processing strategy for the failed traffic replay records based on the differences between the new and old version codes includes: Based on the differences between the new and old versions of the code, determine whether the failed traffic replay records match the expected difference results; If the failed traffic replay record matches the expected difference result, the failed traffic replay record is marked as an ignoreable record; If the failed traffic replay record does not conform to the expected difference result, a problem report is generated for the failed traffic replay record, and the code module associated with the failed traffic replay record is identified in both the new version code and the old version code.

6. The method according to claim 5, characterized in that, The method further includes: The new version code and the old version code are displayed in the traffic playback monitoring interface, and the code module is highlighted in the display area of ​​the new version code and the display area of ​​the old version code.

7. A flow playback device, characterized in that, The device includes: The determination module is used to determine the latest traffic file to be replayed from the traffic replay task queue; The replay module is used to send the latest traffic file to be replayed to the new code execution node and the old code execution node for traffic replay to obtain the traffic replay result; the new code execution node runs the new version of the target application code; the old code execution node runs the old version of the target application code; The comparison module is used to determine the processing strategy for the failed traffic replay record based on the differences between the new version code and the old version code when the traffic replay result shows that there is a failed traffic replay record.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images