A traffic data screening method, device, equipment and storage medium

Abstract

The application provides a traffic data screening method and device, equipment and a storage medium. The method comprises the following steps: obtaining original traffic data associated with a specified service scenario, and a screening strategy preset for the service scenario, wherein the screening strategy comprises a traffic screening process determined for the service scenario, the traffic screening process is a plurality of selected strategy operators corresponding to the service scenario, and the selected plurality of strategy operators are combined according to an indicated operator association relationship to generate. Since each strategy operator represents a single unit operation determined for the original traffic data in the service scenario, each unit operation is used to realize a corresponding processing logic for traffic data screening, thereby improving the development efficiency of a single screening strategy. Furthermore, the unit operation can be reused in different service scenarios, so that resource waste caused by repeated development of the same processing logic can be avoided when developing multiple screening strategies, and the resource utilization rate is improved.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method, apparatus, device and storage medium for filtering traffic data. Background Technology

[0002] Currently, after collecting raw traffic data, online servers can use traffic filtering strategies developed for corresponding business scenarios to filter out accurate traffic data that matches the business scenario from the raw traffic data.

[0003] For example, after collecting the raw traffic data of its own game service, the online server can use the following traffic filtering strategy developed for the corresponding regression testing scenario: "Obtain the code coverage data of the raw traffic data, calculate the similarity between the code coverage data and the code coverage data of the preset traffic test cases, and remove the raw traffic data when the similarity is greater than the preset threshold; otherwise, retain the raw traffic data." This allows for the filtering of accurate traffic data that matches the regression testing scenario from the raw traffic data, that is, accurate traffic data that supports regression testing of the game service.

[0004] However, when business scenarios change, it is necessary to redevelop the corresponding traffic filtering strategy, which results in high manpower and time costs and affects filtering efficiency. Summary of the Invention

[0005] This application provides a method, apparatus, electronic device, and storage medium for filtering traffic data, which reduces the human and time costs required for strategy development and improves filtering efficiency.

[0006] The specific technical solutions provided in this application are as follows:

[0007] Firstly, a method for filtering traffic data is proposed, including:

[0008] Get the raw traffic data associated with the specified business scenario and the filtering strategy preset for the business scenario. The filtering strategy is generated by selecting multiple strategy operators for the corresponding business scenario and combining the selected multiple strategy operators according to the indicated operator association relationship. Each strategy operator represents a unit operation used for the raw traffic data in the business scenario. Each unit operation is used to implement a corresponding processing logic for filtering traffic data.

[0009] Based on the operator association, the unit operations in the filtering strategy are executed on the original traffic data until the execution completion information of the filtering strategy is obtained, and the corresponding strategy output data is obtained. The strategy output data is then used as accurate traffic data that matches the business scenario.

[0010] Secondly, a data filtering device for traffic flow is proposed, comprising:

[0011] The strategy acquisition module is used to acquire the raw traffic data associated with a specified business scenario, as well as the filtering strategy preset for the business scenario. The filtering strategy is generated by selecting multiple strategy operators for the corresponding business scenario and combining the selected multiple strategy operators according to the indicated operator association relationship. Each strategy operator represents a unit operation used for the raw traffic data in the business scenario. Each unit operation is used to implement a corresponding processing logic for filtering traffic data.

[0012] The execution module is used to perform the unit operations in the filtering strategy on the raw traffic data according to the operator association relationship until the execution completion information of the filtering strategy is obtained, the corresponding strategy output data is obtained, and the strategy output data is used as accurate traffic data that matches the business scenario.

[0013] In one possible implementation, before obtaining the preset filtering strategy for the business scenario, the strategy acquisition module is further configured to:

[0014] Obtain strategy description information determined for the business scenario. The strategy description information includes: multiple functions to be executed determined for the business scenario, and each function to be executed is associated with a processing logic for filtering traffic data.

[0015] Select multiple strategy operators associated with multiple functions to be executed from the preset set of operators;

[0016] In response to orchestration configuration operations triggered for multiple policy operators, the operator relationships between the multiple policy operators are determined, and the multiple policy operators are combined according to the operator relationships to generate corresponding filtering strategies.

[0017] In one possible implementation, in response to an orchestration configuration operation triggered for multiple policy operators, the policy acquisition module determines the operator association relationships among the multiple policy operators, and is used to:

[0018] In response to a selection operation triggered for multiple policy operators, at least two sets of policy operators are determined;

[0019] In response to an orchestration configuration operation triggered for at least two policy operator subsets, determine the association between the at least two policy operator subsets, as well as the association between each policy operator in each policy operator subset.

[0020] In one possible implementation, in response to an orchestration configuration operation triggered for at least two policy operator subsets, the association between the at least two policy operator subsets and the association between each policy operator in each policy operator subset are determined, including any of the following:

[0021] In response to a phase configuration operation triggered for at least two policy operator subsets, determine that the association between the at least two policy operator subsets is a serial relationship, and that the association between each policy operator in each policy operator subset is a serial relationship;

[0022] In response to a task configuration operation triggered for at least two policy operator subsets, determine that the association between the at least two policy operator subsets is a parallel relationship, and the association between each policy operator in each policy operator subset is a serial relationship;

[0023] In response to a default configuration operation triggered for at least two policy operator subsets, determine that the association between the at least two policy operator subsets is a serial relationship, and that the association between each policy operator in each policy operator subset is a serial relationship.

[0024] In one possible implementation, after generating the corresponding filtering strategy, the strategy acquisition module is further used to: encapsulate the filtering strategy and obtain a strategy plugin;

[0025] The module retrieves the pre-defined scheduling strategy for the business scenario. The strategy retrieval module is used for:

[0026] Obtain the pre-defined strategy plugins for the business scenario; the strategy plugins carry filtering strategies.

[0027] The policy plugin is loaded using a preset policy loader to obtain the filtering policy.

[0028] In one possible implementation, each candidate plugin carries a preset candidate strategy for a candidate scenario. Each candidate strategy includes a candidate filtering process determined for the corresponding candidate scenario. The candidate filtering process is generated by selecting multiple strategy operators for a corresponding candidate scenario and combining the selected multiple candidate operators according to the indicated candidate association relationship. Each candidate operator represents a unit operation determined for the original traffic data in the corresponding candidate scenario.

[0029] After the strategy output data is used as accurate traffic data that matches the business scenario, the execution module is also used for:

[0030] In response to a scheduling request carrying a plugin identifier with multiple candidate plugins, each candidate plugin of each plugin identifier is scheduled according to the indicated plugin scheduling relationship. Each time a scheduling is performed, the following operations are performed: according to the candidate association relationship in the candidate plugin, the corresponding unit operation in the candidate strategy is executed on the raw traffic data.

[0031] Until the scheduling completion information of each candidate plugin is obtained, the corresponding candidate output data is obtained, and the candidate output data is used as accurate traffic data that matches the business scenario.

[0032] In one possible implementation, after processing the candidate output data as precise traffic data that matches the business scenario, the execution module is further used to:

[0033] In response to a plugin recommendation request, obtain key information for each of the multiple candidate plugins. Each key information includes at least: parameter information of the corresponding candidate plugin and historical loading information of the corresponding candidate plugin.

[0034] Based on the key information, the plugin evaluation values ​​of multiple candidate plugins are obtained, and the multiple candidate plugins are sorted in descending order according to the evaluation values ​​of each plugin.

[0035] From multiple candidate plugins, select at least one candidate plugin that meets the preset sorting criteria as the target plugin;

[0036] It is recommended to select at least one target plugin.

[0037] In one possible implementation, based on each key piece of information, the plugin evaluation value for each of the multiple candidate plugins is obtained, and the execution module is used to:

[0038] For multiple candidate plugins, perform the following operations respectively:

[0039] According to the preset evaluation rules, the parameter information of a candidate plugin is evaluated to obtain the parameter evaluation value of the candidate plugin. According to the evaluation rules, the historical loading information of a candidate plugin is evaluated to obtain the performance evaluation value of the candidate plugin.

[0040] The parameter evaluation value and performance evaluation value are weighted and summed to obtain the plugin evaluation value of a candidate plugin.

[0041] Thirdly, an electronic device is proposed, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of any of the above methods.

[0042] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program executable by a computer device, which, when run on the computer device, causes the computer device to perform the steps of the above-described traffic data filtering method.

[0043] Fifthly, embodiments of this application provide a computer program product, which includes a computer program stored on a computer-readable storage medium. The computer program includes program instructions, which, when executed by a computer, cause the computer to perform the steps of the above-described method for filtering traffic data.

[0044] The beneficial effects of this application are as follows:

[0045] This application provides a method, apparatus, electronic device, and storage medium for filtering traffic data. The method can be applied to electronic devices such as servers. It includes acquiring raw traffic data associated with a specified business scenario and a preset filtering strategy for the business scenario. The filtering strategy includes a traffic filtering process determined for the business scenario. The traffic filtering process is generated by selecting multiple strategy operators corresponding to the business scenario and combining the selected multiple strategy operators according to the indicated operator association relationship. For example, the client can select multiple strategy operators associated with the business scenario and indicate the operator association relationship. Then, the filtering strategy is generated by combining the selected multiple strategy operators according to the operator association relationship. Therefore, for the raw traffic data, the unit operation represented by each strategy operator in the filtering strategy is executed according to the operator association relationship. Each unit operation is used to implement a corresponding processing logic for filtering traffic data, which is equivalent to reproducing the traffic filtering process in the traffic filtering strategy associated with the specified business scenario for the raw traffic data. For example, suppose that in the filtering strategy associated with the regression testing scenario, the corresponding traffic filtering process is generated through various strategy operators, each characterized as a unit operation such as "obtaining code coverage data of the original traffic data", "calculating the similarity between the code coverage data and the code coverage data of the preset test cases", "removing the original traffic data", and "retaining the original traffic data", as well as the operator association relationship characterized as "serial-serial-parallel". Thus, executing the unit operations represented by each strategy operator in the filtering strategy according to the operator association relationship is equivalent to reproducing the traffic filtering process for the original traffic data as follows: "obtain the code coverage data of the original traffic data, calculate the similarity between the code coverage data and the code coverage data of the preset test cases, and remove the original traffic data when the similarity is greater than a preset threshold; otherwise, retain the original traffic data". Therefore, based on the above method, accurate traffic data matching the business scenario can be filtered out from the original traffic data.

[0046] In this way, according to the operator association relationship, the unit operations in the filtering strategy are executed on the original traffic data until the execution completion information of the filtering strategy is obtained, and the corresponding strategy output data is obtained. Then, the strategy output data is used as the accurate traffic data that matches the business scenario. That is, the filtering of the original traffic data is realized. For example, the server can execute the unit operations in the filtering strategy sent by the client according to the operator association relationship indicated by the client. Then, when the execution completion information of the filtering strategy is obtained, the obtained corresponding strategy output data is used as the accurate traffic data that matches the business scenario. That is, the accurate traffic data that matches the business scenario is filtered out from the original traffic data. Thus, the client only needs to select multiple strategy operators corresponding to the business scenario and combine them according to the indicated operator association to quickly obtain the filtering strategy required for the business scenario. The server only needs to execute the unit operations in the filtering strategy according to the indicated operator association. When the execution information of the filtering strategy is obtained, the corresponding strategy output data is used as the accurate traffic data matching the business scenario. Since each unit operation only needs to be developed once and can be reused in different business scenarios, the above method significantly reduces the time and manpower costs required for the client to develop filtering strategies, effectively improving the efficiency of strategy development. On the other hand, when developing multiple filtering strategies, it avoids the waste of resources caused by repeated development of the same processing logic, thereby reducing the total amount of resources required for the joint development of multiple filtering strategies and effectively improving resource utilization. Attached Figure Description

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

[0048] Figure 1 A schematic diagram illustrating the filtering of traffic data provided in an embodiment of this application;

[0049] Figure 2 A schematic diagram of a scenario architecture provided for an embodiment of this application;

[0050] Figures 3a-3d This is a schematic diagram of a configuration interface provided in an embodiment of this application;

[0051] Figure 4 A schematic diagram of a directed acyclic graph provided in an embodiment of this application;

[0052] Figure 5A flowchart illustrating a method for filtering traffic data provided in an embodiment of this application;

[0053] Figure 6 An example diagram of traffic filtering provided in an embodiment of this application;

[0054] Figure 7 An example diagram of a regression test provided in an embodiment of this application;

[0055] Figure 8 A schematic diagram of a public operator library provided in an embodiment of this application;

[0056] Figure 9 A schematic diagram of a loading strategy plugin provided in an embodiment of this application;

[0057] Figure 10 A schematic diagram illustrating yet another loading strategy plugin provided in an embodiment of this application;

[0058] Figure 11 A schematic diagram of a traffic data filtering system provided in an embodiment of this application;

[0059] Figure 12 A schematic diagram of the interaction process of a scheduling plugin provided in an embodiment of this application;

[0060] Figures 13a-13c This is a schematic diagram of a specific scenario provided in an embodiment of this application;

[0061] Figure 14 A schematic diagram of a traffic data filtering device provided in an embodiment of this application;

[0062] Figure 15 A schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0063] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. Unless otherwise specified, the embodiments and features in the embodiments of this application can be arbitrarily combined with each other. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0064] It is understood that the collection, use, and storage of raw traffic data involved in the following specific embodiments of this application require permission or consent from the relevant parties or organizations, and must comply with the laws, regulations, and standards of the relevant countries and regions. In some cases, such permission or consent may be in the form of an interface pop-up window instructing the relevant parties or organizations to sign within a designated area; or it may be obtained from a publicly available database; or it may be data collected within an authorized organization; or it may be data collected by simulating relevant parties in a virtual scenario.

[0065] First, some key terms involved in the embodiments of the present invention will be explained as follows.

[0066] Raw traffic data refers to the data generated by devices connected to the network during the provision of online services. Specifically, in one implementation, users of online services can initiate online requests for online services to online servers through a network connection, and the online servers can generate response messages for these online requests. In this way, the online servers can collect the online request and response messages of the online services to obtain the raw traffic data of the online services. Examples of online services include game services, multimedia information recommendation services, and dashboard services.

[0067] For example, suppose object A sends an online request a to the online server for game service A, and the online server generates a response message b for the online request a. In this case, the online server can use the relevant data carried by the online request a and the response message b (such as the Uniform Resource Locator URL, return code, etc.) as the raw traffic data collected for game service A.

[0068] Traffic filtering strategies refer to strategies developed for specific business scenarios that can filter out accurate traffic data that matches the specific business scenario from the collected raw traffic data.

[0069] For example, in a regression testing scenario, the relevant technology can adopt the following traffic filtering strategy: "obtain the code coverage data of the original traffic data, calculate the similarity between the code coverage data and the code coverage data of the preset test cases, and remove the original traffic data when the similarity is greater than the preset threshold; otherwise, retain the original traffic data," to filter out accurate traffic data that supports regression testing of online services from the original traffic data.

[0070] Precise traffic data refers to traffic data that matches a specific business scenario; that is, traffic data that supports the business scenario.

[0071] For example, see Figure 1As shown, in the field of software testing, precise traffic data that matches regression testing scenarios, performance testing scenarios, and security testing scenarios can be filtered from the raw traffic data of online services. In other words, precise traffic data that supports regression testing, performance testing, and security testing of online services can be obtained.

[0072] For example, in the field of multimedia information recommendation, precise traffic data that matches the object feature collection scenario and object geographic collection scenario can be filtered from the raw traffic data of online services. In other words, precise traffic data that supports the collection of object features and object geographic location of target objects using online services can be obtained.

[0073] For example, in the field of machine learning, precise traffic data that matches the training set collection scenario can be filtered out from the raw traffic data of online services, that is, precise traffic data that can be used as a model training set.

[0074] The design concept of the embodiments of this application will be briefly introduced below.

[0075] In related technologies, after collecting raw traffic data, online servers can use traffic filtering strategies developed for corresponding business scenarios to filter out accurate traffic data that matches the business scenario from the raw traffic data.

[0076] For example, after collecting the raw traffic data of its own game service, the online server can use the following traffic filtering strategy developed for the corresponding regression testing scenario: "Obtain the code coverage data of the raw traffic data, calculate the similarity between the code coverage data and the code coverage of the preset test cases, and remove the raw traffic data when the similarity is greater than the preset threshold; otherwise, retain the raw traffic data." From the raw traffic data, the accurate traffic data that matches the regression testing scenario is filtered out, that is, the accurate traffic data that supports regression testing of the game service.

[0077] However, when business scenarios change, it is necessary to redevelop the corresponding traffic filtering strategy. Since traffic filtering strategies are usually developed through engineering research and development, the required manpower and time costs are high, which in turn affects the filtering efficiency.

[0078] At the same time, since online servers can only use traffic filtering strategies developed for the corresponding business scenarios, it is impossible to fully utilize the existing traffic filtering strategies when developing new ones. This can easily lead to redundant development and waste of resources.

[0079] For example, suppose the traffic filtering strategy 'a' developed for the regression testing scenario is: "Obtain the code coverage data of the original traffic data, calculate the similarity between the code coverage data and the code coverage data of the preset test cases, and remove the original traffic data when the similarity is greater than the preset threshold; otherwise, retain the original traffic data." Furthermore, suppose that a traffic filtering strategy needs to be developed for the performance testing scenario. If traffic filtering strategy 'a' cannot be applied to the current required performance testing scenario, then the corresponding traffic filtering strategy needs to be developed through the engineering development of the performance testing scenario, which can easily lead to a waste of resources.

[0080] In view of this, embodiments of this application provide a method, apparatus, electronic device, and storage medium for filtering traffic data. The method can be applied to electronic devices such as servers, including obtaining raw traffic data associated with a specified business scenario and a filtering strategy preset for the business scenario. The filtering strategy includes a traffic filtering process determined for the business scenario. The traffic filtering process is generated by selecting multiple strategy operators corresponding to the business scenario and combining the selected multiple strategy operators according to the indicated operator association relationship. For example, the client can select multiple strategy operators associated with the business scenario and indicate the operator association relationship, and then combine the selected multiple strategy operators according to the operator association relationship to generate the filtering strategy. Therefore, for the raw traffic data, the unit operation represented by each strategy operator in the filtering strategy is executed according to the operator association relationship. Each unit operation is used to implement a corresponding processing logic for filtering traffic data, which is equivalent to reproducing the traffic filtering process in the traffic filtering strategy associated with the specified business scenario for the raw traffic data. For example, suppose that in the filtering strategy associated with the regression testing scenario, the corresponding traffic filtering process is generated through various strategy operators, each characterized as a unit operation such as "obtaining code coverage data of the original traffic data", "calculating the similarity between the code coverage data and the code coverage data of the preset test cases", "removing the original traffic data", and "retaining the original traffic data", as well as the operator association relationship characterized as "serial-serial-parallel". Thus, executing the unit operations represented by each strategy operator in the filtering strategy according to the operator association relationship is equivalent to reproducing the traffic filtering process for the original traffic data as follows: "obtain the code coverage data of the original traffic data, calculate the similarity between the code coverage data and the code coverage data of the preset test cases, and remove the original traffic data when the similarity is greater than a preset threshold; otherwise, retain the original traffic data". Therefore, based on the above method, accurate traffic data matching the business scenario can be filtered out from the original traffic data.

[0081] In this way, according to the operator association relationship, the unit operations in the filtering strategy are executed on the original traffic data until the execution completion information of the filtering strategy is obtained, and the corresponding strategy output data is obtained. Then, the strategy output data is used as the accurate traffic data that matches the business scenario. That is, the filtering of the original traffic data is realized. For example, the server can execute the unit operations in the filtering strategy sent by the client according to the operator association relationship indicated by the client. Then, when the execution completion information of the filtering strategy is obtained, the obtained corresponding strategy output data is used as the accurate traffic data that matches the business scenario. That is, the accurate traffic data that matches the business scenario is filtered out from the original traffic data. Thus, the client only needs to select multiple strategy operators corresponding to the business scenario and combine them according to the indicated operator association to quickly obtain the filtering strategy required for the business scenario. The server only needs to execute each unit operation in the filtering strategy according to the indicated operator association. When the execution information of the filtering strategy is obtained, the corresponding strategy output data is used as the accurate traffic data matching the business scenario. Since each unit operation only needs to be developed once and can be reused multiple times, the above method significantly reduces the time and manpower costs required for the client to develop filtering strategies, effectively improving the efficiency of strategy development. On the other hand, when developing multiple filtering strategies, it avoids the waste of resources caused by repeated development of the same processing logic, thereby reducing the total amount of resources required for the joint development of multiple filtering strategies and effectively improving resource utilization.

[0082] It should be understood that the specific implementation methods of this application are not limited to use in the testing field, gaming field, multimedia information recommendation field, machine learning field, and other fields involving the filtering of traffic data in technologies such as the Internet, cloud technology, artificial intelligence, smart transportation, smart home, smart wearable devices, autonomous driving, and the Internet of Things. Furthermore, the business scenarios involved in this application can be scenarios related to the filtering of traffic data in the aforementioned fields. For example, in the field of software testing, this application can involve business scenarios such as regression testing, performance testing, and security testing; in the field of multimedia information recommendation, this application can involve business scenarios such as object feature collection and object geographic collection; and in the field of machine learning, this application can involve business scenarios such as training set collection.

[0083] In other words, the raw traffic data involved in this application can come from any electronic device in the network. Therefore, the proposed traffic data filtering method can be implemented on the raw traffic data so that the filtered accurate traffic data can be used in regression testing scenarios, performance testing scenarios, security testing scenarios, object feature collection scenarios, object geographic collection scenarios, etc.

[0084] Furthermore, the embodiments of this application will be described below with reference to the accompanying drawings. It should be understood that the embodiments described herein are for illustration and explanation only and are not intended to limit this application. Moreover, the embodiments of this application and the features in the embodiments can be combined with each other without conflict.

[0085] See Figure 2 As shown, it is a schematic diagram of a scenario architecture applicable to an embodiment of this application. The scenario architecture includes device 201, device 202 and device 203. The number of devices 201 can be one or more, and the number of devices 202 and devices 203 can also be one or more. Devices 201, device 202 and device 203 can communicate with each other through a communication network. The communication network used by devices 201, device 202 and device 203 can be a wired network or a wireless network.

[0086] Device 201 may be, but is not limited to, mobile phones, tablets, laptops, desktop computers, e-book readers, smart voice interaction devices, smart home appliances, in-vehicle terminals, etc., but is not limited to these. In one possible implementation, device 201 may be a device that provides online services, such as a device with an online service client installed. Online services include, but are not limited to, game services, e-commerce services, multimedia information recommendation services, audio and video services, etc. Alternatively, device 201 may be a device dedicated to generating raw traffic data, such as a traffic storage device. Correspondingly, device 202 may be a device that provides online services, such as a backend server corresponding to an online service, or a device dedicated to filtering traffic data, such as a traffic filtering platform server.

[0087] It is understood that this application does not limit the type of online service, nor does it limit the number of devices 201 and 202. For example, in some embodiments, the raw traffic data may come from one device 201, or the raw traffic data may be obtained from multiple devices 201. Device 202 may be an independent 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.

[0088] It should be noted that in this scenario architecture, device 202 performs the processing operations on the raw traffic data, including: obtaining the raw traffic data associated with the specified business scenario and the filtering strategy preset by the business scenario; executing the unit operations in the filtering strategy on the raw traffic data according to the operator association relationship until the execution completion information of the filtering strategy is obtained, obtaining the corresponding strategy output data, and using the strategy output data as the accurate traffic data matching the business scenario. The above-mentioned filtering strategy may be pre-stored by device 202, and the filtering strategy is generated through multiple strategy operators associated with the business scenario and the operator association relationship between multiple strategy operators. Alternatively, it may be a filtering strategy sent by device 203, and the filtering strategy is generated through multiple strategy operators associated with the business scenario and the operator association relationship between multiple strategy operators.

[0089] Furthermore, device 203 can be, but is not limited to, mobile phones, tablets, laptops, desktop computers, e-book readers, smart voice interaction devices, smart home appliances, in-vehicle terminals, etc., and device 203 can be a device used to send filtering strategies to device 202, such as the management device of device 202. In device 203, a management terminal related to the filtering of traffic data can be installed. This management terminal can be software (such as browsers, communication software, etc.), or web pages, mini-programs, etc. In the above application scenario, device 203 can generate filtering strategies based on multiple strategy operators associated with business scenarios and the operator association relationships between multiple strategy operators by installing the management terminal, and send the filtering strategies to device 202 through the communication network.

[0090] That is, in the specific implementation process of the above application scenario, device 202 obtains the original traffic data associated with the business scenario from device 201, and obtains the preset filtering strategy of the business scenario from device 203. The filtering strategy includes a traffic filtering process determined for the business scenario. The traffic filtering process is generated by multiple strategy operators associated with the business scenario and the operator association relationship between the multiple strategy operators. Each strategy operator represents a unit operation determined for the business scenario.

[0091] In one possible implementation, device 203 may generate a filtering strategy by: acquiring strategy description information determined for a business scenario, wherein the strategy description information includes: multiple functions to be executed determined for the business scenario, each function to be executed being associated with a processing logic for filtering traffic data; selecting multiple strategy operators associated with each function to be executed from a preset set of operators; in response to an orchestration configuration operation triggered for multiple strategy operators, determining the operator association relationship between the multiple strategy operators, and combining the multiple strategy operators according to the operator association relationship to generate a corresponding filtering strategy.

[0092] Specifically, each strategy operator represents a unit operation used for raw traffic data in a business scenario. Each unit operation is used to implement a corresponding processing logic for filtering traffic data. The processing logic includes, for example, rule calculation, model calculation, and algorithm processing. Thus, those skilled in the art can pre-develop multiple unit operations for filtering traffic data, where each unit operation is used to implement a corresponding processing logic for filtering traffic data. In this way, device 203 can select multiple strategy operators associated with multiple functions to be executed in the pre-developed unit operations according to multiple functions to be executed in the business scenario.

[0093] For example, in a regression testing scenario, multiple strategy operators can be selected based on the strategy description information applicable to regression testing, corresponding to the business scenario. Assume the strategy description information includes multiple functions to be executed: "preprocessing," "obtaining code coverage of raw traffic data," "calculating the similarity between the code coverage and the code coverage of preset test cases," "removing the raw traffic data when the similarity is greater than a preset threshold," "retaining the raw traffic data when the similarity is not greater than a preset threshold," and "postprocessing." Further, assume that strategy operators A, B, C, D, E, and F, which can respectively implement the functions "preprocessing," "obtaining code coverage of raw traffic data," "calculating the similarity between the code coverage and the code coverage of preset test cases," "removing the raw traffic data when the similarity is greater than a preset threshold," "retaining the raw traffic data when the similarity is not greater than a preset threshold," and "postprocessing," are obtained from a preset set of operators. That is, multiple strategy operators A, B, C, D, E, and F associated with the multiple functions to be executed in the strategy description information are selected.

[0094] Furthermore, by performing orchestration configuration operations triggered by multiple strategy operators, the operator association relationships between multiple strategy operators are determined, and the multiple strategy operators are combined according to the operator association relationships to generate corresponding filtering strategies.

[0095] In one possible implementation, the orchestration configuration operations triggered by multiple policy operators can be performed in a configuration interface, which may be an interface presented in the management terminal of device 203, see reference. Figure 3a As shown, it is a possible configuration interface diagram provided in an embodiment of this application. In this configuration interface, the device 203 generates a corresponding filtering strategy in response to the orchestration configuration operation triggered by the above-mentioned multiple strategy operators A, B, C, D, E, and F.

[0096] In one possible implementation, device 203, in response to triggering a selection operation for a plurality of policy operators, determines at least two policy operator sets, and device 203, in response to triggering an orchestration configuration operation for at least two policy operator sets, determines the association between the at least two policy operator sets, and the association between each policy operator in each policy operator set.

[0097] For example, suppose that the relevant object selects policy operators A, B, and C, and further selects policy operators D and F in the configuration interface presented by device 203, then device 203, in response to the selection operation triggered for policy operators A, B, and C, in response to the selection operation triggered for policy operators D and E, and in response to the selection operation triggered for policy operator F, determines three policy operator sets {A, B, C}, {D, E}, and {F}.

[0098] The following section will explain the orchestration configuration operations triggered by policy subsets.

[0099] In one possible implementation, device 203, in response to a phase configuration operation triggered for at least two policy operator subsets, determines that the association between the at least two policy operator subsets is a serial relationship, and that the association between each policy operator in each policy operator subset is a serial relationship.

[0100] For example, see Figure 3b As shown, assuming the relevant object selects two policy operator subsets {A, B, C, D, E, F} and {F} for multiple policy operators A, B, C, D, E, F, and the relevant object further configures the two policy operator subsets {A, B, C, D, E} and {F} into different stages, namely: stage 1 and stage 2, in the operation interface presented by device 203, then device 203, in response to the stage configuration operation for the two policy operator subsets {A, B, C, D, E} and {F}, determines that the association relationship between policy operator subsets {A, B, C, D, E} and policy operator subset {F} is a serial relationship, and the association relationship between policy operators A, B, C, D, E in policy operator subsets {A, B, C, D, E} is a serial relationship.

[0101] In one possible implementation, device 203, in response to a task configuration operation triggered for at least two policy operator subsets, determines that the association between the at least two policy operator subsets is a parallel relationship, and the association between each policy operator in each policy operator subset is a serial relationship.

[0102] For example, see Figure 3c As shown, assuming that the relevant object selects two policy operator subsets {D} and {E} for multiple policy operators A, B, C, D, E, and F, and the relevant object further configures the two policy operator subsets {D} and {E} as different tasks in the configuration interface presented by device 203, namely: "Task 1" and "Task 2", then device 203, in response to the task configuration operation for the two policy operator subsets {D} and {E}, determines that the association relationship between policy operator subset {D} and policy operator subset {E} is a parallel relationship.

[0103] In one possible implementation, device 203, in response to a default configuration operation triggered for at least two policy operator subsets, determines that the association between the at least two policy operator subsets is a serial relationship, and that the association between each policy operator in each policy operator subset is a serial relationship.

[0104] For example, see Figure 3d As shown, assuming the relevant object selects two policy operator subsets {A, B, C} and {D, E, F} for multiple policy operators A, B, C, D, E, F, and does not continue to operate on the two policy operator subsets in the configuration interface presented by device 203, then device 203, in response to the default configuration operation for the two policy operator subsets {A, B, C} and {D, E, F}, determines that the association relationship between policy operator subsets {A, B, C} and policy operator subset {D, E, F} is a serial relationship, the association relationship between policy operators A, B, C in policy operator subset {A, B, C} is a serial relationship, and the association relationship between policy operators D, E, F in policy operator subset {D, E, F} is a serial relationship.

[0105] Thus, device 203, in response to selection operations triggered for multiple policy operators and orchestration configuration operations triggered for at least two policy operator sets, determines operator associations to generate corresponding filtering strategies based on the operator associations; in one possible implementation, the operator associations can be represented as a directed acyclic graph (DAG).

[0106] For example, assuming device 203, in response to a stage configuration operation for two policy operator subsets {A, B, C, D, E}, {F}, it determines that the association between policy operator subsets {A, B, C, D, E} and policy operator subset {F} is a serial relationship; then, in response to a default configuration operation for two policy operator subsets {A, B, C}, {D, E, F}, it determines that the association between policy operator subsets {A, B, C} and policy operator subsets {D, E, F} is a serial relationship; then, in response to a task configuration operation for two policy operator subsets {D}, {E}, it determines that the association between policy operator subsets {D} and policy operator subset {E} is a parallel relationship, wherein the association between policy operators in each policy operator subset is a serial relationship. The operator association between the policy operators A, B, C, D, E, F determined above is represented as a directed acyclic graph, which can be represented as follows: Figure 4 As shown.

[0107] Thus, by employing the above method, device 203 can generate filtering strategies corresponding to business scenarios by using multiple strategy operators associated with business scenarios and the operator relationships between these strategy operators. This eliminates the need for R&D personnel to manually write filtering strategies for business scenarios, reducing the manpower and time costs required for development and improving strategy development efficiency. Furthermore, by leveraging the multiple strategy operators associated with business scenarios and the operator relationships between these strategy operators, filtering strategies can be quickly generated by adjusting the operator relationships between multiple strategy operators when facing the same or different business scenarios. In turn, by utilizing the resources of existing filtering strategies, the filtering strategies required by the business can be developed, thereby avoiding resource waste caused by redundant development and improving resource utilization.

[0108] Furthermore, based on the above application scenarios and the generated filtering strategies, please refer to... Figure 5 As shown below, the process of the traffic data filtering method involved in this application will be explained. It is worth noting that the process of this traffic data filtering method is described using a regression testing scenario as an example, including:

[0109] S501: Obtain the raw traffic data associated with the specified business scenario, as well as the preset filtering strategy for the business scenario.

[0110] Specifically, the so-called raw traffic data refers to the data generated by devices connected to the network during the provision of online services; the so-called filtering strategy includes a traffic filtering process determined for a business scenario. The traffic filtering process is generated by selecting multiple strategy operators corresponding to the business scenario and combining the selected multiple strategy operators according to the indicated operator association relationship. Each strategy operator represents a unit operation determined for the raw traffic data in the business scenario, and each unit operation is used to implement a corresponding processing logic for filtering traffic data.

[0111] For example, see Figure 6 As shown, assuming that in a regression testing scenario, device 202 provides game services to device 201, then device 202 obtains the raw traffic data of the game service. Furthermore, device 202 obtains the filtering strategy for the regression testing scenario sent by device 203. In this filtering strategy, the unit operations corresponding to strategy operators A, B, C, D, E, and F are: "preprocessing", "obtaining the code coverage of the raw traffic data", "calculating the similarity between the code coverage and the code coverage of preset test cases", "removing the raw traffic data when the similarity is greater than a preset threshold", "retaining the raw traffic data when the similarity is not greater than a preset threshold", and "postprocessing". The operator relationships between the above strategy operators are shown in the figure. Figure 4 As shown.

[0112] S502: Based on the operator association relationship, perform the unit operations in the filtering strategy on the original traffic data until the execution completion information of the filtering strategy is obtained, obtain the corresponding strategy output data, and use the strategy output data as accurate traffic data that matches the business scenario.

[0113] Specifically, device 202 can execute the unit operations in the filtering strategy through a specific process or engine, and then determine that the filtering strategy has been completed when it receives the execution completion information returned by the process or engine, and use the obtained corresponding strategy output data as accurate traffic data that matches the business scenario.

[0114] For example, see Figure 7 As shown, assuming device 202 uses its associated engine, according to... Figure 4The operator relationships shown execute the unit operations corresponding to each of the strategy operators A, B, C, D, E, and F. Thus, for the original traffic data, the traffic filtering process in the filtering strategy is implemented as follows: "Preprocessing; obtaining the code coverage of the original traffic data; calculating the similarity between the code coverage and the code coverage of the preset test cases; removing the original traffic data when the similarity is greater than a preset threshold; retaining the original traffic data when the similarity is not greater than the preset threshold; postprocessing." In this way, when the device 202 obtains the completion information of the filtering strategy in the engine, it can obtain the corresponding strategy output data, that is, the traffic data whose similarity between the corresponding code coverage and the code coverage of the preset test cases is not greater than the threshold. The strategy output data can then be used as accurate traffic data to support regression testing.

[0115] Understandably, in practical applications, for version updates of filtering strategies related to the same business scenario, the strategy operators associated with each filtering strategy can be stored in a common operator library. (See [link to relevant documentation]). Figure 8 The diagram illustrates a possible public operator library provided in this application. This public operator library stores three versions of filtering strategies corresponding to business scenarios A, B, C, and D. Specifically, in version V1, filtering strategy a_V1 corresponding to business scenario A is associated with strategy operator 1 in the public operator library; filtering strategy b_V1 corresponding to business scenario B is associated with strategy operator 3 in the public operator library; filtering strategy c_V1 corresponding to business scenario C is associated with strategy operator 4 in the public operator library; and filtering strategy d_V1 corresponding to business scenario D is associated with strategy operator 6 in the public operator library. Further, in version V2, filtering strategy a_V2 corresponding to business scenario A is associated with strategy operators 1, 7, and 8 in the public operator library; and filtering strategy b_V2 corresponding to business scenario B is associated with... The filtering strategies c_V2 for business scenario C are associated with strategies 4, 10, 5, and 11 in the public operator library, and the filtering strategy d_V2 for business scenario D is associated with strategies 5, 11, 6, and 12 in the public operator library. Furthermore, in version V3, the filtering strategy a_V3 for business scenario A is associated with strategies 1, 7, 8, 13, 14, and 15 in the public operator library; the filtering strategy b_V3 for business scenario B is associated with strategies 3 and 9 in the public operator library; the filtering strategy c_V3 for business scenario C is associated with strategies 3, 9, 15, 4, 10, and 16 in the public operator library; and the filtering strategy d_V3 for business scenario D is associated with strategies 4, 10, 16, 11, 6, 12, and 18 in the public operator library.

[0116] Thus, based on the above approach, for version replacements of filtering strategies associated with the same business scenario, multiple strategy operators associated with each filtering strategy are stored in a common operator library, thereby improving storage efficiency.

[0117] In one possible implementation, after generating the filtering policy, device 203 further includes: encapsulating the filtering policy and generating a policy plugin. In this way, device 203 sends the policy plugin to device 202, so that after obtaining the original traffic data in device 201, device 202 loads the policy plugin through a preset policy loader, obtains the filtering policy, and executes the subsequent steps involved in this application.

[0118] Thus, this application encapsulates the filtering strategy as a strategy plugin, thereby ensuring the flexible loading of each filtering strategy and making it more versatile. For example, when it is necessary to set or adjust the corresponding filtering strategy to adapt to specific business scenarios or to deal with unexpected events in business scenarios, currently it is necessary to adjust the system file corresponding to the filtering strategy through the management terminal based on actual needs, and then use the adjusted system file to globally replace the required filtering strategy. This makes the replacement of filtering strategies difficult and the loading speed slow. However, in the embodiment of this application, the strategy plugin corresponding to the current filtering strategy is directly replaced by the strategy plugin corresponding to the adjusted filtering strategy. Therefore, the required filtering strategy can be loaded without making corresponding changes to the system file. This improves the loading speed of the filtering strategy, and since the system file is not associated with the filtering strategy, the developed filtering strategy can be applied to different systems, making it more versatile.

[0119] It is worth noting that in practical applications, there is no limit to the number of policy plugins obtained by encapsulating a corresponding filtering strategy. For example, a filtering strategy can be encapsulated into a corresponding policy plugin, or a filtering strategy can be encapsulated into multiple policy plugins according to actual needs. In the process of encapsulating a filtering strategy into multiple policy plugins, it can be understood that each policy plugin needs to carry at least one of the corresponding multiple policy operators. Furthermore, based on the operator association relationship between the corresponding at least one policy operator, the plugin association relationship between multiple policy plugins can be further determined. For example, assuming that a filtering strategy is encapsulated into two policy plugins A and B, and policy plugin A contains the following policy operators: {A, B, C, D, E}, and policy plugin B contains the following policy operator {F}, then according to the determined operator association relationship, it can be determined that policy plugin A and policy plugin B can be in a serial relationship.

[0120] For ease of understanding, this application will be described below as a filtering strategy encapsulated as a strategy plugin.

[0121] Optionally, the preset strategy loader mentioned above can be a class loader called StrategyClassLoader. A class loader supports hot loading between different filtering strategies associated with the same business scenario, thereby loading the specified filtering strategy associated with the business scenario.

[0122] For example, see Figure 9 As shown, suppose device 203 sends a strategy plugin to device 202. This strategy plugin carries a filtering strategy a_V2 for the corresponding business scenario A. In this way, device 202 performs hot loading between the currently used strategy plugin a_V1 for the corresponding business scenario A and the obtained strategy plugin a_V2 through the StrategyClassLoader. That is, by replacing the pointers of the address and other parameter information of the corresponding strategy plugin a_V1 with the pointers of the parameter information of the corresponding strategy plugin a_V1, the strategy plugin a_V2 is loaded quickly.

[0123] In this way, by encapsulating the filtering strategy into a strategy plugin and dynamically loading it through a class loader, the corresponding strategy execution plugin can be deployed flexibly and quickly to adapt to specific business scenarios or to deal with unexpected events in business scenarios, so that the filtering strategy can adapt to actual needs more quickly.

[0124] Furthermore, in one possible implementation, device 203 can generate multiple candidate strategies associated with each of the multiple candidate scenarios corresponding to its own needs, and thereby obtain multiple candidate plugins carrying the candidate strategies. It is understood that in the process of generating candidate plugins, device 203 can perform the steps of generating filtering strategies and strategy plugins as described above. For example, in the process of generating candidate plugins for a performance test scenario, device 203 can perform the steps of determining multiple candidate operators associated with the performance test scenario as described above, and determining the candidate association relationship between multiple candidate operators in response to the orchestration configuration operation for multiple candidate operators.

[0125] It should be understood that, in one possible implementation, the candidate strategy generated by device 203 is further encapsulated as a candidate plugin, so that device 203 can send multiple candidate plugins to device 202. Thus, after device 202 receives multiple candidate plugins, it can flexibly load multiple candidate plugins to quickly adapt to actual needs.

[0126] For example, see Figure 10 As shown, suppose device 203 sends the following candidate plugins to device 202: candidate plugin A, candidate plugin B, and candidate plugin C. Candidate plugin A corresponds to the performance test scenario, candidate plugin B corresponds to the security test scenario, and candidate plugin C corresponds to the traffic redirection test scenario. Each candidate plugin is associated with multiple corresponding strategy operators. After receiving multiple candidate plugins, device 202 can load multiple candidate plugins respectively. In this way, device 202 can filter out accurate traffic data that supports performance testing, accurate traffic data that supports security testing, and accurate traffic data that supports traffic redirection testing from the original traffic data.

[0127] Furthermore, in one possible implementation, after device 202 obtains multiple candidate plugins, device 203 can also initiate a scheduling request to device 202 carrying plugin identifiers of multiple candidate plugins. Then, device 202 schedules each candidate plugin according to the indicated plugin scheduling relationship. Each time scheduling occurs, according to the candidate association relationships among the candidate plugins, it executes the corresponding unit operations in the candidate strategy on the original traffic data until it obtains scheduling completion information for each candidate plugin, obtains the corresponding candidate output data, and uses the candidate output data as the accurate traffic data in the original traffic data that matches the business scenario. In this way, device 203 can freely schedule the existing candidate plugins in device 202, and then, in the event of an uncertain business scenario or a sudden event in the business scenario, use the obtained corresponding candidate output data as the accurate traffic data in the original traffic data that matches the business scenario, thereby improving the user experience.

[0128] It is worth noting that the above-mentioned plug-in scheduling relationship can be indicated by device 203 according to actual needs, or it can be determined by the corresponding plug-in association relationship between multiple candidate plug-ins when multiple candidate plug-ins to be scheduled are associated with the same screening strategy. For example, in one possible case, device 203 can flexibly indicate serial or parallel scheduling between multiple candidate plug-ins associated with the same or different screening strategies according to actual needs, or indicate that multiple candidate plug-ins associated with the same screening strategy are scheduled according to the plug-in association relationship.

[0129] Furthermore, in one possible implementation, device 203 sends a recommendation request for multiple candidate plugins to device 202, so that device 202 responds to the recommendation request for multiple candidate plugins by obtaining key information of each candidate plugin, obtaining plugin evaluation values ​​of each candidate plugin based on the key information, sorting the multiple candidate plugins in descending order according to the plugin evaluation values, selecting at least one candidate plugin that meets the preset sorting conditions as the target plugin, and recommending the selected at least one target plugin to device 203.

[0130] Specifically, each key piece of information includes at least: parameter information of the corresponding candidate plugin and historical loading information of the corresponding candidate plugin; for example, in the specific implementation of this application, the key information of a candidate plugin may include: parameter information such as the candidate plugin's language features (go, c++), framework features (cgi, server, appsvr), user ratings, access volume, execution time, disk / CPU / memory consumption, and historical loading information such as the candidate plugin's historical coverage.

[0131] In one possible implementation, the parameter information of a candidate plugin is evaluated according to a preset evaluation rule to obtain a parameter evaluation value of the candidate plugin. The historical loading information of a candidate plugin is evaluated according to the evaluation rule to obtain a performance evaluation value of the candidate plugin. Finally, the parameter evaluation value and the performance evaluation value are weighted and summed to obtain a plugin evaluation value of the candidate plugin.

[0132] For example, based on preset evaluation rules, a candidate plugin is evaluated for parameters such as language features (go, c++), framework features (cgi, server, appsvr), user ratings, access volume, execution time, and disk / CPU / memory consumption, to obtain a parameter evaluation value 'a'. Additionally, based on the evaluation rules, the historical coverage of a candidate plugin is evaluated to obtain a performance evaluation value 'b'. Finally, based on preset parameter evaluation weights 'weight_a' and 'performance evaluation weights 'weight_b', a candidate plugin's evaluation value 'score' is obtained: score = a * weight_a + b * weight_b.

[0133] In this way, at least one target plugin can be recommended to device 203 when needed, thereby making full use of existing candidate strategies and reducing the cost of strategy trial and error.

[0134] Further reading Figure 11 As shown, this application also provides a traffic data filtering system, which can be built using a microservice architecture. Specifically, the server side of the system can be shown as device 202, and the management side of the system can be shown as device 203. The system also supports connecting to external application devices, which can be device 201. Furthermore, the server-side device 202 supports plugin orchestration and scheduling services, plugin recommendation services, policy plugin management services, software development kit (SDK) services, and data channel services.

[0135] It should be noted that, based on the plugin orchestration and scheduling service, the plugin scheduling relationship can be indicated according to actual needs, such as indicating serial or parallel scheduling between every two candidate plugins; based on the plugin recommendation service, at least one target plugin can be selected from multiple candidate plugins; based on the policy plugin management service, existing policy plugins or candidate plugins can be deleted, updated, and managed and configured; based on the software development kit (SDK) service, development tools related to policy operators and policy plugins can be provided, creating a standardized development environment. For example, the SDK service can provide development tool documentation, plugin access documentation, etc., and specify the security specifications and access specifications for each policy plugin. The security specifications include, but are not limited to: organizational structure verification, traffic data access permission verification, traffic filtering result write permission verification, access scope, etc., and the access specifications include, but are not limited to: policy plugin interface, object type declaration, etc.; based on the data channel service, relevant data generated in the system can be transmitted.

[0136] Correspondingly, the management device 203 supports policy plugin upload service, policy plugin feature management service, traffic filtering pipeline orchestration service, policy operator management service, and business access management service.

[0137] It should be noted that, based on the policy plugin upload service, policy plugins associated with business scenarios can be developed and uploaded to the server; based on the policy plugin feature management service, the attributes of stored policy plugins or candidate plugins, such as plugin development language, can be viewed and obtained; based on the policy operator management service, existing policy operators can be deleted, iterated, and configured; and based on the business access management service, raw traffic data associated with the current required business scenario can be managed.

[0138] Furthermore, the aforementioned traffic data filtering system also includes a storage service, which can be a Web Feature Service (WFS) or a designated database service. Specifically, the storage service can be deployed in device 202 or on a designated external storage device. Furthermore, based on the so-called storage service, relevant data generated by the traffic data filtering system can be stored.

[0139] Thus, based on such Figure 11 In one possible implementation of the traffic data filtering system shown, device 203 corresponds to the management end in the system, and device 202 corresponds to the server end. The management end sends a scheduling request carrying plugin identifiers for multiple candidate plugins. The server stores each candidate plugin with each plugin identifier and can execute the scheduling request initiated by the management end through the scheduling engine. (See reference...) Figure 12As shown, the process interaction between the so-called management end and the so-called server end during plugin scheduling includes:

[0140] S1201: The traffic filtering pipeline orchestration service in the management terminal sends a scheduling request carrying the plugin identifiers of multiple candidate plugins to the scheduling engine in the server terminal.

[0141] S1202: The scheduling engine in the server requests the strategy plugin management service to obtain each candidate plugin with each plugin identifier;

[0142] S1203: The scheduling engine in the server schedules multiple candidate plugins according to the indicated plugin scheduling relationship; each time a scheduling occurs, S12031-S12033 are executed.

[0143] S12031: The scheduling engine in the server requests the storage service to record scheduling information;

[0144] S12032: The scheduling engine in the server requests a candidate plugin to orchestrate the scheduling service;

[0145] S12033: The scheduling engine in the server requests the storage service to update the scheduling information;

[0146] S1204: The scheduling engine on the server side sends a scheduling completion message to the traffic filtering pipeline orchestration service on the management side.

[0147] It should be noted that, in Figure 12 In the illustrated process interaction, the scheduling engine on the server side can request the plugin orchestration scheduling service to schedule each candidate plugin in a serial or parallel manner according to the plugin scheduling relationship. During each candidate plugin scheduling, the scheduling engine on the server side can execute the unit operations represented by the corresponding multiple strategy operators in a synchronous or asynchronous manner according to the operator association relationship in the candidate plugin. For example, when scheduling a candidate plugin, if the current strategy operator to be executed and its corresponding next strategy operator are serially related, the unit operations represented by the current strategy operator and the next strategy operator are executed synchronously. If the current strategy operator to be executed and its corresponding next strategy operator are parallel related, the unit operations represented by the current strategy operator and the next strategy operator are executed asynchronously.

[0148] In this way, when it is necessary to adapt to specific business scenarios or deal with unexpected events in business scenarios, the candidate plugins of existing candidate strategies can be used to flexibly and quickly deploy applicable traffic data filtering pipelines, so as to adapt to actual needs more quickly and thus improve user experience.

[0149] The following section will describe the specific scenarios involved in this application based on the traffic data filtering system provided above.

[0150] See Figure 13a As shown, in a specific scenario, the target object can select multiple policy operators associated with the current business scenario through the policy plugin upload service in the management terminal, and trigger orchestration configuration operations for multiple policy operators in the management terminal to determine the operator association relationship between multiple policy operators. Furthermore, the policy plugin upload service supports encapsulating multiple policy operators to obtain the corresponding policy plugin V2, and uploading the policy plugin V2 to the plugin orchestration and scheduling service in the server. Furthermore, the plugin orchestration and scheduling service in the server loads the policy plugin V2 to realize the replacement of the filtering strategy, and then adopts the latest filtering strategy to filter out accurate traffic data. In this specific scenario, the accurate traffic data can be used for system testing.

[0151] See Figure 13b As shown, in another specific scenario, the target object can select multiple candidate plugins through the traffic filtering pipeline orchestration service in the management terminal, and request the plugin orchestration and scheduling service in the server terminal to schedule multiple candidate plugins according to the indicated plugin scheduling relationship. Then, the server terminal uses each candidate plugin to filter traffic data under the indicated traffic filtering pipeline and select the corresponding accurate traffic data.

[0152] See Figure 13c As shown, in another specific scenario, the plugin recommendation service on the server side can calculate the plugin evaluation value of each candidate plugin by using the key information of each candidate plugin uploaded by the target object. Then, based on the evaluation values ​​of each plugin, the multiple candidate plugins are sorted in descending order. From the multiple candidate plugins, at least one candidate plugin that meets the preset sorting conditions is selected as the target plugin and recommended to the management end. In this way, the management end can obtain candidate plugins that may be related to the business scenario more quickly, thereby further improving the efficiency of strategy development.

[0153] Based on the same technical concept, this application provides a schematic diagram of the structure of a traffic data filtering device, as shown in the figure. Figure 14 As shown, the device 1400 includes:

[0154] The strategy acquisition module 1401 is used to acquire the raw traffic data associated with a specified business scenario and the filtering strategy preset for the business scenario. The filtering strategy is generated by selecting multiple strategy operators for the corresponding business scenario and combining the selected multiple strategy operators according to the indicated operator association relationship. Each strategy operator represents a unit operation used for the raw traffic data in the business scenario. Each unit operation is used to implement a corresponding processing logic for filtering traffic data.

[0155] The execution module 1402 is used to perform the unit operations in the filtering strategy on the raw traffic data according to the operator association relationship until the execution completion information of the filtering strategy is obtained, the corresponding strategy output data is obtained, and the strategy output data is used as accurate traffic data that matches the business scenario.

[0156] In one possible implementation, before obtaining the preset filtering strategy for the business scenario, the strategy acquisition module 1401 is further configured to:

[0157] Obtain strategy description information determined for the business scenario, wherein the strategy description information includes multiple functions to be executed determined for the business scenario, and each function to be executed is associated with a processing logic for filtering traffic data;

[0158] Select multiple strategy operators associated with multiple functions to be executed from the preset set of operators;

[0159] In response to orchestration configuration operations triggered for multiple policy operators, the operator relationships between the multiple policy operators are determined, and the multiple policy operators are combined according to the operator relationships to generate corresponding filtering strategies.

[0160] In one possible implementation, in response to an orchestration configuration operation triggered for multiple policy operators, the policy acquisition module 1401 determines the operator association relationships among the multiple policy operators and is used to:

[0161] In response to a selection operation triggered for multiple policy operators, at least two sets of policy operators are determined;

[0162] In response to an orchestration configuration operation triggered for at least two policy operator subsets, determine the association between the at least two policy operator subsets, as well as the association between each policy operator in each policy operator subset.

[0163] In one possible implementation, in response to an orchestration configuration operation triggered for at least two policy operator subsets, the association between the at least two policy operator subsets and the association between each policy operator in each policy operator subset are determined, including any of the following:

[0164] In response to a phase configuration operation triggered for at least two policy operator subsets, determine that the association between the at least two policy operator subsets is a serial relationship, and that the association between each policy operator in each policy operator subset is a serial relationship;

[0165] In response to a task configuration operation triggered for at least two policy operator subsets, determine that the association between the at least two policy operator subsets is a parallel relationship, and the association between each policy operator in each policy operator subset is a serial relationship;

[0166] In response to a default configuration operation triggered for at least two policy operator subsets, determine that the association between the at least two policy operator subsets is a serial relationship, and that the association between each policy operator in each policy operator subset is a serial relationship.

[0167] In one possible implementation, after generating the corresponding filtering strategy, the strategy acquisition module 1401 is further used to: encapsulate the filtering strategy and obtain a strategy plugin;

[0168] Then, the pre-defined scheduling strategy for the business scenario is obtained. The strategy acquisition module 1401 is used for:

[0169] Obtain the pre-defined strategy plugins for the business scenario; the strategy plugins carry filtering strategies.

[0170] The policy plugin is loaded using a preset policy loader to obtain the filtering policy.

[0171] In one possible implementation, each candidate plugin carries a preset candidate strategy for a candidate scenario. Each candidate strategy includes a candidate filtering process determined for the corresponding candidate scenario. The candidate filtering process is generated by selecting multiple strategy operators for a corresponding candidate scenario and combining the selected multiple candidate operators according to the indicated candidate association relationship. Each candidate operator represents a unit operation determined for the original traffic data in the corresponding candidate scenario.

[0172] After the strategy output data is used as accurate traffic data that matches the business scenario, the execution module 1402 is also used for:

[0173] In response to a scheduling request carrying a plugin identifier with multiple candidate plugins, each candidate plugin of each plugin identifier is scheduled according to the indicated plugin scheduling relationship. Each time a scheduling is performed, the following operations are performed: according to the candidate association relationship in the candidate plugin, the corresponding unit operation in the candidate strategy is executed on the raw traffic data.

[0174] Until the scheduling completion information of each candidate plugin is obtained, the corresponding candidate output data is obtained, and the candidate output data is used as accurate traffic data that matches the business scenario.

[0175] In one possible implementation, after processing the candidate output data as precise traffic data that matches the business scenario, the execution module 1402 is further configured to:

[0176] In response to a plugin recommendation request, obtain key information for each of the multiple candidate plugins. Each key information includes at least: parameter information of the corresponding candidate plugin and historical loading information of the corresponding candidate plugin.

[0177] Based on the key information, the plugin evaluation values ​​of multiple candidate plugins are obtained, and the multiple candidate plugins are sorted in descending order according to the evaluation values ​​of each plugin.

[0178] From multiple candidate plugins, select at least one candidate plugin that meets the preset sorting criteria as the target plugin;

[0179] It is recommended to select at least one target plugin.

[0180] In one possible implementation, based on each key piece of information, the plugin evaluation value of each of the multiple candidate plugins is obtained, and the execution module 1402 is used to:

[0181] For multiple candidate plugins, perform the following operations respectively:

[0182] According to the preset evaluation rules, the parameter information of a candidate plugin is evaluated to obtain the parameter evaluation value of the candidate plugin. According to the evaluation rules, the historical loading information of a candidate plugin is evaluated to obtain the performance evaluation value of the candidate plugin.

[0183] The parameter evaluation value and performance evaluation value are weighted and summed to obtain the plugin evaluation value of a candidate plugin.

[0184] Based on the same technical concept, embodiments of this application provide a computer device, which can be... Figure 2 The device 202 shown, such as Figure 15 As shown, it includes at least one processor 1501 and a memory 1502 connected to at least one processor. In this embodiment, the specific connection medium between the processor 1501 and the memory 1502 is not limited. Figure 15 Taking the connection between processor 1501 and memory 1502 via a bus as an example, the bus can be divided into address bus, data bus, control bus, etc.

[0185] In this embodiment of the application, the memory 1502 stores instructions that can be executed by at least one processor 1501. By executing the instructions stored in the memory 1502, at least one processor 1501 can perform the steps of the above-described method for filtering traffic data.

[0186] The processor 1501 is the control center of the computer device, capable of connecting to various parts of the computer device via various interfaces and lines. It performs video editing by running or executing instructions stored in the memory 1502 and accessing data stored in the memory 1502. Optionally, the processor 1501 may include one or more processing units. The processor 1501 may integrate an application processor and a modem processor. The application processor primarily handles the operating system, user interface, and applications, while the modem processor primarily handles wireless communication. It is understood that the modem processor may not be integrated into the processor 1501. In some embodiments, the processor 1501 and the memory 1502 may be implemented on the same chip; in other embodiments, they may be implemented on separate chips.

[0187] Processor 1501 can be a general-purpose processor, such as a central processing unit (CPU), digital signal processor, application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0188] Memory 1502, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. Memory 1502 may include at least one type of storage medium, such as flash memory, hard disk, multimedia card, card-type memory, random access memory (RAM), static random access memory (SRAM), programmable read-only memory (PROM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic storage, magnetic disk, optical disk, etc. Memory 1502 can be any other medium capable of carrying or storing desired program code in the form of instructions or data structures that can be accessed by a computer, but is not limited thereto. In the embodiments of this application, memory 1502 can also be a circuit or any other device capable of implementing storage functions for storing program instructions and / or data.

[0189] Based on the same inventive concept, embodiments of this application provide a computer-readable storage medium storing a computer program executable by a computer device, which, when run on the computer device, causes the computer device to perform the steps of the above-described traffic data filtering method.

[0190] Based on the same inventive concept, this application provides a computer program product, which includes a computer program stored on a computer-readable storage medium. The computer program includes program instructions that, when executed by a computer, cause the computer to perform the steps of the above-described method for filtering traffic data.

[0191] This application provides a method, apparatus, electronic device, and storage medium for filtering traffic data. The method can be applied to a server and includes acquiring raw traffic data associated with a specified business scenario and a filtering strategy preset for the business scenario. Since the filtering strategy includes a traffic filtering process determined for the business scenario, the traffic filtering process is generated by multiple strategy operators associated with the business scenario and the operator association relationship between the multiple strategy operators. Each strategy operator represents a unit operation determined for the business scenario. Therefore, for the raw traffic data, each unit operation in the filtering strategy is executed according to the operator association relationship. That is, by reproducing the traffic filtering process, each filtering step for the raw traffic data is performed, thereby filtering out accurate traffic data that matches the business scenario from the raw traffic data. For example, suppose that in the filtering strategy associated with the regression testing scenario, the corresponding traffic filtering process is: "Obtain the code coverage of the original traffic data, calculate the similarity between the code coverage and the code coverage of the preset test cases, and remove the original traffic data when the similarity is greater than a preset threshold; otherwise, retain the original traffic data." This traffic filtering process is generated by strategy operators that represent each unit operation, such as "Obtain the code coverage of the original traffic data," "Calculate the similarity between the code coverage and the code coverage of the preset test cases," and "Remove the original traffic data," as well as the operator relationships between these strategy operators. Thus, by performing the corresponding unit operations on the original traffic data according to the operator relationships, the traffic filtering process in the filtering strategy is reproduced, and accurate traffic data matching the regression testing scenario is obtained.

[0192] From the server's perspective, by executing the filtering operations of each unit in the screening strategy on the raw traffic data, accurate traffic data matching the business scenario can be filtered out from the raw traffic data. From the client's perspective, by using multiple strategy operators associated with the business scenario and the operator relationships between these strategy operators, a corresponding filtering strategy for the business scenario can be generated. This eliminates the need for developers to manually write filtering strategies for the business scenario, reducing development manpower and time costs and improving the efficiency of traffic data filtering. Furthermore, by leveraging the multiple strategy operators associated with the business scenario and the operator relationships between them, when facing the same business scenario, the latest version of the filtering strategy corresponding to the business scenario can be generated by adjusting the operator relationships between multiple strategy operators. This fully utilizes the current filtering strategy corresponding to the business scenario, reduces resource waste, and improves the utilization rate of the filtering strategy.

[0193] Those skilled in the art will understand that embodiments of the present invention can be provided as methods or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0194] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0195] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0196] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0197] Although preferred embodiments of the invention 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 both the preferred embodiments and all changes and modifications falling within the scope of the invention.

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

Claims

1. A method for filtering traffic data, characterized in that, include: The system obtains raw traffic data associated with a specified business scenario and a preset strategy plugin for the business scenario. It loads the strategy plugin using a preset strategy loader to obtain a filtering strategy. The strategy plugin carries the filtering strategy, which includes a traffic filtering process determined for the business scenario. This process is generated by selecting multiple strategy operators corresponding to the business scenario and combining the selected operators according to indicated operator relationships. Each strategy operator represents a unit operation used for the raw traffic data in the business scenario, and each unit operation is used to implement a corresponding processing logic for filtering traffic data. According to the operator association relationship, the unit operations in the filtering strategy are executed on the original traffic data until the execution completion information of the filtering strategy is obtained, and the corresponding strategy output data is obtained. The strategy output data is then used as the accurate traffic data that matches the business scenario. The operator association relationship includes: the association relationship between at least two sets of strategy operators, and the association relationship between each strategy operator in each set of strategy operators. The association relationship between the sets of strategy operators includes at least a parallel relationship. The at least two sets of strategy operators are determined by the selection operation when selecting the plurality of strategy operators. Each set of strategy operators includes at least one strategy operator selected during the selection operation.

2. The method as described in claim 1, characterized in that, Before obtaining the preset filtering strategy for the business scenario, the method further includes: Obtain strategy description information determined for the business scenario, wherein the strategy description information includes: multiple functions to be executed determined for the business scenario, and each function to be executed is associated with a processing logic for filtering traffic data; From a preset set of operators, select multiple strategy operators associated with the multiple functions to be executed; In response to orchestration configuration operations triggered for the plurality of policy operators, the operator association relationships among the plurality of policy operators are determined, and the plurality of policy operators are combined according to the operator association relationships to generate corresponding filtering strategies.

3. The method as described in claim 2, characterized in that, The step of determining the operator association relationships among the multiple policy operators in response to an orchestration configuration operation triggered for the multiple policy operators includes: In response to a selection operation triggered for the plurality of policy operators, at least two sets of policy operators are determined; In response to an orchestration configuration operation triggered for the at least two policy operator subsets, the association between the at least two policy operator subsets and the association between each policy operator in each policy operator subset are determined.

4. The method as described in claim 3, characterized in that, The method of determining the association between the at least two policy operator subsets and the association between policy operators within each policy operator subset in response to an orchestration configuration operation triggered for the at least two policy operator subsets includes any one of the following: In response to a phase configuration operation triggered for the at least two policy operator subsets, it is determined that the association relationship between the at least two policy operator subsets is a serial relationship, and the association relationship between each policy operator in each policy operator subset is a serial relationship; In response to a task configuration operation triggered for the at least two policy operator subsets, it is determined that the association between the at least two policy operator subsets is a parallel relationship, and the association between each policy operator in each policy operator subset is a serial relationship; In response to a default configuration operation triggered for the at least two policy operator subsets, it is determined that the association relationship between the at least two policy operator subsets is a serial relationship, and the association relationship between each policy operator in each policy operator subset is a serial relationship.

5. The method according to any one of claims 1-4, characterized in that, Each candidate plugin carries a preset candidate strategy for a candidate scenario. Each candidate strategy includes a candidate filtering process determined for the corresponding candidate scenario. The candidate filtering process is generated by selecting multiple strategy operators for a candidate scenario and combining the selected multiple candidate operators according to the indicated candidate association relationship. Each candidate operator represents a unit operation determined for the original traffic data in the corresponding candidate scenario. After the strategy output data is used as accurate traffic data matching the business scenario, the method further includes: In response to a scheduling request carrying a plugin identifier with multiple candidate plugins, each candidate plugin of each plugin identifier is scheduled according to the indicated plugin scheduling relationship. Each time a scheduling is performed, the following operations are performed: according to the candidate association relationship among the candidate plugins, the corresponding unit operation in the candidate strategy is executed on the original traffic data. Until the scheduling completion information of each candidate plugin is obtained, the corresponding candidate output data is obtained, and the candidate output data is used as accurate traffic data that matches the business scenario.

6. The method as described in claim 5, characterized in that, After using the candidate output data as accurate traffic data that matches the business scenario, the method further includes: In response to the plugin recommendation request, the key information of each of the multiple candidate plugins is obtained, wherein each key information includes at least: the parameter information of the corresponding candidate plugin and the historical loading information of the corresponding candidate plugin; Based on each key piece of information, the plugin evaluation values ​​of the multiple candidate plugins are obtained respectively, and the multiple candidate plugins are sorted in descending order according to the plugin evaluation values. From the plurality of candidate plugins, at least one candidate plugin that meets the preset sorting conditions is selected as the target plugin; It is recommended to select at least one target plugin.

7. The method as described in claim 6, characterized in that, The step of obtaining the plugin evaluation value for each of the multiple candidate plugins based on each key piece of information includes: For each of the candidate plugins, perform the following operations: According to the preset evaluation rules, the parameter information of a candidate plugin is evaluated to obtain the parameter evaluation value of the candidate plugin. According to the evaluation rules, the historical loading information of the candidate plugin is evaluated to obtain the performance evaluation value of the candidate plugin. The parameter evaluation value and the performance evaluation value are weighted and summed to obtain the plugin evaluation value of the candidate plugin.

8. A device for filtering traffic flow data, characterized in that, include: The strategy acquisition module is used to acquire raw traffic data associated with a specified business scenario and to acquire a preset strategy plugin for the business scenario. The strategy plugin is loaded through a preset strategy loader to acquire a filtering strategy. The strategy plugin carries the filtering strategy, which includes a traffic filtering process determined for the business scenario. The traffic filtering process is generated by selecting multiple strategy operators corresponding to the business scenario and combining the selected multiple strategy operators according to the indicated operator association relationship. Each strategy operator represents a unit operation determined for the raw traffic data under the business scenario. Each unit operation is used to implement a corresponding processing logic for filtering traffic data. The execution module is used to execute the unit operations of the filtering strategy on the original traffic data according to the operator association relationship, until the execution completion information of the filtering strategy is obtained, obtain the corresponding strategy output data, and use the strategy output data as accurate traffic data matching the business scenario. The operator association relationship includes: the association relationship between at least two strategy operator sets, and the association relationship between each strategy operator in each strategy operator set; the association relationship between strategy operator sets includes at least a parallel relationship; the at least two strategy operator sets are determined by the selection operation when selecting the multiple strategy operators; each strategy operator set includes at least one strategy operator selected during the selection operation.

9. The apparatus as claimed in claim 8, characterized in that, Before obtaining the preset filtering strategy for the business scenario, the strategy acquisition module is further configured to: Obtain strategy description information determined for the business scenario, wherein the strategy description information includes: multiple functions to be executed determined for the business scenario, and each function to be executed is associated with a processing logic for filtering traffic data; From a preset set of operators, select multiple strategy operators associated with the multiple functions to be executed; In response to orchestration configuration operations triggered for the plurality of policy operators, the operator association relationships among the plurality of policy operators are determined, and the plurality of policy operators are combined according to the operator association relationships to generate corresponding filtering strategies.

10. The apparatus as claimed in claim 9, characterized in that, In response to the orchestration configuration operation triggered for the plurality of policy operators, the policy acquisition module determines the operator association relationship among the plurality of policy operators, wherein the policy acquisition module is used to: In response to a selection operation triggered for the plurality of policy operators, at least two sets of policy operators are determined; In response to an orchestration configuration operation triggered for the at least two policy operator subsets, the association between the at least two policy operator subsets and the association between each policy operator in each policy operator subset are determined.

11. The apparatus as claimed in claim 10, characterized in that, The method of determining the association between the at least two policy operator subsets and the association between policy operators within each policy operator subset in response to an orchestration configuration operation triggered for the at least two policy operator subsets includes any one of the following: In response to a phase configuration operation triggered for the at least two policy operator subsets, it is determined that the association relationship between the at least two policy operator subsets is a serial relationship, and the association relationship between each policy operator in each policy operator subset is a serial relationship; In response to a task configuration operation triggered for the at least two policy operator subsets, it is determined that the association between the at least two policy operator subsets is a parallel relationship, and the association between each policy operator in each policy operator subset is a serial relationship; In response to a default configuration operation triggered for the at least two policy operator subsets, it is determined that the association relationship between the at least two policy operator subsets is a serial relationship, and the association relationship between each policy operator in each policy operator subset is a serial relationship.

12. The apparatus according to any one of claims 8-11, characterized in that, Each candidate plugin carries a preset candidate strategy for a candidate scenario. Each candidate strategy includes a candidate filtering process determined for the corresponding candidate scenario. The candidate filtering process is generated by selecting multiple strategy operators for a candidate scenario and combining the selected multiple candidate operators according to the indicated candidate association relationship. Each candidate operator represents a unit operation determined for the original traffic data in the corresponding candidate scenario. After the strategy output data is used as accurate traffic data matching the business scenario, the method further includes: In response to a scheduling request carrying a plugin identifier with multiple candidate plugins, each candidate plugin of each plugin identifier is scheduled according to the indicated plugin scheduling relationship. Each time a scheduling is performed, the following operations are performed: according to the candidate association relationship among the candidate plugins, the corresponding unit operation in the candidate strategy is executed on the original traffic data. Until the scheduling completion information of each candidate plugin is obtained, the corresponding candidate output data is obtained, and the candidate output data is used as accurate traffic data that matches the business scenario.

13. The apparatus as claimed in claim 12, characterized in that, After using the candidate output data as accurate traffic data that matches the business scenario, the execution module is further configured to: In response to the plugin recommendation request, the key information of each of the multiple candidate plugins is obtained, wherein each key information includes at least: the parameter information of the corresponding candidate plugin and the historical loading information of the corresponding candidate plugin; Based on each key piece of information, the plugin evaluation values ​​of the multiple candidate plugins are obtained respectively, and the multiple candidate plugins are sorted in descending order according to the plugin evaluation values. From the plurality of candidate plugins, at least one candidate plugin that meets the preset sorting conditions is selected as the target plugin; It is recommended to select at least one target plugin.

14. The apparatus as claimed in claim 13, characterized in that, The step of obtaining the plugin evaluation value for each of the multiple candidate plugins based on each key piece of information, and the execution module is used to: For each of the candidate plugins, perform the following operations: According to the preset evaluation rules, the parameter information of a candidate plugin is evaluated to obtain the parameter evaluation value of the candidate plugin. According to the evaluation rules, the historical loading information of the candidate plugin is evaluated to obtain the performance evaluation value of the candidate plugin. The parameter evaluation value and the performance evaluation value are weighted and summed to obtain the plugin evaluation value of the candidate plugin.

15. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the method according to any one of claims 1 to 7.

16. A computer-readable storage medium, characterized in that, It stores a computer program executable by a computer device, which, when run on the computer device, causes the computer device to perform the steps of any one of claims 1 to 7.

17. A computer program product, characterized in that, The computer program product includes a computer program stored on a computer-readable storage medium, the computer program including program instructions that, when executed by a computer, cause the computer to perform the steps of the method according to any one of claims 1-7.

Images