An adaptive multi-dimensional flow control method, system, device and medium

Abstract

The application provides a self-adaptive multi-dimensional traffic control method, system, device and medium, the method comprises the following steps: creating a flow control configuration strategy based on service requirements; receiving and analyzing client requests to obtain corresponding key-value pair information; matching the key-value pair information with the flow control configuration strategy to obtain a matching result; dynamically adjusting the flow control configuration strategy based on the matching result to obtain an execution strategy, thereby executing a traffic control operation based on the execution strategy. The self-adaptive multi-dimensional traffic control method, system, device and medium of the application solve the technical problems of low efficiency in extracting massive request information in a high-concurrency network environment, the limitations and static nature of traffic control, and the insufficient system scalability, significantly improve the request information processing efficiency, achieve fine traffic control, and have certain scalability and flexibility.

Description

Technical Field

[0001] This invention belongs to the technical field of flow control, and in particular relates to an adaptive multi-dimensional flow control method, system, device and medium. Background Technology

[0002] In modern network applications and services, a large number of requests are processed on the server side. With the expansion of network scale and the dramatic increase in the number of requests, servers face enormous pressure. Currently, servers often lack a unified and efficient method for extracting request information; in terms of traffic management, traditional fixed-parameter control methods are insufficient to cope with complex and ever-changing network environments. This leads to inefficiency when servers handle massive amounts of requests and makes it difficult to guarantee a good user experience.

[0003] Therefore, how to provide a traffic management method to solve the above problems has become a technical challenge that urgently needs to be overcome by those skilled in the art. Summary of the Invention

[0004] The purpose of this invention is to provide an adaptive multi-dimensional traffic control method, system, medium, and device to solve the problem that in high-concurrency network environments, it is impossible to dynamically adjust the control strategy according to real-time network traffic conditions and business needs.

[0005] In a first aspect, the present invention provides an adaptive multi-dimensional traffic control method, the method comprising the following steps: creating a traffic control configuration strategy based on business requirements, wherein the traffic control configuration strategy includes setting traffic control rules, configuring traffic control parameters, and maintaining token bucket status information; receiving and parsing the client request to obtain corresponding key-value pair information; matching the extracted key-value pair information with the traffic control configuration strategy to obtain a matching result; dynamically adjusting the traffic control configuration strategy based on the matching result to obtain an execution strategy, thereby performing traffic control operations based on the execution strategy.

[0006] In this implementation, the key-value pairs obtained from the client request are matched with the preset flow control configuration policy, and the flow control decision and operation are continuously adjusted in combination with the token bucket status information to determine the flow control policy for the corresponding client request. This can achieve the technical effect of dynamically adjusting the control policy according to the real-time network traffic conditions and business needs.

[0007] In one implementation of the first aspect, receiving and parsing the client request to obtain the corresponding key-value pair information includes the following steps: identifying the request characteristics of the client request, wherein the request characteristics include customer attribute characteristics and behavioral characteristics; extracting the target field of the client request based on the request characteristics and converting it into the corresponding key-value pair information.

[0008] This implementation method, by identifying customer attribute and behavioral characteristics, provides a comprehensive understanding of the features of client requests from multiple perspectives. The process of converting target fields into key-value pairs allows for flexible definition of data structure and content based on different business needs. It enables the selection of which dimensions of data to focus on based on specific analytical objectives or application scenarios, thereby providing more customized services.

[0009] In one implementation of the first aspect, creating a flow control configuration strategy based on business requirements includes the following steps: setting flow control rules based on the business requirements of the flow control strategy, and configuring corresponding flow control parameters for the flow control rules; initializing the status information of the token bucket based on the flow control parameters, and obtaining a preset flow control strategy to guide the flow management process; wherein, the flow control parameters include core control parameters, condition matching parameters, custom behavior parameters, and priority parameters.

[0010] In this implementation, specific flow control rules and refined parameter configurations can be used to formulate the most suitable flow control strategies for different application scenarios, and adjustments can be made according to actual needs, thereby optimizing system performance and resource utilization.

[0011] In one implementation of the first aspect, the traffic control rules include: static configuration rules and dynamic configuration rules; the static configuration rules are set by annotation parameters within the code and are used for static resource configuration, fixed business logic, and system configuration with low change frequency; the dynamic configuration rules are set by an external configuration center and are used for dynamic resource configuration, business logic with high change frequency, and system configuration adjusted in real time; wherein, the dynamic configuration rules are set using the Nacos configuration center.

[0012] This implementation combines static and dynamic configuration rules to flexibly manage different types of resources and business logic. Using the Nacos configuration center enables real-time updates of configuration information without system downtime, significantly improving system flexibility and responsiveness.

[0013] In one implementation of the first aspect, matching the extracted key-value pair information with the traffic control policy to obtain a matching result includes the following steps: identifying the traffic control rule corresponding to the key-value pair information in the traffic control policy; performing field matching between the key-value pair information and the traffic control parameters configured in the traffic control rule to obtain a preliminary matching result; and performing condition matching between the preliminary matching result and the traffic control parameters configured in the traffic control rule to obtain a final matching result.

[0014] In this implementation, by accurately matching and dynamically adjusting key-value pair information and flow control configuration policies, corresponding control measures are taken for specific traffic types or user behaviors, thus achieving effective control and management of network traffic.

[0015] In one implementation of the first aspect, the matching result is combined with the token bucket state information to identify the flow control configuration policy adjustment requirement; based on the flow control configuration policy adjustment requirement, the token bucket state information is adjusted to obtain the execution policy; and the flow control operation is executed based on the execution policy; wherein, the token bucket state information includes the current number of tokens, the token generation rate, the token consumption rate, and the token bucket capacity.

[0016] This implementation dynamically adjusts the flow control configuration strategy to flexibly respond to real-time traffic fluctuations. Combined with token bucket state information, network resources can be managed and allocated more precisely, ensuring efficient resource utilization. The dynamic adjustment mechanism enables the system to better handle sudden traffic spikes and anomalies, improving system robustness and stability.

[0017] In one implementation of the first aspect, the method further includes an exception handling mechanism: classifying detected abnormal client requests to obtain an exception request classification, wherein the exception request classification includes temporary exceptions, recoverable exceptions, and systemic exceptions; setting corresponding exception handling strategies for different categories of abnormal requests, wherein the exception handling strategies include ignoring exceptions, retrying requests, and issuing alarms; and performing corresponding flow control operations according to the exception request classification and the exception handling strategies.

[0018] This implementation improves the stability and reliability of traffic management by introducing an exception handling mechanism. By classifying and specifically handling abnormal requests, the risk of crashes is reduced, and user experience and service quality are enhanced.

[0019] Secondly, the present invention provides an adaptive multi-dimensional traffic control system, comprising: an information extraction module for receiving and parsing the client request to obtain corresponding key-value pair information; a traffic control strategy configuration module for creating a traffic control configuration strategy based on business requirements, wherein the traffic control configuration strategy includes defining traffic control rules, configuring traffic control parameters, and maintaining token bucket status information; a traffic control decision module for matching the extracted key-value pair information with the traffic control strategy to obtain a matching result; dynamically adjusting the traffic control configuration strategy based on the matching result to determine the traffic control decision for the client request and executing traffic control operations; and a token bucket management module for configuring parameters of the token bucket based on the traffic control strategy configuration module and dynamically adjusting the traffic control strategy configuration module based on the traffic control decision module to implement traffic control operations.

[0020] Thirdly, the present invention provides an electronic device, the electronic device comprising: a processor and a memory;

[0021] The memory is used to store computer programs;

[0022] The processor is used to execute the computer program stored in the memory to cause the electronic device to perform the above-described adaptive multi-dimensional flow control method.

[0023] Fourthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by an electronic device, implements the above-described adaptive multi-dimensional flow control method.

[0024] As described above, the adaptive multi-dimensional flow control method, system, device, and medium of the present invention have the following characteristics:

[0025] Beneficial effects:

[0026] This invention significantly improves the efficiency of request information processing: through a unified information extraction module, key-value pair information can be accurately and efficiently extracted simultaneously from the header, request parameters, and POST request body, avoiding the complexity and inefficiency caused by processing different parts of the request separately. This integrated processing method reduces the time and resource consumption for information extraction, and improves the server's request processing speed.

[0027] This invention achieves fine-grained flow control: by combining request key-value pair information with a token bucket algorithm-based flow control strategy, it can perform more refined flow control based on the content and source of the request. For example, different flow quotas can be allocated to different types of users (based on identifiers in request headers or parameters) and different types of requests (based on specific parameters in the request body), thereby better utilizing server resources and improving the overall performance and stability of the system.

[0028] This invention offers excellent scalability and flexibility: new request information extraction rules can be added or flow control strategies adjusted based on requirements to adapt to constantly changing network environments and business needs. For example, attention can be increased to specific request headers or request body fields based on new business logic, or token bucket parameters can be modified to adapt to different traffic patterns. Through dynamic flow control strategies, the system can self-adjust based on real-time request characteristics and system status, enabling it to respond more flexibly and effectively to different traffic patterns. Attached Figure Description

[0029] Figure 1 The diagram shows an application scenario of the adaptive multi-dimensional flow control method of the present invention in one embodiment;

[0030] Figure 2 The diagram shows the steps of an embodiment of the adaptive multi-dimensional flow control method of the present invention;

[0031] Figure 3a This diagram illustrates the flow control strategy configuration module in one embodiment of the adaptive multi-dimensional flow control method of the present invention.

[0032] Figure 3b The diagram shows a flow control mode in one embodiment of the adaptive multi-dimensional flow control method of the present invention.

[0033] Figure 3c The diagram shows a parameter configuration of the adaptive multi-dimensional flow control method of the present invention in one embodiment.

[0034] Figure 4 This diagram illustrates the information extraction module in one embodiment of the adaptive multi-dimensional flow control method of the present invention.

[0035] Figure 5a The diagram shows a flow control decision module in one embodiment of the adaptive multi-dimensional flow control method of the present invention.

[0036] Figure 5b The diagram shows the matching process steps in one embodiment of the adaptive multi-dimensional flow control method of the present invention.

[0037] Figure 6 The diagram shown is an architecture diagram of the adaptive multi-dimensional flow control method of the present invention in one embodiment;

[0038] Figure 7 The flowchart shown is an embodiment of the adaptive multi-dimensional flow control system of the present invention;

[0039] Figure 8 The diagram shown is a schematic representation of the system structure of the adaptive multi-dimensional flow control method of the present invention in one embodiment.

[0040] Figure 9 The diagram shown is a structural schematic of an embodiment of the electronic device of the present invention. Detailed Implementation

[0041] The following specific examples illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be noted that, unless otherwise specified, the following embodiments and features described therein can be combined with each other.

[0042] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Therefore, the drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0043] like Figure 1 As shown, this invention uses a client-server model in its HTTP implementation. Multiple clients send requests to the server, each request containing the URL of the resource to be accessed, request headers (e.g., Accept, User-Agent), and an optional request body (for POST or PUT requests). Upon receiving the request, the server locates the corresponding resource based on the information in the request and performs the appropriate processing operation.

[0044] The technical solutions of the present invention will now be described in detail with reference to the accompanying drawings.

[0045] like Figure 2 As shown, in one embodiment, the adaptive multi-dimensional flow control method of the present invention includes steps S11 to S14.

[0046] Step S11: Create a flow control configuration strategy based on business requirements, wherein the flow control configuration strategy includes defining flow control rules, configuring flow control parameters, and maintaining token bucket status information;

[0047] Specifically, creating a flow control configuration strategy based on business needs includes the following steps:

[0048] Based on the business requirements of the traffic control strategy, traffic control rules are set, and corresponding traffic control parameters are configured for the traffic control rules.

[0049] The token bucket status information is initialized based on the flow control parameters to obtain a preset flow control strategy to guide the flow management process.

[0050] The traffic control parameters include core control parameters, condition matching parameters, custom behavior parameters, and priority parameters. Core control parameters directly affect the core logic and behavior of traffic control and include: rate, mode, bucketCapacity, and requestedTokens. Condition matching parameters define which requests should be affected by traffic control rules and include: uri, filterConditions (including fieldName and fieldValue), and source. Custom behavior parameters define the specific actions the system should take when traffic control is triggered and include: fallbackFunction and customKeyFunction. Priority parameters specify the execution order or priority between different traffic control rules and include: rateExpression, rateInterval, and bucketCapacityExpression.

[0051] Furthermore, the traffic control rules include: static configuration rules and dynamic configuration rules;

[0052] The static configuration rules are set through annotation parameters inside the code and are used for static resource configuration, fixed business logic, and system configuration with low change frequency.

[0053] The dynamic configuration rules are set through an external configuration center and are used for dynamic resource configuration, business logic with high change frequency, and real-time adjustment of system configuration.

[0054] The dynamic configuration rules are set using the Nacos configuration center.

[0055] (1) As Figures 3a to 3c As shown, static configuration is typically suitable for scenarios where flow control rules do not change frequently, such as static resource configuration, fixed business logic, and system configuration with low change frequency.

[0056] 1) Static resource configuration

[0057] In many application scenarios, the configuration of flow control rules is relatively fixed and does not need to be changed frequently. For example, the internal management systems of some enterprises and the portal websites of government agencies have relatively stable access traffic and a fixed user group. Therefore, the flow control rules can be set with fixed parameters, such as a time window of 10 tokens per minute and a fixed token bucket capacity.

[0058] 2) Fixed business logic

[0059] For systems with relatively fixed and unchanging business processes, flow control rules do not need to be frequently adjusted. For example, payment gateways in financial systems and order processing modules on e-commerce websites have relatively fixed request patterns and parameters, and flow control strategies can be set based on these fixed patterns without frequent updates.

[0060] 3) System configuration with low change frequency

[0061] In systems that require flow control management but do not have high real-time requirements, flow control rules can remain unchanged for a long time. For example, internal enterprise report generation systems and data analysis platforms typically do not frequently adjust flow control strategies due to business changes, so static configuration can be used.

[0062] When flow control rules do not change frequently, static configuration is suitable. This approach is simple, straightforward, and easy to implement and manage. For systems with stable traffic, fixed business logic, or low frequency of changes, static configuration provides sufficient flexibility and stability.

[0063] Furthermore, static configuration is achieved by using the `@RateLimit` annotation in the code and setting the corresponding parameters. This configuration method is simple, declared directly in the code, and easy to understand and maintain. Specific static flow control parameters are as follows:

[0064] `mode`: This parameter defines the algorithm used to implement the flow control strategy. There are two flow control modes: `TIME_WINDOW` (time window based mode) and `TOKEN_BUCKET` (token bucket algorithm based mode). The time window based mode allows a certain number of requests to be processed within a specific time window. The token bucket algorithm generates tokens at a fixed rate, and requests require tokens to be processed. The default setting is `TOKEN_BUCKET`.

[0065] `rate`: This parameter has different meanings depending on the mode. In `TIME_WINDOW` mode, it represents the maximum number of requests allowed within each time window. In `TOKEN_BUCKET` mode, it represents the number of tokens generated per second, i.e., the maximum number of requests allowed per second. The default value is 1.

[0066] bucketCapacity: In TOKEN_BUCKET mode, this parameter defines the capacity of the token bucket, and its size determines the maximum concurrency of the interface under rate limiting rules.

[0067] requestedTokens: This parameter defines the number of tokens required for each request. It is usually 1, but can be adjusted in special cases.

[0068] keys: This parameter specifies the key value of the object to which the flow control policy applies. There can be multiple keys to distinguish different request sources or types.

[0069] fallbackFunction: This callback function is executed when a request is rejected by the flow control policy. It can be used to log messages, return specific error messages, etc.

[0070] customKeyFunction: This parameter is used to customize how flow control key values ​​are generated, allowing more complex business logic to determine the granularity of flow control.

[0071] rateExpression: This is an expression used to define how the traffic count is calculated within a time window, and it supports complex logic.

[0072] rateInterval: For TIME_WINDOW mode, this parameter defines the size of the time window, for example, 1 second. For TOKEN_BUCKET mode, this parameter can be left blank.

[0073] (2) Figures 3a to 3c As shown, dynamic configuration is typically suitable for scenarios where flow control rules change frequently, such as dynamic resource configuration, business logic with high change frequency, and system configuration that needs to be adjusted in real time.

[0074] 1) Dynamic resource allocation

[0075] In many application scenarios, flow control rules need to be adjusted based on real-time traffic conditions. For example, social media platforms, online game servers, and e-commerce websites may experience changes in access volume and request patterns at any time, thus requiring frequent updates to flow control rules to adapt to different traffic demands.

[0076] 2) Business logic with high change frequency

[0077] For systems with significantly changing and frequently updated business processes, flow control rules also need to be adjusted accordingly. For example, cloud service providers and content delivery networks (CDNs) often experience changes in business requirements and user behavior patterns, thus requiring frequent updates to flow control strategies to ensure service quality.

[0078] 3) System configurations that require real-time adjustments

[0079] In systems with high real-time requirements, flow control rules need to be adjusted in real time to cope with sudden changes in traffic. For example, in financial trading systems and real-time data processing systems, request processing must respond quickly, so flow control strategies need to be able to be updated immediately in order to control the number of concurrent requests in a timely manner.

[0080] When flow control rules change frequently, dynamic configuration is suitable. This approach can flexibly respond to changes in traffic and business, ensuring efficient system operation and stability. For systems with large traffic fluctuations, complex business logic, or high real-time requirements, dynamic configuration can provide sufficient flexibility and adaptability.

[0081] Furthermore, dynamic configuration is achieved through JsonArray strings in Nacos, supporting the configuration of multiple different sets of flow control rules from a single interface. Specific dynamic configuration parameters are as follows:

[0082] uri: This parameter specifies the request URI of the interface. It is a required field and is used to identify which interfaces need to apply flow control policies.

[0083] desc: This parameter is optional and is used to describe the functionality of the interface for easy configuration and management.

[0084] filterConditions: An array containing specific flow control rules (supporting multiple rules), including field names and field values, used to define when the flow control strategy is applied.

[0085] source: An enumeration type that defines the source of field values ​​in filterConditions. It can be a request header (HEADER), request parameters (REQUEST_PARAM), or request body (REQUEST_BODY).

[0086] rate: Same as rate in static configuration, but has different meanings depending on the mode.

[0087] mode: Same as mode in static configuration, defines the flow control mode.

[0088] bucketCapacity: Same as bucketCapacity in the static configuration, defines the size of the token bucket.

[0089] requestedTokens: Same as requestedTokens in the static configuration, it defines the number of tokens required for each request.

[0090] Both configurations are introduced by adding the `@RateLimit` annotation to the interface. When both static and dynamic configurations exist, the system will prioritize the dynamic configuration. This means that if the relevant configuration exists in Nacos, the static configuration will not take effect. Through these two configuration methods, this invention provides a comprehensive traffic control solution for different business needs, ensuring the stable operation of the system under high concurrency.

[0091] In one embodiment, a requirements analysis is performed based on the acquired client requests to determine which interfaces require traffic control. The traffic patterns of these interfaces are analyzed to decide whether to use static or dynamic configuration. For static configuration, the `@RateLimit` annotation is defined in the code, and the corresponding parameters are set. For dynamic configuration, a Nacos configuration center is prepared, and configurations in JsonArray string format are defined. The application is deployed, ensuring it can connect to the Nacos configuration center (if dynamic configuration is used). After the application starts, traffic control is implemented according to the configuration. Dynamic configuration can be updated in real time without restarting the application. The effectiveness of traffic control is monitored, and configuration parameters are adjusted as needed.

[0092] Furthermore, managing the token bucket status information based on the traffic control policy includes the following steps: initializing the token bucket status information; configuring the corresponding initial token capacity and generation rate based on the traffic control policy; obtaining the number of tokens based on the client request and updating the token bucket status information in real time.

[0093] During the initialization phase of the token bucket management module, the initial capacity and generation rate are first set: the system sets an initial capacity (C) and token generation rate (R) for each token bucket according to the flow control configuration policy. These parameters define the maximum capacity of the token bucket and the speed at which tokens are generated. Next, the number of tokens is initialized. During initialization, the number of tokens in the token bucket is set to the initial capacity value to ensure that there are enough tokens available when the system starts. Finally, the token bucket initialization time is recorded for subsequent token generation calculations. Since the system may need to dynamically adjust the token bucket parameters, this invention uses Nacos as a dynamic configuration platform, which can update the token bucket capacity and generation rate in real time without restarting the service.

[0094] Furthermore, the token generation process is as follows:

[0095] First, the system calculates the number of newly generated tokens: The system calculates the number of newly generated tokens at preset time intervals (e.g., per second). The calculation formula is:

[0096] New token quantity = (Current time - Last update time) × Token generation rate

[0097] Secondly, update the token bucket: add the newly acquired tokens to the token bucket, but the total amount will not exceed the token bucket's capacity limit. This ensures that the token bucket will not exceed its maximum capacity due to the generation rate setting.

[0098] Finally, when a request arrives, token consumption is processed.

[0099] Furthermore, the steps for handling token consumption are as follows:

[0100] First, determine the number of tokens to be consumed: Based on the flow control policy and the characteristics of the request, determine the number of tokens (T) required to process the request.

[0101] Secondly, process client requests: if the number of tokens in the token bucket is greater than or equal to T, deduct T tokens from the token bucket and allow the request to proceed. If the number of tokens is insufficient, reject the request.

[0102] Finally, the relationship between tokens and the number of downstream interfaces is clarified: In this invention, the number of tokens is directly proportional to the number of downstream services called by the interface. This means that if a request involves multiple downstream interfaces, it may consume more tokens. In actual projects, each request typically consumes 1 token, but this ratio can be adjusted according to actual business needs.

[0103] In this way, the token bucket management module can effectively control the request traffic entering the system, ensuring system stability and service quality.

[0104] Step S12: Receive and parse the client request to obtain the corresponding key-value pair information.

[0105] Specifically, receiving and parsing client requests to obtain the corresponding key-value pair information includes the following steps:

[0106] Identify the request characteristics of the client request, including client attribute characteristics and behavioral characteristics;

[0107] Based on the request characteristics, the target fields of the client request are extracted and converted into corresponding key-value pairs.

[0108] Information extraction is a crucial part of traffic management. Its main function is to extract key information from client requests to support subsequent traffic control decisions. Client attribute characteristics include basic client information such as IP address, user agent, strings, and authentication information. This information helps the system understand the source and identity of the request. Behavioral characteristics involve the specific behavior of the client request, such as the requested URL, HTTP method (GET, POST, etc.), request headers, and request body. Behavioral characteristics help understand the client's intent and needs.

[0109] After identifying request characteristics, the system needs to extract target fields related to traffic control. For example, this might involve extracting path parameters or query parameters from the URL, obtaining specific markers (such as API keys) from the request header, or parsing specific fields from JSON / XML data in the request body. The extracted information is then converted into key-value pairs, where the key is a unique identifier and the value is the corresponding data content. This format facilitates subsequent processing and matching operations.

[0110] like Figure 4 As shown, obtaining key-value pair information corresponding to a client request includes the following steps: extracting the header fields of the client request and converting them into header key-value pairs; extracting the parameter fields of the client request and converting them into parameter key-value pairs; and extracting the request body fields of the client request and converting them into request body key-value pairs.

[0111] (1) Request header information extraction

[0112] The request header contains a series of key-value pairs that convey client configuration information, request details, and a description of the client's capabilities. These header fields provide information about the client environment, browser type, and accepted content types, helping the server understand the client's request and respond accordingly.

[0113] The primary purpose of request headers is to allow clients to send additional information to the server to control or specify the method of the request, the expected response, and authentication requirements. For example, the User-Agent header tells the server the client's operating system and browser version, while the Accept header specifies the data types the client can accept.

[0114] For incoming requests, the standard format of the request header (such as the HTTP header format) is parsed, and each header field is used as a key, with its corresponding value stored in a temporary data structure. For example, if the flow control rule is set to control traffic to the user with tenant ID = 12345, then during rule parsing, the key `gksk_tanent_id` and its corresponding value need to be extracted from the header request, and then compared with the flow control rule to determine if a match occurs. Relevant information from the request header, such as tenant ID and user ID, is extracted; this information is used to identify and verify the requester's identity and permissions.

[0115] (2) Extraction of request parameter information

[0116] Request parameters typically appear in the query string portion of a URL and are used to pass simple key-value pairs of data. These parameters are separated by the '&' symbol, and each parameter consists of a key name and a key value, connected by '='. Request parameters are primarily used for operations such as filtering, sorting, and pagination. They are appended directly to the end of the URL and separated from the URL path portion by a question mark (?). For example, in example.com / api / product?sort=price&order=asc, 'sort' and 'order' are request parameters.

[0117] Parse the query parameters in the request URL, using the parameter name as the key and the parameter value as the value. If there are multiple parameters with the same name (e.g., "param1=value1" and "m1=value2"), store the values ​​as a list.

[0118] (3) Extracting POST request body information

[0119] The POST request body is an optional part of an HTTP request, used only when data needs to be sent and the request method supports it, such as POST or PUT. It is used to transmit data sent from the client to the server and can contain various types of data, such as form data, JSON data, and files.

[0120] The primary purpose of a POST request body is to transmit complex data structures to the server. This data can be user-input form data, uploaded files, or parameters required for API calls. The specific data type is specified by the Content-Type field in the request header, such as application / json indicating JSON formatted data.

[0121] If the request is a POST request and the request body is in a parsable format (such as JSON, form data, etc.), the request body content is parsed into key-value pairs. For JSON request bodies, the object properties are iterated through, with property names used as keys and property values ​​as values. This is then matched against flow control rules. Information extracted from the request body is typically transmitted via POST requests for further analysis and processing of the request content, ensuring that flow control strategies can be flexibly adjusted according to actual needs.

[0122] Step S13: Match the extracted key-value pair information with the flow control configuration strategy to obtain the matching result.

[0123] Specifically, the steps include: identifying the traffic control rule corresponding to the key-value pair information in the traffic configuration policy; performing field matching between the key-value pair information and the traffic control parameters configured in the traffic control rule to obtain a preliminary matching result; and performing condition matching between the preliminary matching result and the traffic control parameters configured in the traffic control rule to obtain a final matching result.

[0124] like Figures 5a to 5b As shown, upon receiving a client request, the system first extracts all key-value pairs from the request. Then, the system predefines a series of traffic control policy rules. These rules are set according to business needs and may include different processing strategies for different user roles (such as ordinary users and advanced users), request types (such as read operations and write operations), and request sources (such as internal calls and external calls).

[0125] The matching process includes field matching and condition matching. The system matches the extracted key-value pairs against the specified fields in the policy rules. For example, if a rule specifies that more lenient traffic control is applied to a particular value in the "Authorization" field (such as a token representing a premium user), the system checks the "Authorization" field value in the request. Once a field value match is successful, the system determines the traffic control level of the request based on the conditions defined in the rule. If the value of the "Authorization" field indicates that the request comes from a premium user, the system may allocate a higher traffic quota, allowing the request to be prioritized even during peak traffic periods. Based on the matching results, the system makes a flow control decision. If the request meets the premium user criteria, it is allowed to pass; otherwise, it may need to further check other rules or implement default traffic control measures, such as limiting the request rate or rejecting the request outright. In this way, key-value pair-based policy matching not only enables differentiated processing for different users and requests but also ensures the reasonable allocation of system resources, improving overall service performance and user experience. If the request meets the criteria for advanced users, it will be allowed to proceed; otherwise, further checks of other rules may be required or default traffic control measures may be implemented, such as limiting the request rate or rejecting the request outright.

[0126] In this way, key-value pair-based policy matching can not only achieve differentiated processing for different users and requests, but also ensure the reasonable allocation of system resources, thereby improving the overall performance of the service and the user experience.

[0127] Step S14: Dynamically adjust the flow control configuration strategy based on the matching result to obtain the execution strategy, and then perform flow control operations based on the execution strategy.

[0128] Specifically, the matching result is combined with the token bucket's state information to identify the flow control configuration policy adjustment requirement; based on the flow control configuration policy adjustment requirement, the token bucket's state information is adjusted to obtain the execution policy; and the flow control operation is executed based on the execution policy; wherein, the token bucket's state information includes the current number of tokens, the token generation rate, the token consumption rate, and the token bucket capacity.

[0129] In one embodiment, the matching results are analyzed in conjunction with the token bucket's state information to identify the following situations: Frequent token shortages in the token bucket indicate that the current policy may be too strict or traffic demand may exceed expectations. Frequent token surpluses in the token bucket may indicate that the policy is too lenient and resources are not being fully utilized. Based on the token bucket state analysis, the following adjustment needs are identified: If tokens are insufficient, the token generation rate or token bucket capacity may need to be increased. If tokens are surplus, the token generation rate or token bucket capacity may need to be decreased. Based on the identified adjustment needs, the flow control configuration policy is adjusted to obtain an execution policy to perform the following operations: Adjust the token generation rate: If tokens are insufficient, increase the token generation rate; if tokens are surplus, decrease the token generation rate. Adjust the token bucket capacity: Adjust the token bucket capacity according to traffic demand to ensure it can accommodate traffic peaks. Modify the flow control rules: Based on the token bucket state, modify the conditions in the flow control rules, such as adjusting the flow control level for matching specific key-value pairs. The adjusted flow control configuration policy, i.e., the execution policy, is applied to the flow control system in real time to ensure that the new token bucket configuration and rules take effect immediately.

[0130] In one embodiment, if the key-value pair information matches the flow control policy successfully, it is determined whether the current quantity of the token bucket meets the required token quantity; if it does, the request is allowed to pass; if it does not, the request is rejected; if the key-value pair information does not match the flow control configuration policy successfully, it is determined whether a default processing method exists; if the default processing method exists, the corresponding flow control decision is obtained based on the default processing method; if the default processing method does not exist, the key-value pair information and the flow control policy are continuously matched in a loop until the corresponding flow control decision is obtained.

[0131] Furthermore, based on the flow control configuration policy, the number of tokens required for each request is determined. For example, if the rule is that 1 token is consumed for every 5 requests, then the 6th request will require 1 token. The current token bucket status is queried in the token bucket management module. If the number of tokens in the token bucket is greater than or equal to the number of tokens required by the request, the request is allowed to pass, and the corresponding number of tokens is deducted from the token bucket. For example, if there are 5 tokens in the current token bucket, and the request requires 1 token, then 1 token is deducted from the token bucket, leaving 4 tokens. If there are insufficient tokens in the token bucket, the request is rejected, and an appropriate prompt message can be returned to the client. For example, if there are 0 tokens in the current token bucket, and the request requires 1 token, then the request is directly rejected, and a "flow control failed" message is returned to the client. The token bucket status needs to be updated after each request is processed.

[0132] In one embodiment, such as Figure 5aAs shown, the system receives a request from the client. The system identifies the request type and extracts key information based on the request's URI or other characteristics. Based on scenario analysis, the system loads the corresponding flow control policy configuration from a configuration center (such as Nacos), initializes the token bucket based on the configuration parameters, and matches the request's characteristics (such as request parameters, request headers, request body, etc.) with the filterConditions in the configuration to determine whether a flow control policy needs to be applied to the request. If the request matches a flow control rule, the system will make a flow control decision based on the configured mode (such as TIME_WINDOW or TOKEN_BUCKET) and rate parameters. In TOKEN_BUCKET mode, the system checks if there are enough tokens in the token bucket to process the request. If there are, the request is allowed to pass; otherwise, the request will be restricted or downgraded. In TOKEN_BUCKET mode, the system adds tokens to the token bucket at a fixed rate. If the request passes the flow control decision, the system will execute the flow control operation. If the request is rejected by the flow control policy, the system will execute a fallback function, which may include logging, returning error messages, etc. After processing the request, the system sends a response back to the client. Through the above workflow, this invention can flexibly adjust traffic management measures according to real-time request characteristics and system status, thereby ensuring system stability and efficiency.

[0133] like Figure 7 As shown, the process receives HTTP requests from clients, including request headers, parameters, and body. It logs into the Nacos console, loads the flow control configuration rules, ensures the rules are correct, and saves them. It iterates through all loaded flow control rules, checking if the current request matches any of them. If a match is found, it extracts the corresponding key-value pairs. It extracts necessary information according to the rule requirements, such as tenant ID and user ID. If a rule is matched, it executes a Reddisson Lua script to obtain a token. It checks if the number of tokens in the token bucket is sufficient. If not, it proceeds to the next step; if sufficient, it allows the request and deducts the corresponding number of tokens from the token bucket. When the number of tokens is insufficient, it checks if there is a custom processing method. If so, it calls the custom processing logic, such as returning a specific error message or performing additional operations; otherwise, it executes the default processing logic and throws the default error message: "Request too fast, please try again later."

[0134] Through the above process, the present invention can effectively achieve fine-grained traffic control based on request information, ensuring that the system can operate efficiently in various application scenarios.

[0135] Furthermore, the method is used to implement an efficient and reliable exception handling mechanism: during traffic management, client requests and system responses are monitored in real time to identify abnormal behaviors, including but not limited to abnormal request frequency, abnormal request size, abnormal response time, and system error response.

[0136] The detected abnormal behaviors are classified into temporary, recoverable, and systemic anomalies to provide a basis for subsequent anomaly handling; specific handling strategies are defined for different types of anomalies, including ignoring anomalies, retrying requests, limiting request frequency, degrading services, and notifying administrators.

[0137] Based on the anomaly classification and handling strategy, the system automatically executes the corresponding anomaly handling operations to ensure system stability and service continuity. After the anomaly handling is completed, the system takes corresponding recovery measures according to the nature and impact of the anomaly, such as restoring normal traffic control policies, clearing the abnormal state, and restarting the affected services.

[0138] In one embodiment, the adaptive multi-dimensional traffic control method of the present invention is applied to a large model platform to solve the problem of concurrent requirements of different business parties for the large model interface.

[0139] Customer A (customerId=12345) requires 10 concurrent connections for the OCR interface ( / ocr) and 20 concurrent connections for the text2Pic interface. The corresponding Nacos configuration can be set as follows:

[0140]

[0141]

[0142]

[0143] For Business A's OCR interface ( / ocr), a token bucket with a capacity of 10 is configured, meaning that a maximum of 10 requests from Business A can be processed simultaneously. Tokens are generated at a rate of 1 per second, and each request consumes 1 token. For Business A's text-to-image interface ( / text2Pic), a token bucket with a capacity of 20 is configured, allowing a maximum of 20 requests from Business A to be processed simultaneously. Other configurations are the same as for the OCR interface.

[0144] This configuration allows the large-scale platform to implement fine-grained traffic control for the different interface requirements of various business units, ensuring that each business unit's requests are processed within specified concurrency limits. This avoids excessive pressure on the large-scale platform and guarantees service stability and fairness. Furthermore, this adaptive traffic control method can be adjusted based on actual operational conditions to adapt to changes in business needs.

[0145] The scope of protection of the adaptive multi-dimensional flow control method described in this embodiment is not limited to the execution order of the steps listed in this embodiment. Any solution implemented by adding, subtracting, or replacing steps in the prior art based on the principles of this invention is included within the scope of protection of this invention.

[0146] This invention also provides an adaptive multi-dimensional flow control system, which can implement the adaptive multi-dimensional flow control method described in this invention. However, the implementation device of the adaptive multi-dimensional flow control system described in this invention includes, but is not limited to, the structure of the adaptive multi-dimensional flow control system listed in this embodiment. All structural modifications and substitutions of the prior art made in accordance with the principles of this invention are included within the protection scope of this invention.

[0147] In one embodiment, such as Figure 8 As shown, the adaptive multi-dimensional flow control system of the present invention includes:

[0148] Information extraction module 81 is used to receive and parse the client request and obtain the corresponding key-value pair information;

[0149] The flow control policy configuration module 82 is used to create flow control configuration policies based on business requirements. The flow control configuration policy includes setting flow control rules, configuring flow control parameters, and maintaining token bucket status information.

[0150] The flow control decision module 83 is used to match the extracted key-value pair information with the flow control strategy to obtain the matching result; dynamically adjust the flow control configuration strategy based on the matching result to obtain the execution strategy, and then perform flow control operation based on the execution strategy.

[0151] The token bucket management module 84 is used to configure the parameters of the token bucket based on the flow control policy configuration module, and to dynamically adjust the flow control policy configuration module based on the flow control decision module to achieve flow control operations.

[0152] In the embodiments provided by this invention, it should be understood that the disclosed systems, apparatuses, or methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of modules / units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or units may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection of apparatuses or modules or units may be electrical, mechanical, or other forms.

[0153] The modules / units described as separate components may or may not be physically separate. The components shown as modules / units may or may not be physical modules; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules / units can be selected to achieve the objectives of the embodiments of the present invention, depending on actual needs. For example, the functional modules / units in the various embodiments of the present invention may be integrated into one processing module, or each module / unit may exist physically separately, or two or more modules / units may be integrated into one module / unit.

[0154] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0155] This invention also provides a computer-readable storage medium. Those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing a processor. The program can be stored in a computer-readable storage medium, which is a non-transitory medium, such as random access memory, read-only memory, flash memory, hard disk, solid-state drive, magnetic tape, floppy disk, optical disk, and any combination thereof. The storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. This available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital video disc (DVD)), or a semiconductor medium (e.g., solid-state drive (SSD)).

[0156] Figure 9 This is a schematic block diagram of a computer device provided in an embodiment of the present invention. Figure 9As shown, the computer device includes at least one processor 901, a memory 902, at least one network interface 903, and a user interface 905. The various components in the device are coupled together via a bus system 904. It is understood that the bus system 904 is used to implement communication between these components. In addition to a data bus, the bus system 904 also includes a power bus, a control bus, and a status signal bus. However, for clarity, in… Figure 9 The general will label all buses as bus systems.

[0157] The user interface 905 may include a monitor, keyboard, mouse, trackball, clicker, button, touchpad, or touch screen.

[0158] It is understood that memory 902 can be volatile memory or non-volatile memory, or both. Non-volatile memory can be read-only memory (ROM) or programmable read-only memory (PROM), used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM) and synchronous static random access memory (SSRAM). The memories described in the embodiments of this invention are intended to include, but are not limited to, these and any other suitable categories of memory.

[0159] In this embodiment of the invention, the memory 902 is used to store various types of data to support the operation of the electronic terminal 900. Examples of this data include: any executable program for operation on the electronic terminal 900, such as the operating system 9021 and application programs 9022; the operating system 9021 contains various system programs, such as the framework layer, core library layer, driver layer, etc., for implementing various basic services and handling hardware-based tasks. The application program 9022 may contain various applications, such as a media player, browser, etc., for implementing various application services. The adaptive multi-dimensional traffic control method provided in this embodiment of the invention can be included in the application program 9022.

[0160] The methods disclosed in the above embodiments of the present invention can be applied to or implemented by processor 901. Processor 901 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware in processor 901 or by instructions in software form. The processor 901 may be a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. Processor 901 can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of the present invention. General-purpose processor 901 may be a microprocessor or any conventional processor, etc. The steps of the accessory optimization method provided in the embodiments of the present invention can be directly reflected as being executed by a hardware decoding processor, or being executed by a combination of hardware and software modules in the decoding processor. The software module may be located in a storage medium, which is located in memory. The processor reads the information in the memory and combines it with its hardware to complete the steps of the aforementioned method.

[0161] In an exemplary embodiment, the electronic terminal 900 may be used by one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), or complex programmable logic devices (CPLDs) to execute the aforementioned method.

[0162] The above embodiments are merely illustrative of the principles and effects of the present invention and are not intended to limit the invention. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of the present invention. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in the present invention should still be covered by the claims of the present invention.

Claims

1. An adaptive multi-dimensional flow control method, characterized in that, The method includes the following steps: A flow control configuration strategy is created based on business requirements. This strategy includes setting flow control rules, configuring flow control parameters, and maintaining token bucket status information. The flow control rules include static and dynamic configuration rules. Static configuration rules are set via annotation parameters within the code and are used for static resource configuration, fixed business logic, and system configuration with low change frequency. Dynamic configuration rules are set through an external configuration center and are used for dynamic resource configuration, business logic with high change frequency, and system configuration adjusted in real time. When both static and dynamic configurations exist, dynamic configuration takes precedence, and static configuration is ineffective. Creating a flow control configuration strategy based on business needs includes the following steps: Set up traffic control rules based on business needs, and configure corresponding traffic control parameters for the traffic control rules; The token bucket's state information is initialized based on the flow control parameters to obtain the flow control configuration strategy; The system receives and parses client requests to obtain corresponding key-value pair information. The client request is an HTTP request, including request headers, request parameters, and a request body. The request headers are used to transmit client configuration information, request details, and a description of the client's capabilities. The request parameters appear in the query string portion of the URL and are used to transmit simple key-value pair data. The request body includes a POST request body, used when data needs to be sent and the request method supports it. Obtaining the key-value pair information corresponding to the client request includes the following steps: extracting the header fields of the client request and converting them into header key-value pairs; extracting the parameter fields of the client request and converting them into parameter key-value pairs; extracting the request body fields of the client request and converting them into request body key-value pairs. The key-value pair information is matched with the flow control configuration strategy to obtain the matching result; Based on the matching results, the flow control configuration strategy is dynamically adjusted to obtain the execution strategy, and then the flow control operation is performed based on the execution strategy. Dynamically adjusting the flow control configuration strategy based on the matching results to obtain an execution strategy, and then performing flow control operations based on the execution strategy, includes the following steps: By combining the matching results with the token bucket status information, the flow control configuration strategy adjustment requirements can be identified. Based on the flow control configuration strategy adjustment requirements, adjust the token bucket status information and obtain the execution strategy; The flow control operation is performed based on the execution strategy. The token bucket's status information includes the current number of tokens, the token generation rate, the token consumption rate, and the token bucket capacity.

2. The adaptive multi-dimensional flow control method according to claim 1, characterized in that: Receiving and parsing client requests to obtain the corresponding key-value pair information includes the following steps: Identify the request characteristics of the client request, wherein the request characteristics include client attribute characteristics and behavioral characteristics; Based on the request characteristics, the target fields of the client request are extracted and converted into corresponding key-value pairs.

3. The adaptive multi-dimensional flow control method according to claim 1, characterized in that: The extracted key-value pair information is matched with the flow control configuration policy to obtain the matching results, which includes the following steps: The flow control rules corresponding to the key-value pair information are identified in the flow control configuration strategy; The key-value pair information is matched with the traffic control parameters configured in the traffic control rules to obtain preliminary matching results; The preliminary matching result is matched with the traffic control parameters configured in the traffic control rules to obtain the final matching result.

4. The adaptive multi-dimensional flow control method according to claim 1, characterized in that: The method also includes an exception handling mechanism: The detected abnormal client requests are classified to obtain abnormal request categories, which include temporary abnormalities, recoverable abnormalities, and systemic abnormalities. Set corresponding exception handling strategies for different types of abnormal requests, wherein the exception handling strategies include ignoring exceptions, retrying requests, and issuing alarms; Based on the abnormal request classification and the abnormal handling strategy, the corresponding abnormal traffic control operation is executed.

5. An adaptive multi-dimensional flow control system, characterized in that, include: The information extraction module is used to receive and parse the client request to obtain the corresponding key-value pair information; Obtaining key-value pair information corresponding to a client request includes the following steps: extracting the header fields of the client request and converting them into header key-value pairs; extracting the parameter fields of the client request and converting them into parameter key-value pairs; extracting the request body fields of the client request and converting them into request body key-value pairs; the client request is an HTTP request, including request headers, request parameters, and a request body; the request headers are used to transmit client configuration information, request details, and a description of the client's capabilities; the request parameters appear in the query string part of the URL and are used to transmit simple key-value pair data; the request body includes a POST request body, used when data needs to be sent and the request method supports it; The flow control strategy configuration module is used to create flow control configuration strategies based on business requirements. These strategies include setting flow control rules, configuring flow control parameters, and maintaining token bucket status information. The flow control rules include static and dynamic configuration rules. Static configuration rules are set via annotation parameters within the code and are used for static resource configuration, fixed business logic, and system configuration with low change frequency. Dynamic configuration rules are set through an external configuration center and are used for dynamic resource configuration, business logic with high change frequency, and system configuration adjusted in real time. When both static and dynamic configurations exist, dynamic configuration takes precedence, and static configuration is ineffective. Creating a flow control configuration strategy based on business needs includes the following steps: Set up traffic control rules based on business needs, and configure corresponding traffic control parameters for the traffic control rules; The token bucket's state information is initialized based on the flow control parameters to obtain the flow control configuration strategy; The flow control decision module is used to match the extracted key-value pair information with the flow control strategy to obtain the matching result; based on the matching result, the flow control configuration strategy is dynamically adjusted to obtain the execution strategy, and then the flow control operation is performed based on the execution strategy. The token bucket management module is used to configure parameters of the token bucket based on the flow control policy configuration module, and to dynamically adjust the flow control policy configuration module based on the flow control decision module to achieve flow control operations. Dynamically adjusting the flow control configuration strategy based on the matching results to obtain an execution strategy, and then performing flow control operations based on the execution strategy, includes the following steps: By combining the matching results with the token bucket status information, the flow control configuration strategy adjustment requirements can be identified. Based on the flow control configuration strategy adjustment requirements, adjust the token bucket status information and obtain the execution strategy; The flow control operation is performed based on the execution strategy. The token bucket's status information includes the current number of tokens, the token generation rate, the token consumption rate, and the token bucket capacity.

6. An electronic device, characterized in that, include: One or more processors; and One or more memories, wherein computer-readable code is stored in the memories, the computer-readable code, when executed by the one or more processors, implements the control method as described in any one of claims 1 to 4.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by an electronic device, the program implements the adaptive multi-dimensional flow control method as described in any one of claims 1 to 4.

Images