A parameter resource isolation-based traffic control system and method

Abstract

This invention belongs to the field of computer software technology, and particularly relates to a traffic control system and method based on parameter resource isolation. The system comprises five modules: traffic acquisition, parameter parsing, resource isolation management, traffic control execution, and dynamic configuration. First, it intercepts business requests and extracts multi-dimensional key parameters. A unique resource group identifier is generated using consistent hashing, and each resource group is bound to an independent sliding window flow control state machine. Quotas are generated by integrating static and dynamic adaptive rate limiting strategies based on operational metrics. Then, differentiated flow control is executed based on the quota and window statistics results, while also supporting real-time hot updates of configuration. This invention can solve the problems of low resource utilization and easy fault propagation in existing technologies under complex business request scenarios.

Description

Technical Field

[0001] This invention belongs to the field of computer software technology, and in particular relates to a flow control system and method based on parameter resource isolation. Background Technology

[0002] In large-scale applications of distributed microservice architectures, traffic control for high-concurrency business requests is a core technical aspect of ensuring system stability. Traffic control frameworks need to achieve reasonable scheduling and resource allocation of service requests to avoid problems such as system resource exhaustion and service unavailability caused by sudden traffic spikes or hot requests. Currently, mainstream traffic control frameworks (such as Sentinel, Hystrix, and Resilience4j) mainly implement global, interface-level, or user-level traffic control. Their core design idea is to configure and execute rate limiting rules based on a single dimension of request characteristics.

[0003] However, in complex real-world business scenarios, the characteristics of service requests are determined by multiple interface parameters. Existing technologies cannot achieve fine-grained resource isolation and traffic control based on multi-parameter combinations, leading to two core technical problems, which are further amplified in high-concurrency scenarios: 1. Performance bottleneck of parameter parsing and rule matching: If the existing framework wants to achieve parameter-level control, it needs to perform parameter parsing operations such as JSON decoding, URL parsing, and regular expression matching on all requests. At the same time, rule matching is completed through range query and wildcard matching. This process will consume a lot of CPU resources and can easily become a system performance bottleneck under high concurrency requests, increasing request processing latency and reducing service response efficiency.

[0004] 2. Insufficient flexibility and expressiveness of parameter matching strategies: In actual business, differentiated rate limiting rules need to be formulated based on multiple parameter combinations such as interface name, method name, user ID, business scenario, and request IP. However, the existing framework only supports rule configuration for single or simple parameters, which cannot achieve resource rule matching with multiple conditions and is difficult to adapt to the flexible management and control needs of complex businesses.

[0005] The aforementioned problems directly lead to the shortcomings of existing technologies, such as low resource utilization and easy spread of faults: on the one hand, a sudden surge in traffic from a single hotspot parameter can exhaust the global resources of the service, causing business requests corresponding to other normal parameters to be rate-limited as well, and system resources to be ineffectively occupied due to "local hotspots"; on the other hand, fixed rate-limiting strategies cannot dynamically adjust quotas according to the real-time operating status of business resource groups, and cannot achieve reasonable allocation of system resources, further reducing resource utilization. Summary of the Invention

[0006] The technical problem solved by this invention is to provide a flow control system and method based on parameter resource isolation, so as to solve the problems of low resource utilization and easy fault propagation in the prior art under complex business request scenarios.

[0007] The basic solution provided by this invention is a flow control system based on parameter resource isolation, comprising a flow acquisition module, a parameter parsing module, a resource isolation management module, a flow control execution module, and a dynamic configuration module, wherein: The traffic collection module is used to intercept business requests flowing into the target service, collect the raw data of the business requests, and encapsulate them into a request context; The parameter parsing module connects to the traffic acquisition module to obtain the request context and extract multi-dimensional key parameters required by the business resource group based on preset parameter extraction rules, and generate a unique and fixed resource group identifier. The resource isolation management module is used to bind an independent sliding window flow control state machine to each business resource group, and integrate static flow limiting strategies and dynamic adaptive flow limiting strategies to generate traffic quota strategies; The flow control execution module connects the parameter parsing module and the resource isolation management module. The flow control execution module obtains the sliding window statistics of the corresponding sliding window flow control state machine according to the resource group identifier of the business resource group, and obtains the corresponding flow quota of the business resource group according to the flow quota policy. The flow control execution module is also used to perform differentiated flow control operations according to preset rules based on the flow quota and sliding window statistics results corresponding to the business resource group. The dynamic configuration module connects to the resource isolation management module. Based on a visual management interface and standardized API, the dynamic configuration module allows administrators to dynamically operate on configuration items and synchronize all configuration changes to each module in real time.

[0008] Furthermore, the original data of the business request includes, but is not limited to, request header information, interface name, method name, request parameters, request system IP, user ID, business scenario identifier, and request timestamp.

[0009] Furthermore, the parameter parsing module includes a parameter extraction unit and an identifier generation unit, wherein: The parameter extraction unit is used to extract key parameters based on JSONPath, regular expressions, and reflection; the key parameters are denoted as a set. ; The identifier generation unit is used for the key parameter set Perform lexicographical sorting to obtain ordered parameter combinations. ; The identifier generation unit is also used to combine ordered parameters. The consistent hashing algorithm is used to generate a fixed-length and unique resource group identifier. The expression is:

[0010] in, This is a string concatenation function that concatenates ordered combinations of parameters into a single string using a fixed delimiter. Based on the hash function; It is a consistent hash function that maps the basic hash value to a ring hash space of size M, where M is an integer power.

[0011] Furthermore, the resource isolation management module includes a resource group management unit, a sliding window unit, and a rate limiting policy management unit, wherein: The resource group management unit associates each business resource group with a unique resource group identifier and divides it into independent resource isolation units, configuring dedicated traffic quotas and sliding window flow state machines; the traffic quota includes the maximum QPS. and maximum concurrency ; The sliding window unit divides the timeline into sub-windows of fixed length based on the sliding window flow state machine, and aggregates the number of business requests within a preset time range by counting the sub-windows; The rate limiting policy management unit is used to allocate traffic quotas to each business resource group based on preset static rate limiting policies and dynamic adaptive rate limiting policies, and to generate an independent and exclusive traffic quota policy for each business resource group.

[0012] Furthermore, in the sliding window unit, the timeline is divided into sub-windows of fixed length based on the sliding window flow state machine. The number of service requests within a preset time range is aggregated by counting the sub-windows. Specifically: Set the length of the child window of the sliding window to The statistical time window is Then count the number of sub-windows contained within the time window. ; Set the request timestamp to Then the current child window corresponding to this request is:

[0013] in, This is the system's initial timestamp. This is the floor function; The current child window; Set child window The number of business requests is Then the statistical time window Total number of service requests within The sum of the counts of the most recent N child windows is expressed as:

[0014] like If the data usage is within the limit, it is considered that the data usage is within the limit; otherwise, it is considered that the data usage exceeds the limit. Extract the current concurrency count within the sliding window .

[0015] Furthermore, in the rate limiting policy management unit, the preset static rate limiting policy is a fixed traffic quota configured based on the parameter combination of the service resource group, including the maximum QPS. Maximum concurrency Then the static quota for this business resource group is , ; The preset dynamic adaptive rate limiting strategy allocates traffic quotas to each business resource group as follows: Collect core operational metrics for each business resource group, including business resource pool latency metrics. Error rate metrics and resource utilization rate indicators Generate an indicator set, denoted as ; The collected core operational indicators were normalized to... Specifically: Normalized value of business resource pool latency metric :

[0016] in, This is the maximum allowable latency of the system; Error rate metric normalized value :

[0017] in, The maximum error rate allowed by the system; Normalized value of resource utilization rate index :

[0018] in, and This is the preset optimal interval. ; Adjustable weights are configured based on normalized business resource pool latency, error rate, and resource utilization metrics. , , The overall score of the business resource group The calculation expression is:

[0019] in, ; Set the current total available bandwidth of the system to The current number of business resource groups is K, and the overall score of the k-th business resource group is Then the dynamic QPS quota for the kth business resource group for:

[0020] Similarly, the dynamic quota for maximum concurrency. The final effective quota for this business resource group is obtained by allocating resources proportionally according to the above formula. , .

[0021] Furthermore, in the flow control execution module, the sliding window statistics result includes the number of requests in the sliding window. Current concurrency ; Traffic quotas include the real-time quota results for this business resource group. , ; Based on the traffic quota and sliding window statistics corresponding to the business resource group, differentiated traffic control operations are performed according to preset rules, specifically as follows: like and If sufficient resources are determined, the request is directly allowed to proceed to the backend service, and a normal response is returned after the request is processed. like or If resources are deemed insufficient, a secondary decision is executed; the secondary decision includes: If the system enables queue waiting, business requests will be placed in the waiting queue. If the resource is released within the timeout period, the request will be executed; otherwise, the business request will be rejected. If the system does not have queue waiting enabled, the business request will be rejected directly, and a rate limiting error response will be returned. If the business group member group is configured with a degradation policy, the degradation will be triggered and a degradation response will be returned.

[0022] A flow control method based on parameter resource isolation, applied to the aforementioned flow control system based on parameter resource isolation, includes: S1: Intercept business requests flowing into the target service, collect the raw data of the business requests, and encapsulate them into a request context; S2: Obtain the request context and extract the multi-dimensional key parameters required by the business resource group based on the preset parameter extraction rules, and generate a unique and fixed resource group identifier; S3: Binds an independent sliding window flow control state machine to each business resource group, and integrates static rate limiting strategies and dynamic adaptive rate limiting strategies to generate traffic quota strategies; S4: Obtain the sliding window statistics of the corresponding sliding window flow control state machine based on the resource group identifier of the business resource group, and obtain the corresponding traffic quota of the business resource group according to the traffic quota policy; S5: Based on the traffic quota and sliding window statistics of the business resource group, perform differentiated traffic control operations according to preset rules; S6: Based on a visual management interface and standardized API, it allows administrators to dynamically operate on configuration items.

[0023] The principle and advantages of this invention are as follows: The technical solution of this application takes parameter resource isolation as the core. It intercepts business requests and collects raw data through the traffic acquisition module. It extracts key parameters such as interface name and user ID from the request context through the parameter parsing module and generates a unique identifier through consistent hashing. Then, the resource isolation management module maintains the mapping relationship between parameter combinations and business resource groups. It binds an independent sliding window flow control state machine to each resource group. It combines two flow control strategies, namely static fixed quota and dynamic weight adaptive flow control based on latency, error rate and resource utilization, to realize quota allocation. At the same time, the flow control executor matches the strategy according to the resource group identifier and performs the release, queuing or rejection operation. The dynamic configuration center supports real-time hot update of the strategy without restarting the service.

[0024] The advantages are: First, it achieves fine-grained resource isolation at the parameter level, further decentralizing traffic control granularity from the global or user level, preventing a single service hotspot parameter from exhausting global resources; second, it significantly improves system stability, controlling the impact of a fault when a single parameter resource group triggers rate limiting to the smallest granularity, without affecting the normal service of other resource groups; third, it has high flexibility and operational efficiency, with the dynamic configuration center supporting real-time hot updates of policies, enabling rapid response to changes in business needs without service interruption; fourth, it improves the overall resource utilization of the system, avoiding resource idleness caused by global rate limiting triggered by a few hotspots, allowing for more full and reasonable allocation of system resources, while also solving the performance bottleneck of parameter parsing and rule matching in high-concurrency scenarios and reducing request latency. Attached Figure Description

[0025] Figure 1 This is a schematic diagram illustrating the processing in an embodiment of the present invention; Figure 2 This is a flowchart of an embodiment of the present invention. Detailed Implementation

[0026] The following detailed description illustrates the specific implementation method: The basic implementation examples are as follows: Figure 1 As shown: A flow control system based on parameter resource isolation includes a flow acquisition module, a parameter parsing module, a resource isolation management module, a flow control execution module, and a dynamic configuration module, wherein: The traffic acquisition module is used to intercept business requests flowing into the target service, collect the raw data of the business requests, and encapsulate them into a request context. In this embodiment, the traffic acquisition module adopts a non-intrusive interception architecture and is deployed at the service entry layer of the target microservice. It supports mainstream microservice frameworks (such as Spring Cloud, Dubbo, gRPC) and mainstream communication protocols such as HTTP / HTTPS and RPC. It achieves full interception of business requests through the framework's native interceptors, filters, or aspect-oriented programming (AOP) to avoid intrusive modifications to the business code and reduce system coupling.

[0027] Meanwhile, in distributed deployment scenarios, the module supports clustered deployment, corresponding one-to-one with the instance nodes of the target service, ensuring that all incoming requests to each service node can be collected in real time and in full, without any issues of missing or duplicate requests.

[0028] After the above traffic collection module is deployed, the request interception is triggered before the business request reaches the core business logic of the target service. The triggering node is located after the network protocol parsing of the service is completed and before parameter verification and business processing, ensuring that the collected raw data is the original request data without business logic processing, and avoiding collection failure due to abnormalities in the business processing stage.

[0029] The traffic acquisition module performs full-dimensional native data collection on business requests flowing into the target service. The collected raw data covers dimensions such as request identifier, business characteristics, network characteristics, and time characteristics, specifically including but not limited to: Request header information: Identification information, authentication information, request origin identifier, etc. in HTTP request headers / RPC protocol headers; Interface name and method name: the target service's interface name, the interface call method name, and the interface version number; Request parameters: All input parameters carried in the request, including URL parameters, POST body parameters, RPC input parameters, etc., supporting structured / unstructured parameters; Requesting system IP: The system IP address and port number that initiated the request, and the local IP address and port number of the service receiving the request; User ID and Business Scenario Identifier: Unique User ID, Tenant ID, Business Scenario Identifier, Business Process ID; Request timestamp: The precise timestamp (accurate to milliseconds) at which the request arrived at the service, providing a time reference for subsequent sliding window statistics.

[0030] The raw data collected above is encapsulated into a request context. The context object consists of fields that correspond one-to-one with the raw data. The encapsulation process involves filling the corresponding fields of the context object according to the field mapping rules to obtain the final encapsulated request context.

[0031] The parameter parsing module connects to the traffic acquisition module to obtain the request context and extract multi-dimensional key parameters required by the business resource group based on preset parameter extraction rules, generating a unique and fixed resource group identifier. In this embodiment, the parameter parsing module and the traffic acquisition module are tightly coupled and deployed in the subsequent processing node of the service entry layer of the target microservice. They share the same resource scheduling system within the same service process, avoiding performance loss from cross-process data transmission. At the same time, the interaction between the parameter parsing module and upstream and downstream modules follows standardized unidirectional data flow rules, that is, it synchronously obtains the encapsulated standardized request context object from the traffic acquisition module without calling any interface of the acquisition module in reverse. After parsing, it only outputs the set of key parameters and the unique resource group identifier to the resource isolation management module and the traffic control execution module, without redundant data transmission, ensuring interaction efficiency under high concurrency.

[0032] The parameter parsing module consists of two independent and sequentially executed functional units: a parameter extraction unit and an identifier generation unit. Specifically: The parameter extraction unit performs key parameter extraction operations based on configurable parameter extraction rules. These rules are preset, modified, and synchronized in real-time by the administrator through a dynamic configuration module, eliminating the need to restart the module. This adapts to the dynamic adjustment requirements of business resource group partitioning rules. The specific implementation process is as follows: After the parameter extraction unit starts, it pulls the preset parameter extraction rules from the dynamic configuration module. The rules include extraction dimensions, extraction methods, and parameter validation rules. Then, it receives the request context object output by the traffic collection module. Based on the parameter format identifier in the request context, such as JSON, URL encoding, or binary structured data, it matches the corresponding parsing method. Specifically, for JSON format request parameters and request header information, JSONPath parsing is used; for URL parameters and unstructured string parameters, regular expression matching is used; and for structured input parameters of the RPC protocol and interface / method name parameters built into the framework, reflection mechanism is used for extraction.

[0033] After the above parsing and extraction are completed, each extracted key parameter is validated to filter out null values ​​and invalid parameters with illegal formats. The valid key parameters that pass the validation are recorded as a set. ; The key parameter set generated by the parameter extraction unit is unordered. The identifier generation unit identifies the unordered key parameter set. Sort the parameter names in ascending order according to lexicographical order to generate ordered parameter combinations. ;in , , The parameters are sorted into name-value key-value pairs; then, based on the ordered parameter combinations... The consistent hashing algorithm is used to generate a fixed-length and unique resource group identifier. The expression is:

[0034] in, This is a string concatenation function that concatenates ordered combinations of parameters into a single string using a fixed delimiter. Use the base hash function, such as MD5 or SHA-256; A consistent hash function maps the base hash value to a ring hash space of size M, where M is an integer power. For example... , Adjustments can be made through the dynamic configuration module.

[0035] The resource isolation management module is used to bind an independent sliding window flow control state machine to each business resource group and integrate static rate limiting policies and dynamic adaptive rate limiting policies to generate traffic quota policies. In this embodiment, the resource isolation management module is deployed in conjunction with the parameter parsing module, the flow control execution module, and the dynamic configuration module. It synchronously obtains the unique resource group identifier corresponding to the business request from the parameter parsing module, which serves as the core basis for business resource matching. It outputs the sliding window statistics results and real-time traffic quota policies of the target business resource group to the flow control execution module. At the same time, it works in real time with the dynamic configuration module to receive real-time updates of configuration items such as static rate limiting policy configuration, dynamic adaptive policy weight, and sliding window parameters.

[0036] In practice, the resource isolation management module consists of a resource group management unit, a sliding window unit, and a rate limiting policy management unit. The resource group management unit completes the basic resource isolation construction, the sliding window unit realizes real-time traffic data statistics, and the rate limiting policy management unit generates differentiated quota policies based on statistical data. The three work together to achieve full-process management of "isolation-statistics-quota". The specific functional boundaries are as follows: The resource group management unit associates each business resource group with a unique resource group identifier and divides it into independent resource isolation units, configuring dedicated traffic quotas and sliding window flow state machines; the traffic quota includes the maximum QPS. and maximum concurrency The resource group management unit is the foundation for achieving parameter-level resource isolation in this application. Its core objective is to ensure that one resource group identifier corresponds to one independent resource isolation unit, thus preventing resource contention and fault propagation between different business resource groups. The specific process is as follows: First, after the resource group management unit starts, it retrieves the basic mapping rules between resource group identifiers and business resource groups from the dynamic configuration module, and initializes an empty resource group mapping table. The core resource of the mapping table is the "unique resource group identifier". "-Business Group Member Group Name-Resource Isolation Unit ID-Basic Configuration Parameters"; Subsequently, upon receiving the resource group identifier output by the parameter parsing module, a match is performed in the local resource group mapping table. If the match is successful, the created resource isolation unit corresponding to the resource group identifier is directly retrieved; if the match fails, the dynamic creation mechanism of the resource isolation unit is immediately triggered, a unique resource isolation unit ID is assigned to the resource group identifier, an independent resource isolation unit is created, and the mapping relationship is written to the resource group mapping table to support fast matching for subsequent requests; Subsequently, each newly created resource isolation unit is configured with dedicated basic flow control parameters, including sliding window sub-window length, statistical time window, default static quota, dynamic adaptive policy switch, etc. All parameters are managed uniformly by the dynamic configuration module, supporting real-time hot updates without the need to restart the unit. The sliding window unit divides the timeline into fixed-length sub-windows based on a sliding window flow state machine. It aggregates the number of business requests within a preset time range by counting the sub-windows. Specifically, the sliding window unit binds an independent sliding window flow control state machine to each resource isolation unit, achieving accurate and real-time statistics of business request traffic. This provides data support for the execution of traffic quota policies. The statistical results include the total number of requests within the statistical time window and the current concurrency. The specific implementation process is as follows: Set the length of the child window of the sliding window to The statistical time window is Then count the number of sub-windows contained within the time window. ; It is a positive integer; Set the request timestamp to Then the current child window corresponding to this request is:

[0037] in, This is the system's initial timestamp. This is the floor function; The current child window; Set child window The number of business requests is Then the statistical time window Total number of service requests within The sum of the counts of the most recent N child windows is expressed as:

[0038] like If the data usage is within the limit, it is considered that the data usage is within the limit; otherwise, it is considered that the data usage exceeds the limit. Extract the current concurrency count within the sliding window Specifically, an independent concurrency counter is maintained for each resource isolation unit. When a request enters the business processing stage, the counter is incremented by 1, and when the request is processed, it is decremented by 1. The real-time value of the counter is recorded as the current concurrency of that resource isolation unit.

[0039] The rate limiting policy management unit is used to allocate traffic quotas to each service resource group based on preset static rate limiting policies and dynamic adaptive rate limiting policies, generating an independent and exclusive traffic quota policy for each service resource group. Specifically, the rate limiting policy management unit integrates the static rate limiting policy and the dynamic adaptive rate limiting policy for each service resource group to generate a real-time and effective traffic quota policy. The core quota metric is the maximum QPS. and maximum concurrency Specifically: The static rate limiting strategy is as follows: Static quota configuration parameters, including the maximum QPS, are retrieved from the dynamic configuration module for each business resource group. Maximum concurrency If the business resource group does not have a dynamic adaptive rate limiting policy enabled, the static quota will be used directly as the effective traffic quota. , ; The dynamic adaptive rate limiting strategy provides business resource groups with dynamic traffic quotas based on operational metrics, adapting to scenarios of fluctuating business demand and changes in system resource status. Its core is to intelligently allocate quotas based on the real-time operational metrics of the business resource groups, ensuring optimal utilization of system resources. The specific execution logic is as follows: Collect core operational metrics for each business resource group, including: Business resource pool latency metrics : The average processing latency for all requests within this resource isolation unit; Error rate metrics This represents the percentage of abnormal requests within this resource isolation unit out of the total number of requests. Resource utilization rate indicators This refers to the utilization rate of system resources such as CPU and memory occupied by this resource isolation unit.

[0040] Generate an indicator set, denoted as ; The collected core operational indicators were normalized to... Specifically: Normalized value of business resource pool latency metric :

[0041] in, The maximum allowed latency by the system is preset by the dynamic configuration module; Error rate metric normalized value :

[0042] in, The maximum error rate allowed by the system is preset by the dynamic configuration module; Normalized value of resource utilization rate index :

[0043] in, and This is the preset optimal interval. ; Adjustable weights are configured based on normalized business resource pool latency, error rate, and resource utilization metrics. , , The overall score of the business resource group The calculation expression is:

[0044] in, A higher score indicates a better operating status for the business resource group and a greater amount of traffic quota that can be allocated.

[0045] Set the current total available bandwidth of the system to The current number of business resource groups is K, and the overall score of the k-th business resource group is Then the dynamic QPS quota for the kth business resource group for:

[0046] Similarly, the dynamic quota for maximum concurrency. The final effective quota for this business resource group is obtained by allocating resources proportionally according to the above formula. , .

[0047] The flow control execution module connects the parameter parsing module and the resource isolation management module. Based on the resource group identifier of the service resource group, the flow control execution module obtains the sliding window statistics of the corresponding sliding window flow control state machine, and obtains the corresponding flow quota for the service resource group according to the flow quota policy. The flow control execution module is also used to execute differentiated flow control operations according to preset rules based on the flow quota corresponding to the service resource group and the sliding window statistics. In this embodiment, firstly, the flow control execution module... Perform precise matching of target business resource groups, retrieve the corresponding sliding window statistics and real-time traffic quota policies. The sliding window statistics include the number of requests in the sliding window. Current concurrency The traffic quota obtained from the real-time traffic quota policy includes the real-time quota result for the business resource group. , ; Next, the sliding window statistics and traffic quotas are compared across multiple thresholds to determine whether resources are sufficient. Specifically: like and If sufficient resources are determined, the request is directly allowed to proceed to the backend service, and a normal response is returned after the request is processed. like or If resources are insufficient, the system outputs a first-level decision result of "insufficient resources" and then executes a second-level decision. The second-level decision includes: If the system enables queue waiting, business requests will be placed in the waiting queue. If the resource is released within the timeout period, the request will be executed; otherwise, the business request will be rejected. If the system does not have queue waiting enabled, the business request will be rejected directly, and a rate limiting error response will be returned. If the business group member group is configured with a degradation policy, the degradation will be triggered and a degradation response will be returned.

[0048] Finally, the primary and secondary decision results are encapsulated into standardized decision instructions, including operation type and configuration parameters (such as timeout), and pushed synchronously to the traffic control execution unit. The decision instructions are stateless data, supporting rapid parsing and execution.

[0049] The dynamic configuration module connects to the resource isolation management module. Based on a visual management interface and standardized APIs, the dynamic configuration module allows administrators to dynamically manipulate configuration items and synchronize all configuration changes to each module in real time. In this embodiment, the dynamic configuration module adopts an independent deployment + distributed clustered architecture, decoupled from the four major business modules mentioned above. It achieves real-time linkage with the business modules through a dedicated intranet communication link, avoiding the impact of module failures on business traffic control processes. Simultaneously, the module itself supports clustered deployment, with configuration data stored in a highly available distributed storage engine, achieving persistent configuration data and disaster recovery backup, ensuring high availability of the configuration service.

[0050] The dynamic configuration module is structured into four layers: configuration access layer, configuration processing layer, configuration storage layer, and configuration synchronization layer. The configuration access layer provides two types of entry points for configuration operations: a visual management interface and standardized APIs. This supports administrator operations and automated invocation by the operations and maintenance system. Specifically: Visualized management interface: Based on B / S architecture, it provides a visual interface for editing, querying, modifying, deleting, and batch configuring configurations. It supports configuration filtering by module and resource group, provides default value prompts for configuration items and parameter range verification to reduce the error rate of manual operation; at the same time, it provides visual monitoring of configuration status, displaying the effective status and synchronization range of each configuration item in real time. Standardized API: Provides both RESTful API and RPC API interfaces, supports JSON format configuration data transmission, and is compatible with batch configuration and invocation of operation and maintenance platforms and automated scripts. The interface includes authentication and parameter validation logic to ensure the security of configuration operations. The API supports single configuration item operations and batch configuration item operations to meet the configuration management needs of large-scale clusters. The configuration processing layer, as the core of the module, completes the configuration item validity verification, configuration format standardization, configuration version management, and operation auditing; the specific implementation process is as follows: Configuration validity verification: Performs triple verification on configuration items, including format verification, range verification, and logical verification, to ensure that the configuration data is valid; Configuration format standardization: Convert the validated configuration data into a standardized configuration format of the system to generate a unified configuration object, ensuring that the four major business modules can be directly parsed without secondary processing; Configuration version management: Generate a unique version number for each configuration change. The version number includes information such as the configuration change time, the operator, and the module that was changed. At the same time, it saves historical version data of the configuration and supports configuration version rollback. When a problem occurs after the new configuration takes effect, it can be quickly rolled back to a previously usable version. Operation audit logs: All configuration operations are fully audited and recorded. The logs include the operator, operation time, operation type (add / modify / delete / batch configuration), changed configuration items, values ​​before and after the change, and operation results. The audit logs are permanently stored (with configurable retention period) and can be queried and exported as needed, ensuring the traceability of configuration operations.

[0051] The configuration storage layer adopts a dual storage mode of memory caching + persistent storage to achieve fast reading and persistent saving of configuration data; wherein: Distributed persistent storage: Employs a highly available and highly consistent distributed key-value storage engine as the underlying persistent storage, storing standardized configuration data... "Configuration Dimension - Configuration Key - Configuration Value" It stores configuration data in key-value pair format, supports quick querying and modification by configuration dimension and configuration key, and implements multiple copy backup of configuration data to avoid configuration data loss due to single node failure. Memory caching: A local configuration cache is built in each cluster instance of the dynamic configuration module to cache the current fully effective configuration data. A mechanism of timed refresh + change-triggered refresh is adopted to ensure that the cached data is consistent with the persistent storage data. The local cache provides fast read capability for business modules to pull on demand, improving the efficiency of configuration retrieval.

[0052] The configuration synchronization layer is based on a publish-subscribe pattern, synchronizing configuration changes to all business module cluster instances in real time to ensure system-wide configuration consistency. The specific process is as follows: Configuration change publication: Once the configuration processing layer has completed the persistence and version management of configuration changes, it immediately publishes the configuration change information (including changed configuration items, new version number, and scope of effect) to the module's built-in distributed message topic. Subtopics are divided according to business modules (such as collection module topic, parsing module topic, isolation management module topic, and execution module topic) to ensure that business modules only subscribe to their own relevant configuration topics and reduce invalid data transmission. Business module subscription and reception: All cluster instances of the four major business modules have subscribed to the corresponding data topics in advance. When new configuration change information is detected in the topic, the configuration change data is received immediately in real time. Local configuration update and activation: After receiving configuration change data, the business module performs an atomic local configuration cache update. The update process does not affect the currently executing traffic control operation, ensuring that hot configuration updates are seamless. After the configuration update is completed, the new configuration items take effect immediately, and subsequent traffic control processes all use the latest configuration. Synchronization result feedback and verification: After the business module completes the local configuration update, it returns configuration effectiveness feedback information to the dynamic configuration module, including instance ID, configuration version number, and effective time; the dynamic configuration module collects feedback information from all instances, displays the configuration synchronization status in real time, and triggers a timed re-push mechanism for instances that have not successfully synchronized to ensure that the configuration synchronization of all instances is completed.

[0053] Therefore, the implementation of this dynamic configuration module enables centralized, visual, and dynamic management of all configuration items in the traffic control system based on parameter resource isolation. It achieves real-time hot updates of configurations through a publish-subscribe model, solving the problems of service interruption and inconsistent configurations across multiple modules in existing technologies. Simultaneously, through granular access control, full-process operation auditing, comprehensive version management, and anomaly alerts, it ensures the security, traceability, and effectiveness of configuration operations. The module's independent deployment and high availability design make it the stable configuration hub of the entire traffic control system, supporting granular and flexible traffic management across the four major business modules. Ultimately, it achieves high flexibility, high operational efficiency, and high stability for the entire system in complex business scenarios, collaborating with other modules to complete parameter-level fine-grained traffic management, improving system resource utilization, and preventing the spread of faults.

[0054] like Figure 2 As shown, in another embodiment of this example, a flow control method based on parameter resource isolation is further included, applied to the above-described flow control system based on parameter resource isolation, comprising: S1: Intercept business requests flowing into the target service, collect the raw data of the business requests, and encapsulate them into a request context; S2: Obtain the request context and extract the multi-dimensional key parameters required by the business resource group based on the preset parameter extraction rules, and generate a unique and fixed resource group identifier; S3: Binds an independent sliding window flow control state machine to each business resource group, and integrates static rate limiting strategies and dynamic adaptive rate limiting strategies to generate traffic quota strategies; S4: Obtain the sliding window statistics of the corresponding sliding window flow control state machine based on the resource group identifier of the business resource group, and obtain the corresponding traffic quota of the business resource group according to the traffic quota policy; S5: Based on the traffic quota and sliding window statistics of the business resource group, perform differentiated traffic control operations according to preset rules; S6: Based on a visual management interface and standardized API, it allows administrators to dynamically operate on configuration items.

[0055] The above are merely embodiments of the present invention. Commonly known structures and characteristics are not described in detail here. Those skilled in the art are aware of all common technical knowledge in the field prior to the application date or priority date, are aware of all existing technologies in that field, and have the ability to apply conventional experimental methods prior to that date. Those skilled in the art can, under the guidance of this application, improve and implement this solution in combination with their own capabilities. Some typical known structures or methods should not be obstacles for those skilled in the art to implement this application. It should be noted that those skilled in the art can make several modifications and improvements without departing from the structure of the present invention. These should also be considered within the scope of protection of the present invention, and will not affect the effectiveness of the implementation of the present invention or the practicality of the patent. The scope of protection claimed in this application should be determined by the content of its claims, and the specific embodiments described in the specification can be used to interpret the content of the claims.

Claims

1. A flow control system based on parameter resource isolation, characterized in that: It includes a traffic acquisition module, a parameter parsing module, a resource isolation management module, a traffic control execution module, and a dynamic configuration module, among which: The traffic collection module is used to intercept business requests flowing into the target service, collect the raw data of the business requests, and encapsulate them into a request context; The parameter parsing module connects to the traffic acquisition module to obtain the request context and extract multi-dimensional key parameters required by the business resource group based on preset parameter extraction rules, and generate a unique and fixed resource group identifier. The resource isolation management module is used to bind an independent sliding window flow control state machine to each business resource group, and integrate static flow limiting strategies and dynamic adaptive flow limiting strategies to generate traffic quota strategies; The flow control execution module connects the parameter parsing module and the resource isolation management module. The flow control execution module obtains the sliding window statistics of the corresponding sliding window flow control state machine according to the resource group identifier of the business resource group, and obtains the corresponding flow quota of the business resource group according to the flow quota policy. The flow control execution module is also used to perform differentiated flow control operations according to preset rules based on the flow quota and sliding window statistics results corresponding to the business resource group. The dynamic configuration module connects to the resource isolation management module. Based on a visual management interface and standardized API, the dynamic configuration module allows administrators to dynamically operate on configuration items and synchronize all configuration changes to each module in real time.

2. The flow control system based on parameter resource isolation according to claim 1, characterized in that: The raw data of the business request includes, but is not limited to, request header information, interface name, method name, request parameters, request system IP, user ID, business scenario identifier, and request timestamp.

3. A flow control system based on parameter resource isolation according to claim 1, characterized in that: The parameter parsing module includes a parameter extraction unit and an identifier generation unit, wherein: The parameter extraction unit is used to extract key parameters based on JSONPath, regular expressions, and reflection; the key parameters are denoted as a set. ; The identifier generation unit is used for the key parameter set Perform lexicographical sorting to obtain ordered parameter combinations. ; The identifier generation unit is also used to combine ordered parameters. The consistent hashing algorithm is used to generate a fixed-length and unique resource group identifier. The expression is: in, This is a string concatenation function that concatenates ordered combinations of parameters into a single string using a fixed delimiter. Based on the hash function; It is a consistent hash function that maps the basic hash value to a ring hash space of size M, where M is an integer power.

4. A flow control system based on parameter resource isolation according to claim 3, characterized in that: The resource isolation management module includes a resource group management unit, a sliding window unit, and a rate limiting policy management unit, wherein: The resource group management unit associates each business resource group with a unique resource group identifier and divides it into independent resource isolation units, configuring dedicated traffic quotas and sliding window flow state machines; the traffic quota includes the maximum QPS. and maximum concurrency ; The sliding window unit divides the timeline into sub-windows of fixed length based on the sliding window flow state machine, and aggregates the number of business requests within a preset time range by counting the sub-windows; The rate limiting policy management unit is used to allocate traffic quotas to each business resource group based on preset static rate limiting policies and dynamic adaptive rate limiting policies, and to generate an independent and exclusive traffic quota policy for each business resource group.

5. A flow control system based on parameter resource isolation according to claim 4, characterized in that: In the sliding window unit, the timeline is divided into sub-windows of fixed length based on the sliding window flow state machine. The number of service requests within a preset time range is aggregated through the counting of the sub-windows. Specifically: Set the length of the child window of the sliding window to The statistical time window is Then count the number of sub-windows contained within the time window. ; Set the request timestamp to Then the current child window corresponding to this request is: in, This is the system's initial timestamp. This is the floor function; The current child window; Set child window The number of business requests is Then the statistical time window Total number of service requests within The sum of the counts of the most recent N child windows is expressed as: like If the data usage is within the limit, it is considered that the data usage is within the limit; otherwise, it is considered that the data usage exceeds the limit. Extract the current concurrency count within the sliding window .

6. A flow control system based on parameter resource isolation according to claim 5, characterized in that: In the rate limiting policy management unit, the preset static rate limiting policy is a fixed traffic quota configured based on the parameter combination of the service resource group, including the maximum QPS. Maximum concurrency Then the static quota for this business resource group is , ; The preset dynamic adaptive rate limiting strategy allocates traffic quotas to each business resource group as follows: Collect core operational metrics for each business resource group, including business resource pool latency metrics. Error rate metrics and resource utilization rate indicators Generate an indicator set, denoted as ; The collected core operational indicators were normalized to... Specifically: Normalized value of business resource pool latency metric : in, This is the maximum allowable latency of the system; Error rate metric normalized value : in, The maximum error rate allowed by the system; Normalized value of resource utilization rate index : in, and This is the preset optimal interval. ; Adjustable weights are configured based on normalized business resource pool latency, error rate, and resource utilization metrics. , , The overall score of the business resource group The calculation expression is: in, ; Set the current total available bandwidth of the system to The current number of business resource groups is K, and the overall score of the k-th business resource group is Then the dynamic QPS quota for the kth business resource group for: Similarly, the dynamic quota for maximum concurrency. The final effective quota for this business resource group is obtained by allocating resources proportionally according to the above formula. , .

7. A flow control system based on parameter resource isolation according to claim 6, characterized in that: In the flow control execution module, the sliding window statistics result includes the number of requests in the sliding window. Current concurrency ; Traffic quotas include the real-time quota results for this business resource group. , ; Based on the traffic quota and sliding window statistics corresponding to the business resource group, differentiated traffic control operations are performed according to preset rules, specifically as follows: like and If sufficient resources are determined, the request is directly allowed to proceed to the backend service, and a normal response is returned after the request is processed. like or If resources are insufficient, a secondary decision is made. The secondary decision-making includes: If the system enables queue waiting, business requests will be placed in the waiting queue. If the resource is released within the timeout period, the request will be executed; otherwise, the business request will be rejected. If the system does not have queue waiting enabled, the business request will be rejected directly, and a rate limiting error response will be returned. If the business group member group is configured with a degradation policy, the degradation will be triggered and a degradation response will be returned.

8. A flow control method based on parameter resource isolation, applied to a flow control system based on parameter resource isolation as described in any one of claims 1-7, characterized in that: include: S1: Intercept business requests flowing into the target service, collect the raw data of the business requests, and encapsulate them into a request context; S2: Obtain the request context and extract the multi-dimensional key parameters required by the business resource group based on the preset parameter extraction rules, and generate a unique and fixed resource group identifier; S3: Binds an independent sliding window flow control state machine to each business resource group, and integrates static rate limiting strategies and dynamic adaptive rate limiting strategies to generate traffic quota strategies; S4: Obtain the sliding window statistics of the corresponding sliding window flow control state machine based on the resource group identifier of the business resource group, and obtain the corresponding traffic quota of the business resource group according to the traffic quota policy; S5: Based on the traffic quota and sliding window statistics of the business resource group, perform differentiated traffic control operations according to preset rules; S6: Based on a visual management interface and standardized API, it allows administrators to dynamically operate on configuration items.

Images