A traffic labeling method and apparatus based on rule matching

Abstract

This invention discloses a traffic marking method and apparatus based on rule matching. (i) If a program script is set for the matching rule, the program script is executed first for matching; (ii) If the script execution result is true, it indicates a match, and the request traffic is marked according to the pre-set marking; (iii) If it returns false, it indicates no match, and the traffic is not marked; (iv) The parameters of the script program are the request parameters of the system interface, which are dynamically passed to the script program when the script is run, and then the complex logic of the script program is used to finally give the result of whether to mark; (v) If no script is set, the basic rule information provided is used for matching and marking. This invention uses a combination of basic rules and advanced scripts, which can be flexibly applied to meet the marking requirements of different scenarios.

Description

Technical Field

[0001] This invention relates to the field of inter-system traffic management, and specifically to a traffic labeling method and apparatus based on rule matching. Background Technology

[0002] In today's rapidly iterating internet technology landscape, application releases are happening at an ever-increasing pace, and system request traffic is surging. This leads to demands for release stability, controllable release failure range, and reliable performance. Consequently, the need to differentiate between system call traffic is growing stronger. The traditional industry approach is to include version information at the traffic entry point to mark and differentiate traffic, or to deploy a separate system environment for purposes such as release verification, system load testing, and A / B testing. However, traditional methods suffer from drawbacks such as extremely high maintenance costs for the entire environment, low reusability of version number methods, and a lack of flexibility in identifying traffic across the entire link, resulting in significantly reduced effectiveness and failing to adequately address the problem. Summary of the Invention

[0003] The technical problem to be solved by the present invention is a traffic marking method and device based on rule matching, which aims to solve the problem of system traffic differentiation in order to achieve the purposes of fault-controlled release, traffic stress testing, A / B testing, data collection and analysis.

[0004] This invention is achieved through the following technical solution: a traffic labeling method based on rule matching.

[0005] include:

[0006] (i) If the matching rule is set to a program script, the program script matching will be executed first;

[0007] (ii) If the script execution result is true, it means a match has been found, and the request traffic is marked according to the pre-set tags;

[0008] (iii) If false is returned, it indicates that no match was found and the traffic is not marked;

[0009] (iv) The parameters of the script program are the request parameters of the system interface. They are dynamically passed to the script program when the script is running, and then the complex logic of the script program is executed to finally give the result of whether it is marked or not.

[0010] (v) If no script is set, the provided basic rule information will be used for matching and marking.

[0011] As a preferred technical solution, it includes the following two aspects: a method for loading / updating rules and a method for using rules to match and mark traffic.

[0012] As a preferred technical solution, the rule loading / updating method specifically includes the following steps:

[0013] S1. Construct RE information;

[0014] S2. Obtain rule data by requesting the URL of the rule loading address according to the system configuration;

[0015] S3. Obtain the returned RS;

[0016] S4. Check if RS's code is 0. If not, execute S5; otherwise, execute S6.

[0017] S5. Obtain the RU information contained in RS and update the local RU cache;

[0018] S6, This update is now complete.

[0019] As a preferred technical solution, the method of marking traffic using rule matching specifically includes the following steps:

[0020] SS1 receives an external HTTP request R;

[0021] SS2, intercept request R traffic;

[0022] SS3: Obtain request R parameter information PARAM and path information PATH;

[0023] SS4. Check if the corresponding system tagging rule RU is cached locally. If so, execute SS5; otherwise, execute SS15.

[0024] SS5: Get RU, check if the enable state is true. If it is, execute SS6; otherwise, execute SS15.

[0025] If SS6 and RU have scriptS set, execute SS7; otherwise execute SS11.

[0026] SS7, construct the script execution parameters, which include the PARAM and PATH mentioned above;

[0027] SS8: Executes the specified S-script program using the script engine;

[0028] SS9. Determine the return result. If it is true, execute SS10; otherwise, execute SS15.

[0029] SS10: Use the RU's coloringTag information to mark traffic, then execute SS15;

[0030] SS11. Is the PATH of traffic R included in the applyInterfacePath of RU? If yes, execute SS12; otherwise, execute SS15.

[0031] SS12: Randomly generate random numbers between 1 and 100 in RAM;

[0032] SS13. Determine if RAM is less than the coloringPercent value of RU. If so, execute SS14; otherwise, execute SS15.

[0033] SS14. Use the RU's coloringTag information to tag traffic;

[0034] SS15, Mark the end of the traffic flow.

[0035] A flow rate marking device according to the present invention includes:

[0036] The RU maintenance module provides RU maintenance functions, offering interfaces for adding and modifying rules to facilitate rule management. Furthermore, the RU maintenance module is responsible for interaction when the application system starts up or periodically retrieves rules, retrieving the held RUs based on the application system's request parameters and returning the results.

[0037] The traffic interception module is used to intercept incoming traffic R. Only by intercepting traffic R from other systems can the next step of tagging rule matching and traffic tagging be carried out. The traffic interception module uses a language-specific implementation to dynamically intercept all HTTP interfaces exposed by the current system. Therefore, when a request comes in, it will intercept the traffic in a way similar to aspect and collect the parameters of R and the actual HTTP path and pass them to the RU application module.

[0038] The RU application module is the core module for traffic marking. The RU application module is responsible for the core logic of traffic marking and the local RU rule cache. After the request interception module intercepts external requests, it parses the path and parameter information and hands it over to the RU application module. After obtaining the specific information, the RU application module determines whether the target needs to be met based on the marking rule status and specific rule information, and implements specific traffic marking actions according to the marking algorithm.

[0039] The U loading / update module is responsible for the initial loading and polling updates of RUs. During system startup, the U loading / update module communicates with the RU maintenance module according to the configured URL to obtain the RU information currently configured in the system, and conducts periodic polling communication after startup to obtain the latest rule configuration. After obtaining the RU information, it calls the RU application module to update the local RU cache.

[0040] The beneficial effects of this invention are: This invention aims to solve the problem of system traffic differentiation in order to achieve the purposes of fault-controllable release, traffic stress testing, A / B testing, data collection and analysis, etc. It adopts a combination of basic rules and advanced scripts to flexibly meet the marking requirements of different scenarios. Attached Figure Description

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

[0042] Figure 1 This is a flowchart of a tagging rule loading / refreshing process provided in an embodiment of the present invention;

[0043] Figure 2 A flowchart of traffic marking using marking rules is provided as an embodiment of the present invention;

[0044] Figure 3 This is a schematic diagram of a flow marking device provided in an embodiment of the present invention. Detailed Implementation

[0045] All features disclosed in this specification, or all steps in all disclosed methods or processes, may be combined in any way, except for mutually exclusive features and / or steps.

[0046] Any feature disclosed in this specification (including any appended claims, abstract, and drawings) may be replaced by other equivalent or similar features, unless specifically stated otherwise. That is, unless specifically stated otherwise, each feature is merely one example of a series of equivalent or similar features.

[0047] like Figure 1 As shown, the present invention provides a traffic marking method based on rule matching, which includes a specific rule data structure RU, which contains information in the following dimensions: {"updateTime":123145678, / / rule update timestamp;

[0048] "serviceName":xxxx, / / Which system the rule applies to;

[0049] "enable":true, / / Whether the rule is enabled;

[0050] "applyInterfacePath":[ / path1, / path2], / / Which system interface the rule applies to;

[0051] "coloringTag":"test", / / What content to use to mark request traffic that matches the rule;

[0052] "coloringPercent":80, / / Mark the traffic when it matches the rule and falls within the configured percentage;

[0053] "script":"xxxx" / / More complex and advanced support for programmable scripts to determine whether to tag traffic;}

[0054] The last item in the aforementioned specific data structure includes a script (a dynamically executable program). This is a more advanced way of marking traffic than basic rule matching. Therefore, in addition to supporting traffic marking based on basic rule matching, this invention also provides a more advanced method of dynamically weaving in a program script (the specific scripting language is not limited) to mark traffic. Specifically, if a program script is set in the matching rule, the program script is executed first for matching. If the script execution result is true, it means a match has been found, and the request traffic is marked according to the pre-set marking. If it returns false, it means no match has been found, and the traffic is not marked. The parameters of the script program are the request parameters of the system interface, which are dynamically passed to the script program when it runs. Then, the complex logic of the script program executes to finally give the result of whether to mark or not. If no script is set, the basic rule information is used for matching and marking. The combination of basic rules and advanced scripts allows for flexible application and meets the marking requirements of different scenarios.

[0055] In other embodiments, the present invention proposes a traffic marking method based on rule matching, which includes a rule loading / updating data structure containing information in the following dimensions:

[0056] Rule loading / fetch request (RE)

[0057] {"nodeIp":"192.168.1.1", / / Node IP, supports deploying rules to a single system node.}

[0058] "serviceName":"xxxxxx" / / system name}

[0059] The response data structure RS{"code":0, / / 0 indicates success, 404 indicates that the tagging rule corresponding to the specified system was not found;

[0060] "message":"Error message","rule":{xxxxx} / / The above specific rule data structure RU}.

[0061] like Figure 1 As shown, in this embodiment, the rule loading / updating method specifically includes the following steps:

[0062] S1. Construct RE information;

[0063] S2. Obtain rule data by requesting the URL of the rule loading address according to the system configuration;

[0064] S3. Obtain the returned RS;

[0065] S4. Check if RS's code is 0. If not, execute S5; otherwise, execute S6.

[0066] S5. Obtain the RU information contained in RS and update the local RU cache;

[0067] S6, This update is now complete.

[0068] like Figure 2 As shown, in this embodiment, the method of marking traffic using rule matching specifically includes the following steps:

[0069] SS1 receives an external HTTP request R;

[0070] SS2, intercept request R traffic;

[0071] SS3: Obtain request R parameter information PARAM and path information PATH;

[0072] SS4. Check if the corresponding system tagging rule RU is cached locally. If so, execute SS5; otherwise, execute SS15.

[0073] SS5: Get RU, check if the enable state is true. If it is, execute SS6; otherwise, execute SS15.

[0074] If SS6 and RU have scriptS set, execute SS7; otherwise execute SS11.

[0075] SS7, construct the script execution parameters, which include the PARAM and PATH mentioned above;

[0076] SS8: Executes the specified S-script program using the script engine;

[0077] SS9. Determine the return result. If it is true, execute SS10; otherwise, execute SS15.

[0078] SS10: Use the RU's coloringTag information to mark traffic, then execute SS15;

[0079] SS11. Is the PATH of traffic R included in the applyInterfacePath of RU? If yes, execute SS12; otherwise, execute SS15.

[0080] SS12: Randomly generate random numbers between 1 and 100 in RAM;

[0081] SS13. Determine if RAM is less than the coloringPercent value of RU. If so, execute SS14; otherwise, execute SS15.

[0082] SS14. Use the RU's coloringTag information to tag traffic;

[0083] SS15, Mark the end of the traffic flow.

[0084] like Figure 3 As shown, a flow rate marking device of the present invention includes:

[0085] The RU maintenance module provides RU maintenance functions, offering interfaces for adding and modifying rules to facilitate rule management. Furthermore, the RU maintenance module is responsible for interaction when the application system starts up or periodically retrieves rules, retrieving the held RUs based on the application system's request parameters and returning the results.

[0086] The traffic interception module is used to intercept incoming traffic R. Only by intercepting traffic R from other systems can the next step of tagging rule matching and traffic tagging be carried out. The traffic interception module uses a language-specific implementation to dynamically intercept all HTTP interfaces exposed by the current system. Therefore, when a request comes in, it will intercept the traffic in a way similar to aspect and collect the parameters of R and the actual HTTP path and pass them to the RU application module.

[0087] The RU application module is the core module for traffic marking. The RU application module is responsible for the core logic of traffic marking and the local RU rule cache. After the request interception module intercepts external requests, it parses the path and parameter information and hands it over to the RU application module. After obtaining the specific information, the RU application module determines whether the target needs to be met based on the marking rule status and specific rule information, and implements specific traffic marking actions according to the marking algorithm.

[0088] The U loading / update module is responsible for the initial loading and polling updates of RUs. During system startup, the U loading / update module communicates with the RU maintenance module according to the configured URL to obtain the RU information currently configured in the system, and conducts periodic polling communication after startup to obtain the latest rule configuration. After obtaining the RU information, it calls the RU application module to update the local RU cache.

[0089] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions conceived without inventive effort should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope defined in the claims.

Claims

1. A traffic labeling method based on rule matching, characterized in that, The process includes the following steps: (i) If the matching rule is set with a program script, the program script will be executed first for matching; (ii) If the result of the script execution is true, it means that a match has been found, and the request traffic will be marked according to the pre-set tags; (iii) If it returns false, it means that no match has been found, and the traffic will not be marked. (iv) The parameters of the script program are the request parameters of the system interface. They are dynamically passed to the script program when the script is run, and then the complex logic of the script program is executed to finally give the result of whether to mark or not; (v) If no script is set, the basic rule information provided is used for matching and marking. It includes the following two aspects: methods for loading / updating rules and methods for using rules to match and mark traffic; The rule loading / updating method specifically includes the following steps: S1, construct RE information; S2, request and obtain rule data according to the rule loading address URL configured by the system; S3, obtain the returned RS; S4, determine whether the code of the RS is 0. If not, execute S5; otherwise, execute S6; S5, obtain the RU information contained in the RS and update the local RU cache; S6, This update is now complete; The method of using rule matching to mark traffic specifically includes the following steps: SS1, receiving an external HTTP request R; SS2. Intercept request R traffic; SS3. Obtain request R parameter information PARAM and path information PATH; SS4. Check if the corresponding system tagging rule RU is cached locally. If yes, execute SS5; otherwise, execute SS15; SS5. Obtain RU and check if the enable status is true. If yes, execute SS6; otherwise, execute SS15; SS6. Check if RU's scriptS is set. If yes, execute SS7; otherwise, execute SS11; SS7. Construct script execution parameters, which include the above PARAM and PATH; SS8. Execute the specified S script program using the script engine; SS9. Check the return result. If true, execute SS10; otherwise, execute SS15; SS10. Tag traffic using RU's coloringTag information and execute SS15; SS11. Check if traffic R's PATH is included in RU's applyInterfacePath. If yes, execute SS12; otherwise, execute SS15; SS12. Randomly generate a random number RAM between 1 and 100. SS13. Determine if RAM is less than the coloringPercent value of RU. If yes, execute SS14; otherwise, execute SS15. SS14. Use the coloringTag information of RU to mark the traffic. SS15. Mark the end of the traffic process.

2. A flow rate marking device, characterized in that, include: The RU maintenance module provides RU maintenance functions, offering interfaces for adding and modifying rules to facilitate rule management. Furthermore, the RU maintenance module is responsible for interaction when the application system starts up or periodically retrieves rules, retrieving the held RUs based on the application system's request parameters and returning the results. The traffic interception module is used to intercept incoming traffic R. Only by intercepting traffic R from other systems can the next step of tagging rule matching and traffic tagging be carried out. The traffic interception module uses a language-specific implementation to dynamically intercept all HTTP interfaces exposed by the current system. Therefore, when a request comes in, it will intercept the traffic in a way similar to aspect and collect the parameters of R and the actual HTTP path and pass them to the RU application module. RU application module, traffic labeling core module; The RU application module is responsible for the core logic of traffic marking and the local RU rule cache. After the request interception module intercepts external requests, it parses the path and parameter information and hands it over to the RU application module. After receiving the specific information, the RU application module determines whether the target needs to be met based on the labeling rule status and specific rule information, and implements the specific traffic marking action according to the labeling algorithm. The U loading / update module is responsible for the initial loading of RUs and polling updates. During the system startup phase, the U loading / update module is responsible for communicating with the RU maintenance module according to the configured URL to obtain the RU information currently configured in the system, and for periodically polling communication after startup to obtain the latest rule configuration. After obtaining the RU information, the RU application module is called to update the local RU cache.

Images