Dynamic flow distribution system based on rule engine
By introducing dynamic traffic distribution technology based on rules engine in the traffic distribution system, the existing system lacks flexibility and efficiency when new functions are released is solved, efficient traffic scheduling and optimized allocation are achieved, and system performance and stability are improved.
Patent Information
- Application Number
- CN202411721254.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-11-28
- Publication Date
- 2025-03-21
- Estimated Expiration
- Not applicable · inactive patent
AI Technical Summary
The existing traffic allocation system lacks flexibility and efficiency when new functions are released, and cannot dynamically adjust traffic allocation strategies based on user characteristics and behavior, resulting in insufficient risk assessment and performance testing of new functions, which may increase the risk of system instability.
A dynamic traffic allocation system based on rules engine is adopted, and through the combination of client integration modules, rules engine modules, traffic allocation modules and rule configuration modules, flexible rule configuration and precise traffic matching are achieved, and the traffic allocation strategy is dynamically adjusted.
It realizes efficient scheduling and optimized allocation of traffic, improves system resource utilization and load balancing capabilities, enhances system scalability and compatibility, provides users with better service experience, and provides operation and maintenance personnel with convenient monitoring and analysis methods, thereby comprehensively improving the performance and stability of the system.
Smart Images
Figure CN119668846A_ABST
Abstract
Description
Technical Field
[0001] The invention relates to the technical field of software development and testing, and in particular to a dynamic flow distribution system based on a rule engine. Background Art
[0002] The existing traffic allocation system lacks flexibility and efficiency when releasing new functions, and cannot dynamically adjust the traffic allocation strategy according to user characteristics and behaviors. This leads to inaccurate risk assessment and performance testing of new functions, which may increase the risk of system instability. To solve this problem, it is necessary to develop a dynamic traffic allocation system based on a rule engine, which can dynamically adjust traffic allocation according to preset rules and user attributes in real time and flexibly.
[0003] The information disclosed in this background technology section is only intended to deepen the understanding of the overall background technology of the present invention, and should not be regarded as acknowledging or suggesting in any form that the information constitutes the prior art already known to those skilled in the art. Summary of the invention
[0004] In view of the defects existing in the prior art, the purpose of the present invention is to provide a dynamic traffic distribution system based on a rule engine, which realizes efficient scheduling and optimal distribution of traffic through flexible rule configuration and precise traffic matching, improves system resource utilization and load balancing capabilities, and at the same time enhances the scalability and compatibility of the system, providing users with a better service experience, and providing operation and maintenance personnel with convenient monitoring and analysis methods, thereby comprehensively improving the performance and stability of the system.
[0005] In order to achieve the above purpose, the technical solution adopted by the present invention is:
[0006] A dynamic traffic distribution system based on a rule engine, characterized by comprising:
[0007] The client integration module is used to initiate a traffic allocation request, to initiate a traffic scheduling request, to collect traffic execution results and generate monitoring logs;
[0008] A rule engine module is used to respond to traffic allocation requests, to parse traffic allocation rules to obtain traffic matching logic, to perform matching processing according to the traffic allocation rules, and to generate a traffic scheduling permission identifier if the match is successful;
[0009] A flow distribution module, used to respond to flow scheduling requests and to perform specific flow scheduling according to flow scheduling permission identifiers;
[0010] The rule configuration module is used to set and modify traffic distribution rules.
[0011] On the basis of the above technical solution, based on any one of the following triggering methods, the client integration module initiates a traffic allocation request:
[0012] Obtain user attributes, and when the characteristic values in the user attributes meet the preset conditions, trigger the client integration module to initiate a traffic allocation request;
[0013] Obtain information about the server interacting with the client. When the server middleware is activated, the client interacting with the server meets the triggering condition, triggering the client integration module to initiate a traffic allocation request.
[0014] Obtain the role allocation information of the load balancer. When the role allocation ratio is not full, the client interacting with the load balancer meets the trigger condition, triggering the client integration module to initiate a traffic allocation request.
[0015] Get the trigger status of the external trigger. When a specific event occurs, the external trigger broadcasts to the preset client group, triggering the client integration module to initiate a traffic allocation request.
[0016] Based on the above technical solution, the flow rate refers to any one of the following:
[0017] Data processing volume, i.e. the ratio of the volume of data processed by the program modules consisting of the new code to the volume of data processed by the program modules consisting of the old code;
[0018] User participation, which refers to the ratio of the number of users whose data is processed by the new code to the number of users whose data is processed by the old code;
[0019] User request volume refers to the ratio of the number of requests processed by the new code per second to the number of requests processed by the old code per second.
[0020] Based on the above technical solution, the traffic allocation rule is used to define the traffic matching logic, which includes:
[0021] Assign condition parameters to define the specific conditions that trigger the match;
[0022] The priority parameter is used to determine the order of effective traffic allocation rules when multiple traffic allocation rules meet the allocation condition parameters;
[0023] Target routing parameters are used to set the target to which the request should be directed when the allocation condition parameters are met;
[0024] Weight parameter, used to dynamically adjust the traffic size according to the scenario identifier in the request parameter;
[0025] After parsing the traffic distribution rules, the traffic matching logic is obtained to determine the currently effective distribution conditions, target routes and weights.
[0026] Based on the above technical solution, the rule engine module first uses a parser to parse the traffic distribution rules. The parser will perform syntax analysis and semantic analysis on the traffic distribution rules in sequence;
[0027] When the rule engine module is started or receives a rule update notification, it triggers the parsing process, and the parsed rules are stored in the memory for fast access and matching.
[0028] Based on the above technical solution, the traffic matching logic is represented as a rule list or rule tree, where each node represents a rule and the connection between nodes represents the priority order;
[0029] By traversing the rule list or rule tree, the conditional expression of each rule is evaluated, and whether the match is successful is determined based on the evaluation result.
[0030] Based on the above technical solution, when receiving a traffic allocation request from a client, the rule engine module extracts information from the request;
[0031] Use the generated traffic matching logic to match the request;
[0032] If the match is successful, a traffic scheduling permission identifier is generated and returned to the client; if the match fails, the request is processed according to the default policy.
[0033] On the basis of the above technical solution, the rule engine module matches the clients one by one based on the currently effective allocation conditions, target routes and weights. If the match passes, the client is recorded and a traffic scheduling permission identifier is allocated to it.
[0034] On the basis of the above technical solution, when the traffic allocation module responds to the traffic scheduling request, it verifies the traffic scheduling permission identifier, and performs specific traffic scheduling operations for the client with the traffic scheduling permission identifier.
[0035] Based on the above technical solution, the traffic scheduling permission identifier contains specific information about how to route requests to a specific service instance, which code version to use, or which processing logic to apply, and the traffic allocation module executes corresponding traffic scheduling decisions based on the information.
[0036] The dynamic flow distribution system based on rule engine described in the present invention has the following features:
[0037] Beneficial effects:
[0038] Through flexible rule configuration and precise traffic matching, efficient scheduling and optimal allocation of traffic are achieved, which improves system resource utilization and load balancing capabilities. At the same time, it enhances the scalability and compatibility of the system, provides users with a better service experience, and provides operation and maintenance personnel with convenient monitoring and analysis methods, thereby comprehensively improving the performance and stability of the system. BRIEF DESCRIPTION OF THE DRAWINGS
[0039] The present invention has the following accompanying drawings:
[0040] The accompanying drawings are used to better understand the present invention and do not constitute an improper limitation of the present invention.
[0041] Figure 1 System architecture diagram of embodiment 1 of a dynamic traffic distribution system based on a rule engine described in the present invention. DETAILED DESCRIPTION
[0042] The present invention is further described in detail below in conjunction with the accompanying drawings. The detailed description is an explanation made in conjunction with the exemplary embodiments of the present invention, including various details of the embodiments of the present invention to facilitate understanding, which should be considered as merely exemplary. Therefore, it should be recognized by those skilled in the art that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for the sake of clarity and conciseness, the description of well-known functions and structures is omitted in the following description.
[0043] like Figure 1 As shown, the dynamic traffic distribution system based on rule engine described in the present invention includes:
[0044] The client integration module is used to initiate a traffic allocation request, to initiate a traffic scheduling request, to collect traffic execution results and generate monitoring logs;
[0045] A rule engine module is used to respond to traffic allocation requests, to parse traffic allocation rules to obtain traffic matching logic, to perform matching processing according to the traffic allocation rules, and to generate a traffic scheduling permission identifier if the match is successful;
[0046] A flow distribution module, used to respond to flow scheduling requests and to perform specific flow scheduling according to flow scheduling permission identifiers;
[0047] The rule configuration module is used to set and modify traffic distribution rules.
[0048] In this embodiment, the client integration module is the entry point of the system, responsible for initiating traffic allocation requests and scheduling requests, and collecting traffic execution results to generate monitoring logs;
[0049] The rule engine module is responsible for responding to traffic allocation requests, parsing traffic allocation rules, and matching according to the rules. Through the rule engine, the system can implement complex traffic allocation logic, such as matching based on user attributes, behaviors, request parameters and other conditions; generating traffic scheduling permission identification as the basis for subsequent traffic scheduling;
[0050] The traffic allocation module performs specific traffic scheduling operations according to the traffic scheduling permission identifier, and can allocate requests to different services or code versions according to the decision of the rule engine, thereby realizing dynamic traffic allocation;
[0051] The rule configuration module provides a friendly configuration interface or API, allowing users to flexibly adjust traffic distribution strategies to adapt to different business needs and test scenarios.
[0052] In this embodiment, initiating a traffic allocation request can be understood as a preliminary screening and authentication process, which determines whether the client is eligible to obtain traffic scheduling permission; and the traffic scheduling request is the process of actually executing traffic scheduling, which relies on the permission identifier to perform specific scheduling operations, specifically:
[0053] The traffic allocation request includes:
[0054] Request initiation: The client integration module initiates a traffic distribution request based on preset trigger conditions (such as user attributes, server status, load balancing information, etc.).
[0055] Rule matching: After receiving the request, the rule engine module will match it according to the predefined traffic distribution rules. These rules define the specific conditions, priorities, target routes, and weights that trigger the match.
[0056] Generate permission: If a request meets the conditions of a rule, the rule engine module generates a traffic scheduling permission identifier. This identifier contains specific information about how to route the request to a specific service instance, which code version to use, or which processing logic to apply.
[0057] Traffic scheduling requests include:
[0058] Request submission: After obtaining the traffic scheduling permission identifier, the client integration module will submit a traffic scheduling request to the traffic allocation module.
[0059] Permit Verification: After receiving the request, the traffic allocation module will first verify the validity of the traffic scheduling permission identifier. This includes checking whether the identifier is expired, whether it has been tampered with, and whether it meets the current system scheduling policy.
[0060] Execute scheduling: If the permission token is valid, the traffic distribution module will perform specific traffic scheduling operations based on the information in the token. This may include routing requests to a specific service instance, using a specific code version, or applying specific processing logic.
[0061] Result feedback: After the traffic scheduling is completed, the traffic allocation module may feed back the scheduling results to the client integration module or related monitoring system for subsequent analysis and optimization.
[0062] On the basis of the above technical solution, based on any one of the following triggering methods, the client integration module initiates a traffic allocation request:
[0063] Obtain user attributes. When the characteristic value in the user attributes meets the preset conditions, the client integration module is triggered to initiate a traffic allocation request. For example, when the user's permission characteristic value belongs to the experimental group, the client integration module is triggered to initiate a traffic allocation request.
[0064] Obtain information about the server interacting with the client. When the server middleware is in an activated state, the client interacting with the server meets the triggering condition, triggering the client integration module to initiate a traffic allocation request. For example, if server A interacts with client A and server middleware A installed on it is in an activated state, the client integration module in client A initiates a traffic allocation request.
[0065] Obtain the role allocation information of the load balancer. When the role allocation ratio is not full, the client interacting with the load balancer meets the trigger condition, triggering the client integration module to initiate a traffic allocation request.
[0066] Get the trigger status of the external trigger. When a specific event occurs, the external trigger broadcasts to the preset client group, triggering the client integration module to initiate a traffic allocation request.
[0067] Based on the above technical solution, the flow rate refers to any one of the following:
[0068] Data processing volume, the ratio of the amount of data processed by the program module composed of the new code to the amount of data processed by the program module composed of the old code; on the one hand, the size of the ratio reflects the degree of risk distribution between the new and old codes. When the stability or performance of the new code is uncertain, a small part of the traffic is first processed by the new code to reduce possible negative impacts; on the other hand, by monitoring the ratio of the amount of data processed by the new code to the amount of data processed by the old code, the performance of the new code can be evaluated. If the new code can efficiently process the amount of data assigned to it, the ratio may gradually increase; on the other hand, the size of the ratio also reflects the scope of impact of the new function or change on users. A smaller ratio may mean that the new change is being tested on a small scale, while a larger ratio may mean that the new change is being promoted to more users;
[0069] The number of users participating refers to the ratio of the number of users whose data is processed by the new code to the number of users whose data is processed by the old code. Traffic can represent the number of users who participate in the use of the new code. In the initial stage, only a small number of users will be assigned to the new code. As the test progresses and the stability is improved, more users will be gradually assigned to the new code.
[0070] The number of user requests refers to the ratio of the number of requests processed by the new code per second to the number of requests processed by the old code per second. The number of processed requests reflects the efficiency of request processing. The proportion of requests processed by the new code can be gradually increased, thereby realizing the gradual deployment and testing of the new code.
[0071] Based on the above technical solution, the traffic allocation rule is used to define the traffic matching logic, which includes:
[0072] Assign condition parameters to define the specific conditions that trigger the match; for example, a field in the request parameter must be equal to a certain value, or the user's geographic location must be within a certain range;
[0073] The priority parameter is used to determine the order of effective traffic allocation rules when multiple traffic allocation rules meet the allocation condition parameters;
[0074] Target routing parameters are used to set the target to which the request should be directed when the allocation condition parameters are met;
[0075] The weight parameter is used to dynamically adjust the traffic size according to the scenario identifier in the request parameter; for example, 70% of the traffic is allocated to the corresponding version A, and 30% of the traffic is allocated to the version B corresponding to the new code;
[0076] After parsing the traffic distribution rules, the traffic matching logic is obtained to determine the currently effective distribution conditions, target routes and weights.
[0077] Based on the above technical solution, the rule engine module first uses a parser to parse the traffic distribution rules. The parser will perform syntax analysis and semantic analysis on the traffic distribution rules in sequence;
[0078] When the rule engine module is started or receives a rule update notification, it triggers the parsing process, and the parsed rules are stored in the memory for fast access and matching.
[0079] Based on the above technical solution, the traffic matching logic is represented as a rule list or rule tree, where each node represents a rule and the connection between nodes represents the priority order;
[0080] By traversing the rule list or rule tree, the conditional expression of each rule is evaluated, and whether the match is successful is determined based on the evaluation result.
[0081] Based on the above technical solution, when receiving a traffic allocation request from a client, the rule engine module extracts information from the request;
[0082] Use the generated traffic matching logic to match the request;
[0083] If the match is successful, a traffic scheduling permission identifier is generated and returned to the client; if the match fails, the request is processed according to the default policy.
[0084] On the basis of the above technical solution, the rule engine module matches the clients one by one based on the currently effective allocation conditions, target routes and weights. If the match passes, the client is recorded and a traffic scheduling permission identifier is allocated to it.
[0085] On the basis of the above technical solution, when the traffic allocation module responds to the traffic scheduling request, it verifies the traffic scheduling permission identifier, and performs specific traffic scheduling operations for the client with the traffic scheduling permission identifier.
[0086] Based on the above technical solution, the traffic scheduling permission identifier contains specific information about how to route requests to a specific service instance, which code version to use, or which processing logic to apply, and the traffic allocation module executes corresponding traffic scheduling decisions based on the information.
[0087] On the basis of the above technical solution, the traffic distribution module also comprehensively evaluates the system load, the health status of the service instance, and the geographical location factors to ensure the effectiveness of the scheduling and the stability of the system.
[0088] The following is a specific embodiment.
[0090] Suppose there is an online shopping platform that is developing a new feature to provide users with more personalized product recommendations. In order to ensure the stability and user experience of the new feature, it is decided to use a dynamic traffic allocation system based on a rule engine to gradually deploy and test this new feature.
[0091] System architecture and module implementation
[0092] 1. Client integration module:
[0093] When a user visits an online shopping platform, the client integration module will automatically detect the user's attributes (such as membership level, historical purchase records, etc.).
[0094] When it is detected that the user attributes meet the preset conditions (for example, the user is a premium member and has more than 5 purchase records in the past three months), the client integration module will initiate a traffic allocation request.
[0095] At the same time, the module will also collect the usage of new functions (such as click-through rate, conversion rate, etc.) and generate monitoring logs for subsequent analysis.
[0096] 2. Rule engine module:
[0097] The rule engine module predefines multiple traffic distribution rules, including:
[0098] Assignment condition parameters: The "Member Level" in the user attributes must be "Advanced", and the number of "Historical Purchase Records" must be greater than 5.
[0099] Priority parameter: This rule has the highest priority, ensuring that premium members and active users can experience new features first.
[0100] Target routing parameters: If a match is successful, the request will be routed to the server instance where the new function is deployed.
[0101] Weight parameter: Initially, 50% of the traffic that meets the conditions is allocated to the new function server, and the remaining 50% is allocated to the old function server.
[0102] When receiving the traffic distribution request initiated by the client integration module, the rule engine module uses the parser to perform grammatical and semantic analysis on the traffic distribution rules and generate traffic matching logic.
[0103] Subsequently, the rule engine module will match the request according to the generated traffic matching logic. If the match is successful, a traffic scheduling permission identifier will be generated, which contains specific information on how to route the request to the new function server instance.
[0104] 3. Traffic distribution module:
[0105] When receiving a traffic scheduling request initiated by a client, the traffic allocation module will first verify the validity of the traffic scheduling permission identifier.
[0106] For requests that contain a valid traffic scheduling permission identifier, the traffic distribution module routes the request to the server instance where the new function is deployed based on the information in the permission identifier.
[0107] At the same time, the traffic distribution module will comprehensively evaluate factors such as the system load and the health status of the service instances to ensure the effectiveness of scheduling and the stability of the system.
[0108] 4. Rule configuration module:
[0109] Platform operators can set and modify traffic distribution rules through a friendly configuration interface or API.
[0110] For example, as the stability of a new feature and user experience improve, operators can gradually increase the proportion of traffic allocated to the new feature (from 50% to 100%).
[0111] At the same time, operators can also analyze the usage of new functions through monitoring logs so as to adjust traffic distribution strategies in a timely manner.
[0112] Trigger mechanism and flow definition
[0113] In this embodiment, a triggering method based on user attributes is mainly adopted. When a user who is a senior member and has a historical purchase record of more than 5 times visits the platform, the client integration module will be triggered to initiate a traffic allocation request.
[0114] Define "traffic" as the ratio of the number of requests handled by the new code to the number of requests handled by the old code per second. By monitoring changes in this ratio, you can assess the popularity of new features and their impact on system performance.
[0115] Through the above specific embodiments, we can clearly see the application and effect of the dynamic traffic allocation system based on the rule engine in actual business scenarios. The system not only helps to gradually deploy and test new functions, but also ensures the stability of the system and user experience.
[0116] The contents not described in detail in this specification belong to the prior art known to professional and technical personnel in this field.
[0117] The above description is only a preferred embodiment of the present invention, and the protection scope of the present invention is not limited to the above embodiment. Any equivalent modifications or changes made by those skilled in the art based on the contents disclosed by the present invention should be included in the protection scope recorded in the claims.
Claims
1. A dynamic traffic distribution system based on rule engine, characterized in that: include: The client integration module is used to initiate a traffic allocation request, to initiate a traffic scheduling request, to collect traffic execution results and generate monitoring logs; A rule engine module is used to respond to traffic allocation requests, to parse traffic allocation rules to obtain traffic matching logic, to perform matching processing according to the traffic allocation rules, and to generate a traffic scheduling permission identifier if the match is successful; A flow distribution module, used to respond to flow scheduling requests and to perform specific flow scheduling according to flow scheduling permission identifiers; The rule configuration module is used to set and modify traffic distribution rules.
2. A dynamic traffic distribution system based on a rule engine as claimed in claim 1, characterized in that: Based on any of the following triggering methods, the client integration module initiates a traffic allocation request: Obtain user attributes, and when the characteristic values in the user attributes meet the preset conditions, trigger the client integration module to initiate a traffic allocation request; Obtain information about the server interacting with the client. When the server middleware is activated, the client interacting with the server meets the triggering condition, triggering the client integration module to initiate a traffic allocation request. Obtain the role allocation information of the load balancer. When the role allocation ratio is not full, the client interacting with the load balancer meets the trigger condition, triggering the client integration module to initiate a traffic allocation request. Get the trigger status of the external trigger. When a specific event occurs, the external trigger broadcasts to the preset client group, triggering the client integration module to initiate a traffic allocation request.
3. A dynamic traffic distribution system based on a rule engine as claimed in claim 1, characterized in that: The flow rate refers to any of the following: Data processing volume, i.e. the ratio of the volume of data processed by the program modules consisting of the new code to the volume of data processed by the program modules consisting of the old code; User participation, which refers to the ratio of the number of users whose data is processed by the new code to the number of users whose data is processed by the old code; User request volume refers to the ratio of the number of requests processed by the new code per second to the number of requests processed by the old code per second.
4. A rule engine-based dynamic traffic distribution system as claimed in claim 1, characterized in that: The traffic distribution rule is used to define the traffic matching logic, which includes: Assign condition parameters to define the specific conditions that trigger the match; The priority parameter is used to determine the order of effective traffic allocation rules when multiple traffic allocation rules meet the allocation condition parameters; Target routing parameters are used to set the target to which the request should be directed when the allocation condition parameters are met; Weight parameter, used to dynamically adjust the traffic size according to the scenario identifier in the request parameter; After parsing the traffic distribution rules, the traffic matching logic is obtained to determine the currently effective distribution conditions, target routes and weights.
5. A dynamic traffic distribution system based on a rule engine as claimed in claim 1, characterized in that: The rule engine module first uses a parser to parse the traffic distribution rules. The parser will perform syntax analysis and semantic analysis on the traffic distribution rules in sequence. When the rule engine module is started or receives a rule update notification, it triggers the parsing process, and the parsed rules are stored in the memory for fast access and matching.
6. A rule engine-based dynamic traffic distribution system as claimed in claim 5, characterized in that: The traffic matching logic is represented as a rule list or rule tree, where each node represents a rule and the connections between nodes represent the priority order; By traversing the rule list or rule tree, the conditional expression of each rule is evaluated, and whether the match is successful is determined based on the evaluation result.
7. A rule engine-based dynamic traffic distribution system as claimed in claim 5, characterized in that: When receiving a traffic allocation request from a client, the rule engine module extracts the information in the request; Use the generated traffic matching logic to match the request; If the match is successful, a traffic scheduling permission identifier is generated and returned to the client; If the match fails, the request is processed according to the default policy.
8. A rule engine-based dynamic traffic distribution system as claimed in claim 1, characterized in that: The rule engine module matches the clients one by one based on the currently effective allocation conditions, target routes and weights. If a match is successful, the client is recorded and a traffic scheduling permission identifier is assigned to it.
9. A rule engine-based dynamic traffic distribution system as claimed in claim 1, characterized in that: When the traffic allocation module responds to the traffic scheduling request, it verifies the traffic scheduling permission identifier, and performs specific traffic scheduling operations on the client with the traffic scheduling permission identifier.
10. A rule engine-based dynamic traffic distribution system as claimed in claim 1, characterized in that: The traffic scheduling permission identifier contains specific information about how to route requests to a specific service instance, which code version to use, or which processing logic to apply. The traffic allocation module executes corresponding traffic scheduling decisions based on the information.