Traffic screening method and related device

Abstract

The invention relates to the technical field of computers, and provides a traffic screening method and a related device, which are used for improving the traffic playback effect, and the method comprises the following steps: obtaining to-be-analyzed traffic in a set acquisition period; analyzing the candidate service requests based on the service parameter sets carried by the candidate service requests in the to-be-analyzed traffic to obtain corresponding command coverage evaluation values; then, based on the obtained command coverage evaluation values of the candidate service requests, screening out a target service request; and finally, based on the target service request and the service response thereof, obtaining target traffic for traffic playback. By screening the traffic, the return visit test under more service scenes is realized by using less traffic.

Description

Technical Field

[0001] This application relates to the field of traffic recording and playback technology, and provides a traffic filtering method and related apparatus. Background Technology

[0002] Traffic recording and replay is a software testing and system verification technique primarily used to ensure that applications or services can function correctly in the face of actual production traffic. Traffic recording and replay involves collecting real operational data (i.e., traffic) from a production environment and then reproducing that traffic in a non-production environment (such as a development, testing, or pre-release environment) to test system performance, stability, compatibility, and other aspects.

[0003] In related technologies, traffic is typically recorded according to business type or by random sampling, and then replayed directly based on the recorded traffic. However, in complex network environments, there is a large amount of redundant operational data. Therefore, recording and replaying based on the full amount of data consumes a lot of resources, has low recording and playback efficiency, and the playback effect is difficult to guarantee. Summary of the Invention

[0004] This application provides a traffic filtering method and related apparatus to improve test playback performance.

[0005] In a first aspect, embodiments of this application provide a traffic filtering method, including:

[0006] Acquire the traffic to be analyzed within a set collection period. The traffic to be analyzed includes at least one candidate service request, and each candidate service request carries a corresponding set of business parameters.

[0007] Based on the business parameter set carried by each of the at least one candidate service request, the at least one candidate service request is analyzed to obtain the corresponding command coverage evaluation value. The command coverage evaluation value represents at least one business logic used to process the corresponding candidate service request.

[0008] Based on the command coverage evaluation value of each of the at least one candidate service requests, select the candidate service requests from the at least one candidate service requests whose at least one business logic satisfies the set filtering conditions, and use them as the target service requests.

[0009] Based on at least one target service request obtained, and combined with the service responses collected for each of the at least one target service request, the target traffic for traffic replay is obtained.

[0010] Secondly, embodiments of this application provide a flow filtering device, comprising:

[0011] The traffic acquisition unit is used to acquire the traffic to be analyzed within a set collection period. The traffic to be analyzed includes at least one candidate service request, and each candidate service request carries a corresponding set of business parameters.

[0012] The request analysis unit is used to analyze the at least one candidate service request based on the business parameter set carried by each of the at least one candidate service requests, and obtain the corresponding command coverage evaluation value. The command coverage evaluation value represents at least one business logic used to process the corresponding candidate service request.

[0013] The request filtering unit is used to filter out candidate service requests from the at least one candidate service requests based on the command coverage evaluation value of each of the at least one candidate service requests obtained, and select the candidate service requests whose at least one business logic satisfies the set filtering conditions as the target service requests.

[0014] The traffic recording unit is used to obtain target traffic for traffic replay based on at least one target service request and the service responses collected for each target service request.

[0015] In one possible implementation, when analyzing the at least one candidate service request based on the business parameter set carried by each of the at least one candidate service requests to obtain the corresponding command coverage evaluation value, the request analysis unit is specifically used for:

[0016] Based on the service parameter sets carried by each of the at least one candidate service requests, parameter statistics are performed to obtain each candidate service parameter. Based on the values ​​of each candidate service parameter, at least one target parameter whose value is within a set value range is selected from the candidate service parameters.

[0017] Based on the selected at least one target parameter, the at least one candidate service request is analyzed to obtain the corresponding command coverage evaluation value.

[0018] In one possible implementation, when analyzing the at least one candidate service request based on the selected at least one target parameter to obtain the corresponding command coverage evaluation value, the request analysis unit is specifically used for:

[0019] For each of the at least one candidate service request, perform the following operations:

[0020] Based on the selected at least one target parameter, a target parameter is determined from the set of business parameters carried by a candidate service request;

[0021] Based on the proportion of the target parameter value types carried in the candidate service request to the total number of value types set for the target parameter, the command coverage evaluation value of the candidate service request is obtained.

[0022] In one possible implementation, when obtaining the command coverage evaluation value of a candidate service request based on the proportion of the value types of the target parameter carried in the candidate service request to the total value types set for the target parameter, the request analysis unit is specifically used for:

[0023] Hash the values ​​of the at least one target parameter in the at least one candidate service request to obtain the hash values ​​of the at least one target parameter respectively;

[0024] Based on the hash values ​​of the at least one target parameter, type statistics are performed to obtain the total number of value types; and based on the hash values ​​of the target parameters carried in the candidate service request, the value types of the target parameters carried in the candidate service request are obtained.

[0025] Based on the number of target parameter values ​​carried in a candidate service request and their proportion in the total number of value types, the command coverage evaluation value of the candidate service request is obtained.

[0026] In one possible implementation, based on the command coverage evaluation values ​​of each of the at least one candidate service requests, when selecting candidate service requests from the at least one candidate service requests whose at least one business logic satisfies the set filtering conditions as the target service requests, the request filtering unit is specifically used for:

[0027] Based on the command coverage evaluation value of each of the at least one candidate service requests obtained, candidate service requests that use at least one business logic that meets the set filtering conditions are selected from the at least one candidate service requests as reference service requests.

[0028] Each of the selected reference service requests is pre-played, and based on the pre-playback results, at least one target service request that was successfully pre-played is selected from the at least one reference service request.

[0029] In one possible implementation, when selecting candidate service requests from the at least one candidate service requests that use at least one business logic that satisfies the set filtering conditions as reference service requests based on the command coverage evaluation values ​​of each of the at least one candidate service requests, the request filtering unit is specifically used for:

[0030] Based on the at least one candidate service request, requests are combined to obtain at least one candidate service request group, and based on the command coverage evaluation value of each candidate service request group containing candidate service requests, the request coverage evaluation value of the at least one candidate service request group is obtained.

[0031] Based on at least one obtained request coverage evaluation value, candidate service request groups whose request coverage evaluation values ​​exceed a set evaluation value threshold are selected from the at least one candidate service request group, and reference service requests in the selected candidate service request groups are used as reference service requests.

[0032] In one possible implementation, when pre-playing the at least one selected reference service request and, based on the obtained pre-playback results, selecting at least one target service request from the at least one reference service request that was successfully pre-played back, the request filtering unit is specifically used for:

[0033] For each of the at least one selected reference service request, perform the following operations:

[0034] Based on a reference service request, multiple requests are made to the target service to obtain the pre-replay results corresponding to each of the multiple requests. Each pre-replay result contains various result fields.

[0035] Based on the values ​​of each result field contained in each of the multiple pre-playback results, the multiple pre-playback results are compared to obtain a comparison result;

[0036] If the comparison result indicates that there is no random field with different values ​​in the multiple pre-replay results, then the reference service request will be taken as the target service request for successful pre-replay.

[0037] In one possible implementation, the request filtering unit is also used for:

[0038] If the comparison result indicates that there is at least one random field in each result field, then multiple requests are re-initiated based on the reference service request to obtain multiple new pre-replay results;

[0039] Based on the values ​​of the fields other than the at least one random field in each of the multiple new pre-playback results, the multiple new pre-playback results are compared to obtain a new comparison result. When the new comparison result indicates that there is no random field in the other fields, the reference service request is taken as the target service request for successful pre-playback.

[0040] In one possible implementation, when obtaining the target traffic for traffic replay based on at least one target service request and the service responses collected for each of the at least one target service request, the traffic recording unit is specifically used for:

[0041] The cached service responses of the at least one target service request are used as the service responses collected for each of the at least one target service request, and based on the obtained at least one target service request and its corresponding service response, the target traffic for traffic replay is obtained; or,

[0042] Requests are sent to the target service based on the at least one target service request, the corresponding service responses are collected, and the target traffic for traffic replay is obtained based on the at least one target service request and its corresponding service response.

[0043] Thirdly, embodiments of this application provide an electronic device, including a processor and a memory, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the steps of the above-described method.

[0044] Fourthly, embodiments of this application provide a computer-readable storage medium including a computer program, which, when run on an electronic device, causes the electronic device to perform the steps of any of the methods described above.

[0045] Fifthly, embodiments of this application provide a computer program product, the program product including a computer program stored in a computer-readable storage medium, wherein a processor of an electronic device reads from the computer-readable storage medium and executes the computer program, causing the electronic device to perform the steps of any of the methods described above.

[0046] In this embodiment, firstly, the candidate service requests are analyzed based on the set of business parameters carried by each of the at least one candidate service request in the traffic to be analyzed, and a command coverage evaluation value is obtained. Since it represents the business logic used to process the corresponding candidate service request, the target traffic for replay can be accurately selected, so that the target traffic can cover more business scenarios, thereby more comprehensively verifying the stability of the system.

[0047] Secondly, based on the command coverage evaluation values ​​of the candidate service requests, the target service requests that use at least one business logic that meets the set filtering conditions are selected from at least one candidate service request. This allows for the rapid and accurate selection of target traffic for replay, thereby enabling traffic replay using a small amount of traffic data, which improves replay efficiency and ensures replay effect.

[0048] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

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

[0050] Figure 1 This is a schematic diagram of an application scenario provided in the embodiments of this application;

[0051] Figure 2 This is a flowchart illustrating a traffic filtering method provided in an embodiment of this application;

[0052] Figure 3 This is a logical diagram illustrating a service invocation provided in an embodiment of this application;

[0053] Figure 4 This is a logical diagram illustrating a command coverage evaluation process provided in an embodiment of this application;

[0054] Figure 5 This is a logical diagram illustrating another command coverage evaluation process provided in the embodiments of this application;

[0055] Figure 6 This is a flowchart illustrating a target service request filtering method provided in an embodiment of this application;

[0056] Figure 7 This is a logical diagram illustrating a pre-playback process provided in an embodiment of this application;

[0057] Figure 8 This is a logical diagram illustrating a traffic recording and playback process provided in an embodiment of this application;

[0058] Figure 9 This is a logical diagram illustrating a traffic pre-playback process provided in an embodiment of this application;

[0059] Figure 10 This is a schematic diagram of the structure of a flow filtering device provided in the embodiments of this application;

[0060] Figure 11 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

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

[0062] In this application embodiment, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0063] It is understood that when the embodiments of this application are applied to specific products or technologies, relevant licenses or consents need to be obtained, and the collection, use and processing of relevant data need to comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0064] Traffic recording and playback involves collecting real operational data (i.e., traffic) from a production environment and then reproducing that traffic in a non-production environment (such as a development, testing, or pre-release environment) to test system performance, stability, compatibility, and other aspects.

[0065] In related technologies, traffic is typically recorded according to business type or by random sampling, and then replayed directly based on the recorded traffic. However, in complex network environments, there is a large amount of redundant operational data. Therefore, recording and replaying based on the full amount of data consumes a lot of resources, has low recording and playback efficiency, and the playback effect is difficult to guarantee.

[0066] In this embodiment, traffic filtering can also be called traffic extraction. The purpose of traffic extraction is to select the smallest set of traffic with the largest business logic coverage that can be effectively replayed, thereby more comprehensively verifying the system's performance. For example, during traffic extraction, firstly, based on the business parameter sets carried by at least one candidate service request in the traffic to be analyzed, the candidate service requests are analyzed to obtain command coverage evaluation values. Since these values ​​represent the business logic used to process the corresponding candidate service requests, the target traffic for replay can be accurately filtered out, allowing the target traffic to cover more business scenarios and thus more comprehensively verifying the system's stability. Secondly, based on the obtained command coverage evaluation values ​​of each candidate service request, target service requests whose at least one business logic meets the set filtering conditions are filtered out from the at least one candidate service request. This quickly and accurately filters out the target traffic for replay, thereby enabling traffic replay using a small amount of traffic data, improving replay efficiency, and ensuring replay effectiveness.

[0067] The following is a brief introduction to the application scenarios to which the technical solutions of the embodiments of this application are applicable. It should be noted that the application scenarios described below are only for illustrating the embodiments of this application and are not intended to limit the scope. In specific implementation, the technical solutions provided by the embodiments of this application can be flexibly applied according to actual needs.

[0068] The solution provided in this application can be used in traffic recording and playback scenarios, such as traffic recording and playback in a microservice architecture. This solution can be applied as a basic technology in various scenarios, including but not limited to cloud technology, artificial intelligence, smart transportation, and assisted driving.

[0069] See Figure 1 The diagram illustrates an application scenario provided in this application embodiment. This application scenario includes terminal device 110 and server 120. The number of terminal devices 110 can be one or more. The number of servers 120 can also be one or more. This application does not specifically limit the number of terminal devices 110 and servers 120.

[0070] In this embodiment, the terminal device 110 may be a smartphone, tablet computer, laptop computer, desktop computer, smart speaker, smartwatch, IoT device, smart voice interaction device, smart home appliance, vehicle terminal, aircraft, etc., but is not limited to these. The terminal device 110 is equipped with a client for recording and playing back traffic data. The client may be in the form of an application, mini-program, webpage, etc., but is not limited to these.

[0071] Server 120 is the backend server corresponding to the client. Server 120 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms.

[0072] Terminal device 110 and server 120 can be connected directly or indirectly through wired or wireless communication, and this application does not impose any restrictions on this.

[0073] The traffic filtering method mentioned in the embodiments of this application can be executed by a server or a terminal device, or by both a server and a terminal device. There is no limitation on this. The following description mainly uses the server as an example.

[0074] For example, the server acquires the traffic to be analyzed within a set collection period. The traffic to be analyzed includes at least one candidate service request, each carrying a corresponding set of business parameters. Then, based on the business parameter sets carried by each of the at least one candidate service request, the server analyzes each candidate service request to obtain a corresponding command coverage evaluation value. The command coverage evaluation value represents at least one business logic used to process the corresponding candidate service request. Then, based on the obtained command coverage evaluation values ​​of each of the at least one candidate service requests, the server selects candidate service requests whose at least one business logic meets the set filtering conditions as target service requests. Finally, based on the obtained at least one target service request and the service responses collected for each of the at least one target service request, the server obtains the target traffic for traffic replay.

[0075] See Figure 2 The diagram shown is a flowchart of a traffic filtering method provided in an embodiment of this application. This method is applied to a traffic filtering device, which can be a terminal device or a server. The specific process is as follows:

[0076] S201. Obtain the traffic to be analyzed within the set collection period. The traffic to be analyzed includes at least one candidate service request, and each candidate service request carries a corresponding set of business parameters.

[0077] The traffic to be analyzed can be collected from the services being recorded. The recorded service refers to one or more services whose traffic is being recorded, such as account login services, information query services, and data sharing services. In this article, the recorded service can also be referred to as the target service.

[0078] In this embodiment, traffic can be collected periodically according to a set collection period, or traffic can be collected once or multiple times according to a set collection period; there is no limitation on this. The set collection period can be configured based on the historical traffic volume of the recorded service, the computing performance of the traffic filtering device, etc., but is not limited to these. In this document, only traffic filtering of the traffic to be analyzed within a set collection period is used as an example for illustration.

[0079] In one possible implementation, all or part of the service requests collected within a set collection period are used as candidate service requests. The number of candidate service requests can be one or more, without limitation. As an example, a portion of service requests are collected as candidate service requests based on a sampling rate, where the sampling rate is used to limit the maximum proportion of traffic collected; for example, the sampling rate can be between 1% and 5%.

[0080] A candidate service request can carry one or more business parameters. Business parameters, also known as input parameters, are data transmitted along with the request when a client (which may be, but is not limited to, an upstream service or frontend application of the target service; this article only uses an upstream service as an example) sends a candidate service request to the target service. Business parameters can be used to indicate the specific operations that the target service needs to perform and the information it requires. Thus, when the target service receives a candidate service request, it can decide how to process the request based on the business parameters carried in the request. For example, if the target service is a query service, the business parameters carried in the candidate service request could be search keywords such as the name of the public account or the content of the public account.

[0081] In one implementation, after receiving a candidate service request, the target service performs business processing based on the request and returns a service response to the client. The service response may carry output parameters, which characterize the processing result of the candidate service request. Output parameters include, but are not limited to, queried information, success / failure indicators, and error codes. For example, the output parameter for a candidate service request to query a public account could be the public account identifier. These output parameters provide the client with the processing result, enabling the client to perform subsequent processing, such as data display and error handling.

[0082] In some implementations, the target service has an upstream service, and the candidate service request is sent to the target service through the upstream service. In this case, after processing the candidate service request, the target service returns the service response to the upstream service.

[0083] In some implementations, the target service also has downstream services. When the target service needs to call the downstream service during the business processing of the candidate service request, it sends a service request to the downstream service and receives the service response returned by the downstream service.

[0084] In this context, upstream and downstream services are relative concepts used to describe the direction and dependencies between service calls. In the call chain, the upstream service precedes the downstream service, relying on the functionality or data provided by the downstream service to complete its own business logic. The downstream service provides the upstream service with necessary data, functionality, or processing results to support its operation. For example, if service A calls service B, then service A is the upstream service, and service B is the downstream service.

[0085] See Figure 3 The target service is service B. The target service has an upstream service (service A) and a downstream service (service C). The target service can collect traffic between the upstream service and the downstream service.

[0086] When service A needs to call service B, service A sends an RPC call request to service B. After receiving the RPC call request, service B performs business processing according to the RPC call request and returns the corresponding RPC call response. Similarly, when service B needs to call service C, service B sends an RPC call request to service C. After receiving the RPC call request, service C performs business processing according to the RPC call request and returns the corresponding RPC call response.

[0087] In one implementation, traffic filtering can be performed by the target service; that is, the server hosting the target service is the traffic filtering device. During the traffic filtering process, the server hosting the target service collects and analyzes the traffic between upstream and downstream services to obtain the target traffic for traffic replay. The traffic analysis process between upstream and downstream services is described in S202-S204, and will not be repeated here.

[0088] In one possible implementation, the target service reports the traffic between the upstream and downstream services to the traffic filtering device, and then the traffic filtering device analyzes the traffic between the upstream and downstream services to obtain the target traffic for traffic replay.

[0089] The traffic reported by the target service to the traffic filtering device can be the traffic to be analyzed within a set collection period. The traffic filtering device obtains the traffic to be analyzed and analyzes each of the at least one candidate service requests based on the business parameter set carried by each of the at least one candidate service requests to obtain the corresponding command coverage evaluation value. Based on the obtained command coverage evaluation value of each of the at least one candidate service requests, the device filters out the candidate service requests whose at least one business logic meets the set filtering conditions as the target service requests. Finally, based on the obtained at least one target service request and the service responses collected for each of the at least one target service requests, the target traffic for traffic replay is obtained.

[0090] Of course, the traffic reported by the target service to the traffic filtering device can also be service requests after initial screening. In this case, the traffic filtering device performs pre-replay based on the service requests after initial screening, and then obtains the target traffic for traffic replay based on the target service requests that have been successfully replayed. The service requests after initial screening refer to reference service requests selected from at least one candidate service requests based on their respective command coverage evaluation values, where at least one business logic used satisfies the set screening conditions. Pre-replay refers to performing pre-replay on each of the at least one selected reference service requests, and selecting at least one target service request that has been successfully replayed from the at least one reference service request based on the obtained pre-replay results. The initial screening process is described in S2031 below, and the pre-replay process is described in S2032 below.

[0091] Service calls can be implemented through, but are not limited to, Remote Procedure Calls (RPCs). This article only uses RPC calls as an example. In RPC calls, service requests can also be called RPC call requests, and service responses can also be called RPC call responses. RPC calls enable decoupling and function reuse between services, allowing each service to focus on its own business logic. For example, during account login, the account login service may need to call the identity verification service's RPC to confirm whether the account has passed identity verification, and then allow login if the identity verification is successful.

[0092] For example, see Figure 3Service B includes an input / output thread (IO thread) for traffic detection and statistics and a worker thread for data caching. When the target service receives a service request from the upstream service (Service A), the target service uses the IO thread in the network layer to perform initial screening of the collected traffic to be analyzed and reports the initial screening traffic to the traffic filtering device, and uses the worker thread in the business logic as a general caching component to perform data caching processing.

[0093] Obviously, in this embodiment of the application, after the target service receives the RPC call request, the following two situations may occur:

[0094] Scenario 1: The target service needs to call another service (downstream service) to complete its business logic. In Scenario 1, there are two types of traffic. The first type of traffic is the RPC call request sent to the target service and the RPC call response returned based on the RPC call request. That is, the RPC call request and RPC call response between the target service and the upstream service. The RPC call response carries the output parameters of the RPC call request. The second type of traffic is the downstream RPC call request initiated to one or more downstream services based on the RPC call request and the RPC call response returned based on the downstream RPC call request. That is, the RPC call request and RPC call response between the target service and the downstream service.

[0095] Scenario 2: The target service does not need to call downstream services to complete its business logic. In Scenario 2, there is a type of traffic: RPC call requests and RPC call responses between the target service and the upstream service.

[0096] In scenario 2, the target traffic for traffic replay needs to include the traffic between the target service and the upstream service. However, for scenario 1 above, the target traffic for traffic replay needs to include not only the traffic between the target service and the upstream service, but also the traffic between the target service and the downstream service.

[0097] In one implementation, the target service may also need to interact with the database when processing RPC call requests to perform operations such as querying data, inserting new records, updating or deleting existing records. For example, in an account login scenario, the target service will receive search keywords, match them with relevant information of each candidate public account recorded in the database, and use the matching results as output parameters.

[0098] In one implementation, to improve response speed, reduce database pressure, and enhance system performance and user experience in high-concurrency scenarios, frequently accessed data (such as data accessed a certain number of times or with a certain access frequency reaching a certain threshold) can be cached. For example, when reading data, the data is first read from the cache; if the cache hits, it is returned directly, avoiding database queries. When data changes (such as writing, modifying, or deleting data), the data in both the database and the cache is updated to ensure data consistency.

[0099] In summary, a complete request processing flow typically involves: receiving the request and parsing the input parameters, making possible downstream service calls, interacting with the database, and finally generating and returning the output parameters based on the processing results.

[0100] S202. Based on the business parameter set carried by each of the at least one candidate service request, analyze the at least one candidate service request respectively to obtain the corresponding command coverage evaluation value. The command coverage evaluation value represents at least one business logic used to process the corresponding candidate service request.

[0101] In one implementation, considering that different values ​​of business parameters carried in a service request can reflect different branches of the business logic that handle the request to a certain extent, in this embodiment, the service request is analyzed by selecting target parameters so that the obtained command coverage evaluation value can reflect which business logics the service request covers as much as possible, thereby improving the coverage of traffic for different types of requests. The higher the coverage, the more scenarios can be replayed for verification, thus enabling traffic to cover more business scenarios and more comprehensively verifying the stability of the system.

[0102] Specifically, based on the business parameter sets carried by each of the at least one candidate service request, the at least one candidate service request is analyzed to obtain the corresponding command coverage evaluation value, including:

[0103] Based on the business parameter set carried by each of the at least one candidate service request, parameter statistics are performed to obtain each candidate business parameter. Based on the value of each candidate business parameter, at least one target parameter whose value is within the set value range is selected from each candidate business parameter.

[0104] Based on at least one selected target parameter, at least one candidate service request is analyzed to obtain the corresponding command coverage evaluation value.

[0105] One set of business parameters may contain several business parameters, and multiple sets of business parameters may contain the same business parameters. Therefore, when performing parameter statistics, the business parameters can be deduplicated, and the deduplicated business parameters can be used as candidate business parameters.

[0106] For example, a service request (Request) = Command type + Parameter list (Business parameter 1 = Parameter value 1 & Business parameter 2 = Parameter value 2 & ...). In other words, a service request contains a command type and a parameter list. The command type includes, but is not limited to, GET, POST, PUT, DELETE, etc. GET is used to request a document from the server, POST is used to send information from the client to the server, PUT is used to send a document from the server to the client, and DELETE is used to request the server to delete a specified page. The parameter list is equivalent to a set of business parameters, containing each business parameter and its possible values.

[0107] Assume that param represents the business parameters, see Table 1, which is an example of the service requests provided in the embodiments of this application. Assume that the received service requests include service request 1, service request 2, service request 3, service request 4, service request 5, etc.

[0108] Table 1 (Service Request Example)

[0109]

[0110] The candidate service requests in Table 1 include: Service Request 1, Service Request 2, and Service Request 3. Service Request 1 carries a parameter list containing param1, param2, param3, param4, and param5 and their respective values; Service Request 2 carries a parameter list containing param2, param3, param4, and param6 and their respective values; and Service Request 3 carries a parameter list containing param2, param3, param7, and param8 and their respective values. It should be noted that the values ​​of the same param in different candidate service requests may be the same or different. For example, the value2 in Service Request 1 and the value2 in Service Request 2 may be the same or different.

[0111] In this embodiment of the application, the command coverage evaluation value can be determined by statistically analyzing the parameters of all candidate service requests, or it can be determined by statistically analyzing the parameters of each type of candidate service request. The two methods will be described below.

[0112] Method 1: Perform parameter statistics and analysis on all candidate service requests.

[0113] Assuming there are n candidate service requests, perform parameter statistics on the business parameter sets carried by each of the n candidate service requests to obtain each candidate business parameter. Based on the values ​​of each candidate business parameter, select k target parameters whose values ​​are within a set range, where k is an integer. Based on the selected k target parameters, analyze each of the n candidate service requests to obtain the corresponding command coverage evaluation value.

[0114] In one possible implementation, considering that a candidate business parameter may be carried in multiple candidate service requests, and therefore, a candidate business request may correspond to multiple values, in this embodiment, the candidate business parameter whose value is in a relatively small discrete value space (e.g., the value is within a set value range) is used as the target parameter. The target parameter can also be called an enumerable parameter. Since different values ​​of enumerable type parameters are more likely to represent different branches of business logic, they better reflect the business scenarios covered by the service request, which is beneficial to improving request coverage.

[0115] See Figure 4 Taking service requests 1 through 5 as an example, the number of business parameters corresponding to service requests 1, 2, 3, 4, and 5 are 5, 4, 4, 4, and 3, respectively. By counting and deduplicating the param in the parameter list carried by each of service requests 1 through 5, 8 candidate business parameters are obtained. The 8 candidate business parameters include: param1, param2, ..., param8.

[0116] Of the eight candidate business parameters, taking only param1, param2, and param3 as examples: param1 is carried in service request 1 and service request 2, and its data type is character; param2 is carried in service request 1, service request 2, service request 3, and service request 4, and its data type is enumeration. Its value is different in service request 1, service request 2, and service request 3, but its value in service request 4 is the same as its value in service request 3; param3 is carried in service request 1, service request 2, service request 3, and service request 4, and its data type is enumeration. Its value is different in service request 1, service request 2, service request 3, and service request 4. Assuming the value range is set to -10 to 10, if the value of param3 is not within the set range, but the value of param2 is within the set range, then param2 is the target parameter.

[0117] Method 2: Perform parameter statistics and analysis for each type of candidate service request.

[0118] Based on the business type carried by each of the n candidate service requests, classify the n candidate service requests, and perform the following operations for each type of candidate service request:

[0119] Perform parameter statistics on the business parameter sets carried by each of the M candidate service requests belonging to the same command type to obtain the candidate business parameters. M is an integer, and the value of M is less than or equal to N.

[0120] Based on the values ​​of each candidate business parameter, select k target parameters whose values ​​fall within a set range, where k is an integer.

[0121] Based on the selected k target parameters, the M candidate service requests are analyzed to obtain the corresponding command coverage evaluation values.

[0122] It should be noted that in the embodiments of this application, the number of candidate service requests corresponding to each command type may be the same or different.

[0123] See Figure 5 Taking service requests 1 to 5 as examples, among the five service requests, service request 1 and service request 4 have the same command type, and service request 2 and service request 5 have the same command type. According to the business type carried by each of the five service requests, the five service requests are classified. The classification results indicate that service request 1 and service request 4 belong to the same command type, and service request 2 and service request 5 belong to the same command type. First, for service request 1 and service request 4, which contain 5 candidate business parameters: param1, param2, ..., param5, based on the values ​​of each of the 5 candidate business parameters, target parameters whose values ​​fall within a set range are selected. For service request 2 and service request 5, which contain 4 candidate business parameters: param2, param3, param4, and param6, based on the values ​​of each of the 4 candidate business parameters, target parameters whose values ​​fall within a set range are selected. For service request 3, which contains 4 candidate business parameters: param2, param3, param7, and param8, based on the values ​​of each of the 4 candidate business parameters, target parameters whose values ​​fall within a set range are selected.

[0124] In one possible implementation, based on at least one selected target parameter, at least one candidate service request is analyzed to obtain the corresponding command coverage evaluation value, specifically including:

[0125] For at least one candidate service request, perform the following operations respectively:

[0126] Based on at least one selected target parameter, a target parameter in the set of business parameters carried by a candidate service request is determined; and based on the proportion of the value types of the target parameters carried by a candidate service request in the total value types set for the target parameters, a command coverage evaluation value of a candidate service request is obtained.

[0127] The total number of possible values ​​can be preset based on the amount of business logic involved in the target service during actual application, and there is no limit to this. The total number of possible values ​​can be the same or different for multiple target parameters.

[0128] In other words, in this embodiment of the application, the proportion of the value types of the enumerable parameters contained in each candidate service request in the traffic to be analyzed to the actual value types supported by the enumerable parameters is used as the command coverage evaluation value of the candidate service request. By calculating the ratio, the business logic covered by the traffic to be analyzed can be accurately reflected, thereby improving the business coverage.

[0129] In this embodiment of the application, when calculating the command coverage evaluation value according to Method 1 and Method 2, corresponding implementation methods can be adopted respectively. For example, in Method 1, for each candidate service request, based on at least one selected target parameter, the target parameter in the business parameter set carried by the candidate service request can be determined directly, and the command coverage evaluation value of the candidate service request can be obtained based on the proportion of the value type of the target parameter carried by the candidate service request in the total value types set for the target parameter. In Method 2, for each candidate service request, based on the target parameters selected for the command type of the candidate service request, the target parameter in the business parameter set carried by the candidate service request can be determined, and then the command coverage evaluation value of a candidate service request can be obtained based on the proportion of the value type of the target parameter carried by the candidate service request in the total value types set for the target parameter.

[0130] It should be noted that, in the embodiments of this application, the types of values ​​for a target parameter can be obtained in, but are not limited to, two ways. In the first implementation, the total number of value types can be obtained by directly performing type statistics based on the values ​​of the target parameter in at least one candidate service request. For example, suppose the target parameters include param2, param4, param5, and param6, where param2 has 3 value types, param4 has 5 value types, and param5 and param6 both have 1 value type.

[0131] In the second implementation, to improve the coverage calculation speed, the values ​​of the target parameters in at least one candidate service request can be hashed to obtain the hash values ​​of at least one target parameter. Then, type statistics are performed based on the hash values ​​of at least one target parameter to obtain the total number of value types. It should be noted that the hash calculation algorithm is not limited in this embodiment and will not be described in detail here.

[0132] For example, the values ​​of param2, param4, param5, and param6 are hashed to obtain the corresponding hash values. Then, based on the obtained hash values, it is determined that the value type of param2 is 3, the value type of param4 is 5, and the value type of param5 and param6 is 1.

[0133] Furthermore, after hashing the values ​​of the Command and enumerable parameters in the candidate service requests, the hash results can be used to deduplicate at least one candidate service request. Then, based on the deduplicated candidate service requests, subsequent traffic filtering operations can be performed. Deduplication can eliminate traffic that does not improve coverage, i.e., duplicate traffic, thereby reducing redundant traffic and improving replay efficiency.

[0134] The following section uses candidate service request i as an example to illustrate the process of analyzing candidate service requests. Candidate service request i can be any one of at least one candidate service request. For candidate service request i, based on at least one selected target parameter, the target parameters in the business parameter set carried by candidate service request i are determined. Then, based on the proportion of the value types of the target parameters carried by candidate service request i in the total value types, the command coverage evaluation value of candidate service request i is obtained.

[0135] In other words, based on the proportion of the target parameter values ​​carried by candidate service request i to the total number of value types, a command coverage evaluation value for a candidate service request is obtained, specifically including:

[0136] Hash the values ​​of at least one target parameter in at least one candidate service request to obtain the hash values ​​of each target parameter; perform type statistics based on the hash values ​​of each target parameter to obtain the total number of value types; and obtain the value type of the target parameter carried by candidate service request i based on the hash values ​​of the target parameters carried by candidate service request i; and obtain the command coverage evaluation value of candidate service request i based on the proportion of the value types of the target parameters carried by candidate service request i in the total number of value types.

[0137] For example, the command coverage evaluation value of candidate service request i can be calculated using formula (1): Command coverage = Number of target parameter values ​​in candidate service request i / Total number of value values ​​Formula (1)

[0138] For example, service request 1 carries target parameters including param2, param4, and param5, the value type of the target parameters carried by service request 1 is 3, and the command coverage evaluation value of service request 1 is 3 / 7; service request 2 carries target parameters including param2, param4, and param6, the value type of the target parameters carried by service request 2 is 3, and the command coverage evaluation value of service request 2 is 3 / 7; service request 3 carries target parameter param2, the value type of the target parameter carried by service request 2 is 1, and the command coverage evaluation value of service request 3 is 1 / 7.

[0139] S203. Based on the command coverage evaluation value of each of the at least one candidate service requests, select the candidate service requests from the at least one candidate service requests whose at least one business logic satisfies the set filtering conditions, and use them as the target service requests.

[0140] For details, please refer to Figure 6 As shown, when executing S203, the following methods can be used, but are not limited to:

[0141] S2031. Based on the command coverage evaluation value of each of the at least one candidate service requests, select candidate service requests from the at least one candidate service requests whose at least one business logic satisfies the set filtering conditions as reference service requests.

[0142] In one possible implementation, when executing S2031, the following steps may be used, but are not limited to:

[0143] S20311. Based on at least one candidate service request, combine requests to obtain at least one candidate service request group, and based on the command coverage evaluation value of each candidate service request group containing candidate service requests, obtain the request coverage evaluation value of at least one candidate service request group.

[0144] In this embodiment, when combining candidate service requests, the requests can be combined according to a set maximum number of combinations. For example, assuming the maximum number of combinations is 3, then combining two candidate service requests will yield several candidate service request groups; combining three candidate service requests will yield several candidate service request groups; and combining one candidate service request will yield several candidate service request groups. Of course, in practical applications, a maximum number of combinations can be omitted, and all possible combinations of requests can be used as candidate service request groups.

[0145] For example, suppose the candidate service requests include service request 1, service request 2 and service request 3. Combining service request 1, service request 2 and service request 3 yields 7 candidate service request groups. The 7 candidate service request groups are: candidate service request group 1 (including service request 1, service request 2 and service request 3), candidate service request group 2 (including service request 1 and service request 2), candidate service request group 3 (including service request 1 and service request 3), candidate service request group 4 (including service request 2 and service request 3), candidate service request group 5 (including service request 1), candidate service request group 6 (including service request 2), and candidate service request group 7 (including service request 3).

[0146] In one possible implementation, the ratio of the sum of the command coverage evaluation values ​​of the candidate service requests included in a candidate service request group to the total number of candidate service requests can be used as the request coverage evaluation value of that candidate service request group. It should be noted that both the request coverage evaluation value and the command coverage evaluation value can be expressed in numerical or hierarchical form; this article only uses numerical form as an example and does not impose any restrictions.

[0147] For example, the requested coverage evaluation value can be calculated using formula (2):

[0148] Request coverage assessment value = Sum of command coverage assessment values ​​of candidate service requests / Total number of requests Formula (2)

[0149] For example, the command coverage evaluation value of service request 1 is 3 / 7, the command coverage evaluation value of service request 2 is 3 / 7, and the command coverage evaluation value of service request 3 is 1 / 7. Among the 7 candidate service request groups, the request coverage evaluation value of candidate service request group 1 (including service request 1, service request 2, and service request 3) is (3 / 7 + 3 / 7 + 1 / 7) / 3 = 1 / 3; the request coverage evaluation value of candidate service request group 2 (including service request 1 and service request 2) is (3 / 7 + 3 / 7) / 3 = 2 / 7; and the request coverage evaluation value of candidate service request group 3 (including service request 1, service request 2, and service request 3) is (3 / 7 + 3 / 7 + 1 / 7) / 3 = 1 / 3. Calculate the request coverage evaluation value of 3) = (3 / 7 + 1 / 7) / 3 = 4 / 21; the request coverage evaluation value of candidate service request group 4 (including service request 2 and service request 3) = (3 / 7 + 1 / 7) / 3 = 4 / 21; the request coverage evaluation value of candidate service request group 5 (including service request 1) = (3 / 7) / 3 = 1 / 7; the request coverage evaluation value of candidate service request group 6 (including service request 2) = (3 / 7) / 3 = 1 / 7; the request coverage evaluation value of candidate service request group 7 (including service request 3) = (1 / 7) / 3 = 1 / 21.

[0150] In the above implementation method, the request coverage evaluation value can be used to reflect the coverage of business logic by different request combinations, thereby quickly filtering out key traffic.

[0151] S20312. Based on at least one obtained request coverage evaluation value, select candidate service request groups from at least one candidate service request group whose request coverage evaluation value exceeds a set evaluation value threshold, and use the candidate service requests in the selected candidate service request groups as reference service requests.

[0152] In this embodiment of the application, when screening candidate service request groups, if the request coverage evaluation value of a candidate service request group exceeds the set evaluation value threshold, then the candidate service request group is directly used as the screened candidate service request group. If the request coverage evaluation values ​​of multiple candidate service request groups exceed the set evaluation value threshold, then the candidate service request group with the highest request coverage evaluation value among the multiple candidate service request groups can be used as the screened candidate service request group, or any one of the multiple candidate service request groups can be used as the screened candidate service request group, but it is not limited to this.

[0153] For example, assuming the evaluation threshold is 14 / 21, then based on the request coverage evaluation values ​​of the seven candidate service request groups, candidate service request group 1 with a request coverage evaluation value exceeding the set 14 / 21 is selected from the seven candidate service request groups, and service request 1, service request 2, and service request 3 in candidate service request group 1 are used as reference service requests.

[0154] S2032. Perform pre-replay on at least one selected reference service request, and based on the obtained pre-replay results, select at least one target service request that was successfully pre-replayed from at least one reference service request.

[0155] To reduce the probability of replay failure, this embodiment of the application performs pre-replay for each reference service request, and filters the final traffic data based on the pre-replay results. Specifically, for at least one filtered reference service request, the following operations are performed:

[0156] First, based on a reference service request, multiple requests are sent to the target service to obtain the pre-replay results corresponding to each of the multiple requests. Each pre-replay result contains various result fields.

[0157] Secondly, based on the values ​​of each result field contained in the multiple pre-playback results, the multiple pre-playback results are compared to obtain the comparison results;

[0158] Finally, based on the comparison results, at least one target service request that was successfully pre-replayed is selected from at least one reference service request.

[0159] Based on the comparison results, when selecting at least one target service request that has been successfully pre-replayed from at least one reference service request, as a possible case, if there is no random field with different values ​​in multiple pre-replay results among the result fields of the comparison results, then one reference service request will be selected as the target service request that has been successfully pre-replayed.

[0160] For ease of description, we will use reference service request i as an example below. Reference service request i can be any one of the at least one selected reference service requests.

[0161] Based on the reference service request i, multiple requests are initiated to the target service to obtain the pre-replay results corresponding to each request. Each pre-replay result contains P result fields. Then, based on the values ​​of the P result fields contained in each of the multiple pre-replay results, the multiple pre-replay results are compared to obtain a comparison result. It should be noted that, in this embodiment of the application, when comparing multiple pre-replay results, specifically, the values ​​of the P result fields can be compared to see if they are the same in the multiple pre-replay results.

[0162] For example, based on service request 1, three requests are made to the target service to obtain the pre-replay results corresponding to the three requests. Each pre-replay result contains 10 result fields. Then, based on the values ​​of the 10 result fields in the three pre-replay results, the three pre-replay results are compared to obtain the comparison results. The comparison results indicate that: field 1 has different values ​​in all three pre-replay results, fields 2 and 3 have different values ​​in two of the pre-replay results, and the remaining fields have the same values ​​in all three pre-replay results.

[0163] In this embodiment, during comparison, if a result field has different values ​​in multiple pre-playback results, then that result field can be determined as unmatched. Unmatched result fields can also be called random fields. In other words, result fields with different values ​​in multiple pre-playback results can be called random fields. It should be noted that "different values ​​in multiple pre-playback results" can be understood as the result field having different values ​​in all of the pre-playback results, or it can be understood as the result field having different values ​​in some of the pre-playback results. This document only uses the example of "a result field with different values ​​in all of the pre-playback results being called a random field" for illustration. For example, among 10 result fields, field 1 has different values ​​in all three pre-playback results, fields 2 and 3 have different values ​​in two of the pre-playback results, and the remaining fields have the same value in the three pre-playback results. Therefore, field 1 can be called a random field.

[0164] In one possible scenario, if the comparison results indicate that no random field exists among the P result fields, then the reference service request i is taken as the pre-replay successful service request; that is, the reference service request i is the filtered target service request. By pre-replaying and using the pre-replay successful service request as the target service request, traffic for replay can be quickly filtered while ensuring successful replay, thereby improving the success rate of traffic replay.

[0165] Furthermore, if the comparison results indicate that one or more random fields exist among the P result fields, one possible implementation is to directly treat the reference service request i as a service request that did not succeed in pre-replay; that is, the reference service request i is not used as the target service request. Another possible implementation is to use the random fields as temporary matching rules, then use these temporary matching rules to replay the traffic again, and based on the replay results, determine whether to treat the reference service request i as a service request that succeeded in pre-replay.

[0166] Specifically, multiple requests are re-initiated based on the reference service request i to obtain multiple new pre-replay results. Then, based on the values ​​of the fields other than at least one random field in each result field of the multiple new pre-replay results, the multiple new pre-replay results are compared to obtain new comparison results. When the new comparison results indicate that there is no random field in other fields, the reference service request i is taken as the target service request for successful pre-replay.

[0167] In this embodiment, a random field can be recorded in a temporary matching rule. Then, the temporary matching rule is used to replay the reference service request i. If the replay is successful, the temporary rule is considered valid and is stored in the final matching rule. This way, during replay, the final matching rule can be used to replay the reference service request i, thus avoiding replay failure. Furthermore, when a service request of the same type as the reference service request i is collected again, the final matching rule can be used to replay the newly collected service request of the same type as the reference service request i.

[0168] See Figure 7 As shown, this is a logical diagram of a pre-playback process provided in an embodiment of this application. Based on service request 1, three requests are initiated to the target service to obtain the pre-playback results corresponding to the three requests. Each pre-playback result contains 10 result fields. Then, based on the values ​​of the 10 result fields in the three pre-playback results, the three pre-playback results are compared to obtain a comparison result. The comparison result indicates that: field 1 in the 10 result fields has different values ​​in all three pre-playback results; fields 2 and 3 have different values ​​in two of the pre-playback results; and the values ​​of the remaining fields are the same in the three pre-playback results. At this time, the comparison result indicates that there is a random field among the 10 result fields, and the random field is field 1.

[0169] Then, field 1 is added to the temporary matching rule, and multiple requests are re-initiated based on service request 1 to obtain multiple new pre-replay results. Then, based on the values ​​of all fields other than field 1 in each result field of these new pre-replay results, the multiple new pre-replay results are compared to obtain new comparison results. When the new comparison results indicate that no random field exists in other fields, service request 1 is taken as the target service request for successful pre-replay. In other words, during the analysis and comparison process, the random field (i.e., field 1) in the temporary rule is filtered out. If all fields other than field 1 match in each result field, the pre-replay of service request 1 is successful. Furthermore, the temporary matching rule can also be used as the final matching rule, and the final matching rule includes field 1.

[0170] In the above implementation, if some fields are randomly generated, such as the Universally Unique Identifier (UUID) field, the UUID can be a unique value randomly generated for replay protection. By extracting matching rules to shield the influence of these random fields, the probability of replay failure can be effectively reduced. Furthermore, during formal replay, the final matching rules can be used to replay the reference service request i, thereby avoiding replay failure, improving the replay effect, and achieving accurate filtering of target traffic. At the same time, the automated matching rule generation method can reduce the workload of data analysis and improve efficiency and consistency.

[0171] For traffic that cannot be successfully replayed using matching rules, there may be various reasons for the failure. For example, it could be due to network latency, packet loss, hardware failure leading to incomplete traffic recording, or it could be dependent on other environmental factors. For traffic that still cannot be successfully replayed using matching rules, detailed analysis and investigation can be conducted to identify the specific reasons for the failure. In this embodiment, this portion of traffic can be directly filtered out to ensure the efficiency and accuracy of traffic replay.

[0172] It should be noted that the comparison process mentioned above is only used as an example of sending a service request to the target service and returning a service response based on the service request. Therefore, comparing multiple pre-replay results (i.e., the service responses received during the pre-replay process for the received service request) means comparing the fields of the service responses of multiple received service requests initiated during the pre-replay process without involving downstream service calls.

[0173] However, in practical applications, if downstream service calls are involved, the pre-replay process involves not only returning a service response based on the initial service request, but also initiating downstream service requests to one or more downstream services and returning service responses based on those downstream service requests. In this case, the comparison can not only compare the fields of the service responses to multiple received service requests during the pre-replay process, but also further compare the fields of the initiated downstream service requests. For example, the fields in the downstream service requests can be called request fields. Based on the values ​​of each request field contained in each downstream service request, the downstream service requests are compared to obtain comparison results. Then, the comparison results of the downstream service requests and the pre-replay results are combined to determine the overall comparison result. The overall comparison result describes whether random fields exist in each result field and each request field. However, if random fields exist, they are used as temporary matching rules. Traffic is replayed again using these temporary matching rules, and based on the replay results, it is determined whether to consider the reference service request as a successfully pre-replayed service request. Since the process of comparing downstream service requests based on the values ​​of each request field contained in each downstream service request to obtain the comparison result is similar to the process of comparing multiple pre-replay results based on the values ​​of each result field contained in each of the obtained pre-replay results to obtain the comparison result, it will not be described in detail here.

[0174] S204. Based on the obtained at least one target service request, and in combination with the service responses collected for each of the at least one target service requests, obtain the target traffic for traffic replay.

[0175] In one possible implementation, the service response of at least one target service request is cached as the service response collected for each of the at least one target service request, and the target traffic for traffic replay is obtained based on the at least one target service request and its corresponding service response.

[0176] In real-world scenarios, the use of cached data often leads to incomplete downstream traffic. Therefore, see [link / reference needed]. Figure 3 A general-purpose caching component was designed. When it is recognized that the request is initiated by recorded traffic, the cached data will be ignored and an RPC call will be forced, thus obtaining a complete call chain.

[0177] In another possible implementation, requests are sent to the target service based on at least one target service request, the corresponding service responses are collected, and the target traffic for traffic replay is obtained based on the obtained at least one target service request and its corresponding service response.

[0178] In some implementations, system network traffic can be monitored and analyzed in real time to quickly identify critical traffic. For example, real-time detection can be achieved by adjusting the traffic collection cycle.

[0179] The following description uses a specific embodiment as an example.

[0180] See Figure 8 As shown, it is a logical schematic diagram of a traffic recording and playback process provided in an embodiment of this application. Figure 8 It includes services A, B and C that provide different business services using a microservice architecture, a traffic filtering device (server), and a playback system with a playback environment.

[0181] When service A needs to call service B, service A sends an RPC call request to service B. After receiving the RPC call request, service B performs business processing according to the RPC call request and returns the corresponding RPC call response. Similarly, when service B needs to call service C, service B sends an RPC call request to service C. After receiving the RPC call request, service C performs business processing according to the RPC call request and returns the corresponding RPC call response.

[0182] Service B collects the traffic to be analyzed within a set collection period, and analyzes each candidate service request based on the business parameter set carried by each candidate service request in the traffic to be analyzed, and obtains the command coverage evaluation value corresponding to each candidate service request. Then, based on each candidate service request, requests are combined to obtain multiple candidate service request groups. Based on the command coverage evaluation value of each candidate service request group, the request coverage evaluation value of multiple candidate service request groups is obtained. Based on the obtained multiple request coverage evaluation values, candidate service request groups whose request coverage evaluation value exceeds the set evaluation value threshold are selected from the multiple candidate service request groups, and the reference service request in the selected candidate service request group is used as the reference service request.

[0183] Furthermore, Service B initiates requests to the target service based on each reference service request, collects the corresponding service responses, and sends the reference service requests and their corresponding service responses to the traffic filtering device.

[0184] Traffic filtering devices (such as servers used for traffic filtering) mainly involve pre-playback and playback processes. During pre-playback, after receiving a reference service request and its corresponding service response, the traffic filtering device first generates matching rules, see [link to relevant documentation]. Figure 9 Specifically, firstly, through the replay module, for each reference service request (i.e. Figure 9The process involves several steps. First, the system initiates multiple requests to the target service based on a reference service request, obtaining pre-replay results for each request. Second, the analysis module compares these pre-replay results based on the values ​​of each result field, obtaining comparison results. When a random field is found in the result field, it is recorded in a temporary matching rule. Then, the replay module uses the temporary matching rule to replay the traffic again. Based on the comparison results of this second replay, it determines whether to accept the reference service request as a successfully replayed service request. If the comparison results of the second replay indicate successful replay (i.e., no random field exists), the reference service request is accepted as the target service request. If the comparison results of the second replay indicate failed replay (i.e., random field still exists), the reference service request is filtered out. Furthermore, the final matching rule can be generated based on the comparison results of the second replay, and this matching rule can be used in subsequent replay processes.

[0185] During playback, the traffic filtering device can perform one or more tests on the target service, such as functional regression testing, stability testing, and performance load testing, but is not limited to these. It should be noted that both pre-playback and playback are conducted within the playback system.

[0186] Based on the same inventive concept, embodiments of this application provide a flow filtering device. For example... Figure 10 As shown, this is a schematic diagram of the flow filtering device 1000, which may include:

[0187] Traffic acquisition unit 1001 is used to acquire traffic to be analyzed within a set collection period. The traffic to be analyzed includes at least one candidate service request, and each candidate service request carries a corresponding set of business parameters.

[0188] The request analysis unit 1002 is used to analyze the at least one candidate service request based on the business parameter set carried by each of the at least one candidate service requests, and obtain the corresponding command coverage evaluation value. The command coverage evaluation value represents at least one business logic used to process the corresponding candidate service request.

[0189] The request filtering unit 1003 is used to filter out candidate service requests from the at least one candidate service requests based on the command coverage evaluation value of each of the at least one candidate service requests, and select candidate service requests whose at least one business logic satisfies the set filtering conditions as target service requests.

[0190] The traffic recording unit 1004 is used to obtain target traffic for traffic replay based on at least one target service request and the service responses collected for each target service request.

[0191] In one possible implementation, when analyzing the at least one candidate service request based on the service parameter set carried by each of the at least one candidate service requests to obtain the corresponding command coverage evaluation value, the request analysis unit 1002 is specifically used for:

[0192] Based on the service parameter sets carried by each of the at least one candidate service requests, parameter statistics are performed to obtain each candidate service parameter. Based on the values ​​of each candidate service parameter, at least one target parameter whose value is within a set value range is selected from the candidate service parameters.

[0193] Based on the selected at least one target parameter, the at least one candidate service request is analyzed to obtain the corresponding command coverage evaluation value.

[0194] In one possible implementation, when analyzing the at least one candidate service request based on the selected at least one target parameter to obtain the corresponding command coverage evaluation value, the request analysis unit 1002 is specifically used for:

[0195] For each of the at least one candidate service request, perform the following operations:

[0196] Based on the selected at least one target parameter, a target parameter is determined from the set of business parameters carried by a candidate service request;

[0197] Based on the proportion of the target parameter value types carried in the candidate service request to the total number of value types set for the target parameter, the command coverage evaluation value of the candidate service request is obtained.

[0198] In one possible implementation, when obtaining the command coverage evaluation value of a candidate service request based on the proportion of the value types of the target parameter carried in the candidate service request to the total value types set for the target parameter, the request analysis unit 1002 is specifically used for:

[0199] Hash the values ​​of the at least one target parameter in the at least one candidate service request to obtain the hash values ​​of the at least one target parameter respectively;

[0200] Based on the hash values ​​of the at least one target parameter, type statistics are performed to obtain the total number of value types; and based on the hash values ​​of the target parameters carried in the candidate service request, the value types of the target parameters carried in the candidate service request are obtained.

[0201] Based on the number of target parameter values ​​carried in a candidate service request and their proportion in the total number of value types, the command coverage evaluation value of the candidate service request is obtained.

[0202] In one possible implementation, based on the command coverage evaluation value of each of the at least one candidate service requests, when selecting candidate service requests from the at least one candidate service requests whose at least one business logic satisfies the set filtering conditions as the target service requests, the request filtering unit 1003 is specifically used for:

[0203] Based on the command coverage evaluation value of each of the at least one candidate service requests obtained, candidate service requests that use at least one business logic that meets the set filtering conditions are selected from the at least one candidate service requests as reference service requests.

[0204] Each of the selected reference service requests is pre-played, and based on the pre-playback results, at least one target service request that was successfully pre-played is selected from the at least one reference service request.

[0205] In one possible implementation, when selecting candidate service requests from the at least one candidate service requests that use at least one business logic that satisfies the set filtering conditions as reference service requests based on the command coverage evaluation values ​​of each of the at least one candidate service requests, the request filtering unit 1003 is specifically used for:

[0206] Based on the at least one candidate service request, requests are combined to obtain at least one candidate service request group, and based on the command coverage evaluation value of each candidate service request group containing candidate service requests, the request coverage evaluation value of the at least one candidate service request group is obtained.

[0207] Based on at least one obtained request coverage evaluation value, candidate service request groups whose request coverage evaluation values ​​exceed a set evaluation value threshold are selected from the at least one candidate service request group, and reference service requests in the selected candidate service request groups are used as reference service requests.

[0208] In one possible implementation, when pre-playing the at least one selected reference service request and, based on the obtained pre-playback results, selecting at least one target service request from the at least one reference service request that was successfully pre-played back, the request filtering unit 1003 is specifically used for:

[0209] For each of the at least one selected reference service request, perform the following operations:

[0210] Based on a reference service request, multiple requests are made to the target service to obtain the pre-replay results corresponding to each of the multiple requests. Each pre-replay result contains various result fields.

[0211] Based on the values ​​of each result field contained in each of the multiple pre-playback results, the multiple pre-playback results are compared to obtain a comparison result;

[0212] If the comparison result indicates that there is no random field with different values ​​in the multiple pre-replay results, then the reference service request will be taken as the target service request for successful pre-replay.

[0213] In one possible implementation, the request filtering unit 1003 is further used for:

[0214] If the comparison result indicates that there is at least one random field in each result field, then multiple requests are re-initiated based on the reference service request to obtain multiple new pre-replay results;

[0215] Based on the values ​​of the fields other than the at least one random field in each of the multiple new pre-playback results, the multiple new pre-playback results are compared to obtain a new comparison result. When the new comparison result indicates that there is no random field in the other fields, the reference service request is taken as the target service request for successful pre-playback.

[0216] In one possible implementation, when obtaining the target traffic for traffic replay based on at least one target service request and the service responses collected for each of the at least one target service request, the traffic recording unit 1004 is specifically used for:

[0217] The cached service responses of the at least one target service request are used as the service responses collected for each of the at least one target service request, and based on the obtained at least one target service request and its corresponding service response, the target traffic for traffic replay is obtained; or,

[0218] Requests are sent to the target service based on the at least one target service request, the corresponding service responses are collected, and the target traffic for traffic replay is obtained based on the at least one target service request and its corresponding service response.

[0219] For ease of description, the above sections are divided into modules (or units) according to their functions and described separately. Of course, in implementing this application, the functions of each module (or unit) can be implemented in one or more software or hardware components.

[0220] Regarding the apparatus in the above embodiments, the specific manner in which each unit executes the request has been described in detail in the embodiments related to the method, and will not be elaborated here.

[0221] Those skilled in the art will understand that various aspects of this application can be implemented as a system, method, or program product. Therefore, various aspects of this application can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combination of hardware and software implementations, collectively referred to herein as a "circuit," "module," or "system."

[0222] Based on the same inventive concept, embodiments of this application also provide an electronic device. In one embodiment, the electronic device can be a server or a terminal device. See also... Figure 11 As shown, it is a schematic diagram of the structure of a possible electronic device provided in an embodiment of this application. Figure 11 In the electronic device 1100, there are: processor 1110 and memory 1120.

[0223] The memory 1120 stores a computer program that can be executed by the processor 1110. The processor 1110 can execute the steps of the above-described summary generation method by executing the instructions stored in the memory 1120.

[0224] Memory 1120 may be volatile memory, such as random-access memory (RAM); memory 1120 may also be non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD); or memory 1120 may be any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto. Memory 1120 may also be a combination of the above-described memories.

[0225] Processor 1110 may include one or more central processing units (CPUs) or digital processing units, etc. Processor 1110 implements the above-described summary generation method when executing a computer program stored in memory 1120.

[0226] In some embodiments, the processor 1110 and the memory 1120 may be implemented on the same chip, while in other embodiments they may be implemented on separate chips.

[0227] This application embodiment does not limit the specific connection medium between the processor 1110 and the memory 1120. This application embodiment takes the connection between the processor 1110 and the memory 1120 via a bus as an example. Figure 11 The diagram uses thick lines to describe the connections between other components; these are merely illustrative and not intended to be limiting. Buses can be categorized as address buses, data buses, control buses, etc. For ease of description, Figure 11 It is described using only a thick line, but does not indicate that there is only one bus or one type of bus.

[0228] Based on the same inventive concept, embodiments of this application provide a computer-readable storage medium including a computer program. When the computer program is run on an electronic device, it causes the electronic device to perform the steps of the aforementioned traffic filtering method. In some possible implementations, various aspects of the traffic filtering method provided in this application can also be implemented as a program product including a computer program. When the program product is run on an electronic device, the computer program causes the electronic device to perform the steps in the aforementioned traffic filtering method. For example, the electronic device can perform actions such as... Figure 2 The steps are shown in the figure.

[0229] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: electrical connections having one or more wires, portable disks, hard disks, RAM, ROM, erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0230] The program product of the embodiments of this application may be a CD-ROM and include a computer program, and may run on an electronic device. However, the program product of this application is not limited thereto. In this document, the readable storage medium may be any tangible medium that contains or stores a computer program that may be used by or in conjunction with a command execution system, apparatus, or device.

[0231] A readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying a readable computer program. This propagated data signal may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting a computer program for use by or in conjunction with a command execution system, apparatus, or device.

[0232] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0233] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A traffic filtering method, characterized in that, include: Acquire the traffic to be analyzed within a set collection period. The traffic to be analyzed includes at least one candidate service request, and each candidate service request carries a corresponding set of business parameters. Based on the business parameter set carried by each of the at least one candidate service request, the at least one candidate service request is analyzed to obtain the corresponding command coverage evaluation value. The command coverage evaluation value represents at least one business logic used to process the corresponding candidate service request. Based on the command coverage evaluation value of each of the at least one candidate service requests, select the candidate service requests from the at least one candidate service requests whose at least one business logic satisfies the set filtering conditions, and use them as the target service requests. Based on at least one target service request obtained, and combined with the service responses collected for each of the at least one target service request, the target traffic for traffic replay is obtained.

2. The method as described in claim 1, characterized in that, The step of analyzing the at least one candidate service request based on the service parameter set carried by each of the at least one candidate service requests to obtain the corresponding command coverage evaluation value includes: Based on the service parameter sets carried by each of the at least one candidate service requests, parameter statistics are performed to obtain each candidate service parameter. Based on the values ​​of each candidate service parameter, at least one target parameter whose value is within a set value range is selected from the candidate service parameters. Based on the selected at least one target parameter, the at least one candidate service request is analyzed to obtain the corresponding command coverage evaluation value.

3. The method as described in claim 2, characterized in that, The step of analyzing the at least one candidate service request based on the selected at least one target parameter to obtain the corresponding command coverage evaluation value includes: For each of the at least one candidate service request, perform the following operations: Based on the selected at least one target parameter, a target parameter is determined from the set of business parameters carried by a candidate service request; Based on the proportion of the target parameter value types carried in the candidate service request to the total number of value types set for the target parameter, the command coverage evaluation value of the candidate service request is obtained.

4. The method as described in claim 3, characterized in that, The method of obtaining the command coverage evaluation value of a candidate service request based on the proportion of the value types of the target parameter carried in the candidate service request to the total value types set for the target parameter includes: Hash the values ​​of the at least one target parameter in the at least one candidate service request to obtain the hash values ​​of the at least one target parameter respectively; Based on the hash values ​​of the at least one target parameter, type statistics are performed to obtain the total number of value types; and based on the hash values ​​of the target parameters carried in the candidate service request, the value types of the target parameters carried in the candidate service request are obtained. Based on the number of target parameter values ​​carried in a candidate service request and their proportion in the total number of value types, the command coverage evaluation value of the candidate service request is obtained.

5. The method according to any one of claims 1-4, characterized in that, Based on the command coverage evaluation values ​​of each of the at least one candidate service requests, candidate service requests whose at least one business logic satisfies the set filtering conditions are selected from the at least one candidate service requests as target service requests, including: Based on the command coverage evaluation value of each of the at least one candidate service requests obtained, candidate service requests that use at least one business logic that meets the set filtering conditions are selected from the at least one candidate service requests as reference service requests. Each of the selected reference service requests is pre-played, and based on the pre-playback results, at least one target service request that was successfully pre-played is selected from the at least one reference service request.

6. The method as described in claim 5, characterized in that, The step of selecting candidate service requests as reference service requests based on the command coverage evaluation values ​​of each of the at least one candidate service requests includes: Based on the at least one candidate service request, requests are combined to obtain at least one candidate service request group, and based on the command coverage evaluation value of each candidate service request group containing candidate service requests, the request coverage evaluation value of the at least one candidate service request group is obtained. Based on at least one obtained request coverage evaluation value, candidate service request groups whose request coverage evaluation values ​​exceed a set evaluation value threshold are selected from the at least one candidate service request group, and reference service requests in the selected candidate service request groups are used as reference service requests.

7. The method as described in claim 6, characterized in that, The step of pre-playing back at least one selected reference service request and, based on the pre-playback results, selecting at least one target service request from the at least one reference service request that was successfully pre-played back includes: For each of the at least one selected reference service request, perform the following operations: Based on a reference service request, multiple requests are made to the target service to obtain the pre-replay results corresponding to each of the multiple requests. Each pre-replay result contains various result fields. Based on the values ​​of each result field contained in each of the multiple pre-playback results, the multiple pre-playback results are compared to obtain a comparison result; If the comparison result indicates that there is no random field with different values ​​in the multiple pre-replay results, then the reference service request will be taken as the target service request for successful pre-replay.

8. The method as described in claim 7, characterized in that, Also includes: If the comparison result indicates that there is at least one random field in each result field, then multiple requests are re-initiated based on the reference service request to obtain multiple new pre-replay results; Based on the values ​​of the fields other than the at least one random field in each of the multiple new pre-playback results, the multiple new pre-playback results are compared to obtain a new comparison result. When the new comparison result indicates that there is no random field in the other fields, the reference service request is taken as the target service request for successful pre-playback.

9. The method according to any one of claims 1-4, characterized in that, The step of obtaining target traffic for traffic replay based on at least one target service request and the service responses collected for each target service request includes: The cached service responses of the at least one target service request are used as the service responses collected for each of the at least one target service request, and based on the obtained at least one target service request and its corresponding service response, the target traffic for traffic replay is obtained; or, Requests are sent to the target service based on the at least one target service request, the corresponding service responses are collected, and the target traffic for traffic replay is obtained based on the at least one target service request and its corresponding service response.

10. A flow rate filtering device, characterized in that, include: The traffic acquisition unit is used to acquire the traffic to be analyzed within a set collection period. The traffic to be analyzed includes at least one candidate service request, and each candidate service request carries a corresponding set of business parameters. The request analysis unit is used to analyze the at least one candidate service request based on the business parameter set carried by each of the at least one candidate service requests, and obtain the corresponding command coverage evaluation value. The command coverage evaluation value represents at least one business logic used to process the corresponding candidate service request. The request filtering unit is used to filter out candidate service requests from the at least one candidate service requests based on the command coverage evaluation value of each of the at least one candidate service requests obtained, and select the candidate service requests whose at least one business logic satisfies the set filtering conditions as the target service requests. The traffic recording unit is used to obtain target traffic for traffic replay based on at least one target service request and the service responses collected for each target service request.

11. An electronic device, characterized in that, It includes a processor and a memory, wherein the memory stores a computer program that, when executed by the processor, causes the processor to perform the steps of the method as described in any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, It includes a computer program that, when run on an electronic device, causes the electronic device to perform the steps of the method as described in any one of claims 1 to 9.

13. A computer program product, characterized in that, It includes a computer program stored in a computer-readable storage medium, and a processor of an electronic device reads from and executes the computer program, causing the electronic device to perform the steps of the method as described in any one of claims 1 to 9.

Images