Permission-based interface current limiting method and device, equipment and storage medium

Abstract

The invention relates to the technical field of data security and the field of financial science and technology, and discloses a permission-based interface flow limiting method, which solves the problem of low efficiency caused by unified processing of all requests by obtaining accessed service interface information and screening out key access requests according to a preset interface path rule. Permission classification is performed based on service roles, account identifiers or user group information of the users, flow limiting management is further refined, and personalized flow limiting conditions are set for the users in different permission ranges. According to the flow limiting conditions, the system dynamically selects a proper flow control strategy, such as request frequency limitation and concurrent request number control, so that system resources are reasonably distributed. According to the method, the flow limiting strategy can be dynamically adjusted according to different permissions of the user, it is guaranteed that the high-permission user is not limited too much, meanwhile, the situation that malicious users cause too large pressure on the system through frequent requests is prevented, and the overall safety and stability of the system are improved.

Description

Technical Field

[0001] The present invention relates to the fields of data security technology and financial technology, and in particular to a permission-based interface current limiting method, device, equipment and storage medium. Background Art

[0002] In recent years, with the rapid development of network technology, the digital transformation of the financial industry has been accelerating, and network security issues have become increasingly prominent. In the financial system, data is highly mobile and open, and various transactions, reporting, insurance and other operations occur frequently, which makes the financial system face greater security risks and traffic management challenges.

[0003] First, the high-frequency transmission of financial transaction data makes the financial system a key target for hacker attacks. Users interact with back-end services through the front-end, especially in complex financial scenarios such as policy revisions and claims applications. Data transmission often involves multiple systems and service interfaces, which makes interface security and traffic management difficult. Traditional network protection measures focus more on data encryption and access control. However, in the case of high concurrent requests, how to prevent malicious requests while ensuring stable service operation has become a key challenge for financial systems.

[0004] Secondly, the risk of interface attacks is also one of the major security risks in the financial industry. The service interfaces in the financial system are exposed to external systems and users, through which users can operate or query services. However, these interfaces may be used maliciously. Attackers can illegally intercept or replay requests, forge transaction data or submit duplicate requests, thereby causing confusion in financial system data, increasing business risks, and even affecting system stability.

[0005] Faced with this situation, existing current limiting products on the market, such as Sentinel and Hytrix, provide current limiting and degradation functions for interface requests, mainly limiting the frequency of interface access through algorithms such as fixed windows and sliding windows. However, these existing technologies have obvious shortcomings:

[0006] Most of the current flow limiting products currently limit the flow of interfaces in a unified manner, and cannot be refined to the user permission level. This is particularly important in financial scenarios, because users with different permissions (such as VIP users and ordinary users) have different requirements for interface requests, and unified flow limiting is likely to affect the normal operations of high-privilege users.

[0007] Some flow-limiting products are highly invasive to business systems and require modification of business codes, which increases the complexity of system implementation and maintenance. For financial systems, which are business-sensitive and large-scale, frequent code modifications will bring additional risks and costs.

[0008] In summary, existing flow control technologies are unable to provide sufficiently refined flow control and security protection when facing the high concurrent requests and complex permission management in the financial industry. These deficiencies directly affect the security and stability of the financial system. Summary of the invention

[0009] The main purpose of the present invention is to provide a permission-based interface current limiting method, device, equipment and storage medium, aiming to solve the technical problem that existing current limiting products cannot be refined to the user permission level for management, and cannot set differentiated current limiting strategies according to the permissions of different users, resulting in too single current limiting processing of the interface, affecting the flexibility and security of business operations.

[0010] To achieve the above object, the present invention provides a permission-based interface current limiting method, comprising:

[0011] Obtain information about connected service interfaces and identify service interfaces that require current limiting management;

[0012] Obtain access requests for the service interface that needs to be current limited, and filter out key access requests according to a preset interface path;

[0013] According to the business role, account ID or user group of the access user corresponding to the key access request, the access user is classified by permission, and corresponding flow limiting conditions are set for access users with different permission ranges;

[0014] Based on the flow limiting conditions of the accessing user, determine the corresponding flow control strategy, wherein the flow control strategy is used to limit the key access requests of the accessing user;

[0015] The access requests of the service interface that needs to be managed by flow limiting are monitored, and when the key access requests of the access users meet the corresponding flow limiting conditions, the corresponding flow control strategy is executed.

[0016] Furthermore, to achieve the above object, the present invention provides a permission-based interface current limiting device, comprising:

[0017] The service interface identification module is used to obtain the information of the connected service interfaces and identify the service interfaces that need to be managed by current limiting;

[0018] An access request screening module is used to obtain access requests of the service interface that needs to be current limited and screen out key access requests according to a preset interface path;

[0019] The flow limiting condition configuration module is used to classify the access users according to their business roles, account IDs or user groups corresponding to key access requests, and set corresponding flow limiting conditions for access users with different permission ranges;

[0020] A flow control strategy module, used to determine a corresponding flow control strategy based on the flow limiting conditions of the accessing user, wherein the flow control strategy is used to limit the key access requests of the accessing user;

[0021] The flow monitoring and flow limiting module is used to monitor the access requests of the service interface that needs to be flow limited, and when the key access requests of the accessing users meet the corresponding flow limiting conditions, execute the corresponding flow control strategy.

[0022] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a computer device, which includes a memory, a processor, and a permission-based interface current limiting program stored in the memory and executable on the processor, wherein the permission-based interface current limiting program, when executed by the processor, implements the steps of the permission-based interface current limiting method as described above.

[0023] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a computer-readable storage medium, on which a permission-based interface current limiting program is stored, and when the permission-based interface current limiting program is executed by a processor, the steps of the permission-based interface current limiting method as described above are implemented.

[0024] Beneficial effects: The present invention relates to the fields of data security technology and financial technology, and discloses a permission-based interface current limiting method. By obtaining the information of the service interface that has been connected, the interface that needs current limiting management is determined, and the access request of the service interface is received, and the key access request is screened out according to the preset interface path rule. According to the user information corresponding to the key access request, the user is classified according to the dimensions such as business role, account identification or user group. Current limiting conditions are set based on different permission ranges, and corresponding flow control strategies are determined according to these conditions, such as request frequency limit, concurrent request number control or data transmission limit. The access request of the interface is monitored, and when it is found that the access request meets the current limiting condition, the flow control strategy is immediately executed. The present invention can dynamically adjust the current limiting strategy according to the different permissions of the user, ensure that the high-authority user is not subject to too many restrictions, and prevent malicious users from causing excessive pressure on the system through frequent requests. Refined current limiting management is realized, the flexibility and pertinence of flow control are enhanced, which can effectively prevent malicious attacks, ensure the normal business operation of high-authority users, and improve the overall security and stability of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] The present invention will be further described below with reference to the accompanying drawings and embodiments, in which:

[0026] Figure 1 A schematic diagram of an application environment of a permission-based interface current limiting method in an embodiment of the present invention;

[0027] Figure 2 This is a flow chart of an embodiment of a permission-based interface current limiting method of the present invention;

[0028] Figure 3 It is a functional module diagram of a preferred embodiment of the interface current limiting device based on authority of the present invention;

[0029] Figure 4 A schematic diagram of the structure of a computer device in one embodiment of the present invention;

[0030] Figure 5 FIG. 4 is another schematic diagram of the structure of a computer device in one embodiment of the present invention. DETAILED DESCRIPTION

[0031] It should be understood that the specific embodiments described herein are only used to explain the present invention, and are not used to limit the present invention.

[0032] The interface current limiting method based on permissions provided in the embodiment of the present invention can be applied in the following aspects: Figure 1 In an application environment, the user terminal communicates with the server terminal through a network. The server terminal can obtain the service interface information that has been accessed through the user terminal, determine the interface that needs flow control management, and receive the access request of the service interface, and filter out the key access request according to the preset interface path rule. According to the user information corresponding to the key access request, combined with dimensions such as business role, account identification or user group, the user is classified for authority. Based on different authority ranges, flow control conditions are set, and corresponding flow control strategies are determined according to these conditions, such as request frequency limit, concurrent request number control or data transmission limit. The access request of the monitoring interface is monitored, and when it is found that the access request meets the flow control condition, the flow control strategy is immediately executed. The present invention can dynamically adjust the flow control strategy according to the different permissions of the user, ensure that high-authority users are not subject to too many restrictions, and prevent malicious users from causing excessive pressure on the system through frequent requests. Refined flow control management is realized, the flexibility and pertinence of flow control are enhanced, which can effectively prevent malicious attacks, and ensure the normal business operation of high-authority users, thereby improving the overall security and stability of the system. Among them, the user terminal can be, but not limited to, various personal computers, laptops, smart phones, tablet computers and portable wearable devices. The server side can be implemented by an independent server or a server cluster composed of multiple servers. The present invention is described in detail below through specific embodiments.

[0033] See also Figure 2 , Figure 2 This is a flow chart of an embodiment of a permission-based interface current limiting method provided by the present invention. It should be noted that although a logical sequence is shown in the flow chart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0034] like Figure 2 As shown, the permission-based interface current limiting method proposed by the present invention includes the following steps:

[0035] S10, obtaining information of connected service interfaces and identifying service interfaces that require current limiting management;

[0036] In this embodiment, the service interface information currently running in the system is collected from multiple sources, including interface name, address, path, request method, etc. The source of the service interface information can be a configuration file, a service registry (such as Eureka, Consul, etc.), or a system database, which stores all running service interfaces and their metadata.

[0037] Access the service registry, or obtain detailed information about the service interface from the configuration file or database. For example, by calling the query interface of the service registry through the API, the system can obtain all registered services. You can also obtain relevant interface information by parsing the configuration file or querying the database.

[0038] From the service interfaces obtained, identify which interfaces are frequently accessed and have a potential impact on system performance, and determine whether current limiting is required. Current limiting management is usually applicable to interfaces open to the outside world or resource-intensive service interfaces.

[0039] The service interfaces that need to be limited can be determined by analyzing historical access logs, monitoring the real-time traffic data of the system, or based on business rules (such as the business importance of the interface, access frequency, etc.). The system can obtain the load data of the interface through real-time monitoring tools (such as Prometheus), and automatically identify the interfaces that need to be limited according to the set limiting conditions (such as the number of requests per second, the number of concurrent requests, etc.).

[0040] Example description: In the financial system, interfaces involving high concurrent requests, such as insurance application, policy inquiry, and claim application, are high-risk and high-load interfaces. The system obtains information on all financial service interfaces, monitors the request volume of key interfaces such as insurance transactions and claim services, and automatically identifies and manages high-traffic interfaces based on traffic trends. For example, during the peak insurance period, the request volume of the insurance application interface may increase dramatically. At this time, the system can prevent interface overload through current limiting management and ensure that requests from high-priority users (such as VIP customers) are processed in a timely manner.

[0041] Through the above steps, service interfaces that need to be limited can be automatically identified to prevent high concurrent requests or malicious requests from affecting system performance. By dynamically obtaining service interface information and flexibly identifying interfaces that need limited management based on traffic monitoring data and business rules, the stability of the system can be significantly improved and the risk of service unavailability due to overload can be reduced.

[0042] S20, obtaining access requests of the service interface that needs to be subject to current limiting management, and filtering out key access requests according to a preset interface path;

[0043] In this embodiment, access requests of service interfaces that have been identified as requiring flow control are obtained. These interfaces are usually high-frequency interfaces that consume large system resources, or interfaces that require special flow control in specific business scenarios.

[0044] The system can record and capture requests from these interfaces by setting the current limiting management flag on the API gateway, service proxy, or load balancer. Based on the current limiting flag, the system will filter and record the interface requests that meet the conditions to ensure that only the interface requests that require current limiting management are captured and processed later.

[0045] For the interface requests that have been obtained, the system filters out the key requests that meet the flow control management requirements according to the preset path rules. The screening conditions can include information such as interface path, request method (such as GET, POST), etc., in order to ensure that only requests that meet the rules are marked as key requests.

[0046] By configuring path matching rules, the system compares all captured requests one by one. Path matching can be based on regular expressions or string comparisons to filter out key requests that are consistent with preset rules and mark them as requests that need to be processed first or subject to flow control.

[0047] Example: In the financial system, interfaces involving high-frequency access, such as transaction processing and loan approval, are interfaces that require flow control management. Through the API gateway, the system can obtain requests from these interfaces and filter out key requests based on preset path rules (such as / api / loan / approval or / api / transaction / execute). During financial peak hours, flow control of these key requests can avoid excessive system load while ensuring the continuity and security of financial services.

[0048] By specifically acquiring and screening service interface requests that require flow control management, the system can efficiently identify and control key access requests, ensuring that flow control policies are only applied to required interfaces, avoiding interference with low-frequency requests or unimportant interfaces. This improves the utilization of system resources and effectively protects the stability of high-frequency call interfaces under high concurrency conditions, preventing system paralysis caused by interface overload.

[0049] S30, classifying the access users according to their business roles, account identifiers or user groups corresponding to the key access requests, and setting corresponding flow limiting conditions for access users with different permission ranges;

[0050] In this embodiment, the system first extracts the user's business role information from the key access request. The business role usually refers to the identity of the user in the system, such as administrator, ordinary user or VIP user, etc. By analyzing the user's business role, the system can set different flow limiting conditions according to the user's permission level.

[0051] When the system receives a critical access request, it calls the permission management module to obtain the business role information of the user corresponding to the request. Usually this information is stored in the user permission system. The system queries the role of the corresponding user through the interface and returns it to the current limiting module as the basis for setting the current limiting conditions.

[0052] The account ID refers to the unique identity of the user in the system, which can be a user ID, email address, or mobile phone number. The system further confirms the user's identity by extracting the account ID in the request and sets special flow control conditions for specific accounts.

[0053] When the system receives a critical access request, it first parses the user identification information in the request, usually extracting the account identification through the user authentication system or the authentication token in the request. Then, the system can configure personalized flow control policies for specific account users, such as special treatment for sensitive accounts (such as administrator accounts).

[0054] User groups are a collection of users in the system that are divided according to certain attributes (such as department, business type, consumption habits, etc.). The system can analyze user groups and set exclusive flow control conditions for users in different groups. The division of user groups helps to impose appropriate flow control on specific groups of people.

[0055] The system extracts the user ID or account information from the key access request and queries the group to which the user belongs by calling the user management system. Based on the attributes of the group, the system sets different flow limiting conditions. For example, a specific VIP customer group can enjoy fewer flow limiting restrictions.

[0056] Based on the business roles, account IDs or user groups analyzed above, the system sets differentiated flow limiting conditions for users with different permissions. The flow limiting conditions may include request frequency limits, concurrent request number limits, data size limits, etc.

[0057] The system dynamically generates corresponding flow control policies based on the permission classification results (business role, account ID or group information), such as setting loose request frequency limits for high-privilege users and strict flow control policies for low-privilege users. These flow control conditions will be directly applied to the processing of interface requests.

[0058] Example: In a financial system, users with different roles (such as administrators, financial advisors, and ordinary customers) have different business needs. The system can configure exclusive flow control strategies for different users by obtaining the user role or account ID in the key access request. For example, the administrator account should enjoy a higher request concurrency limit when performing account management and auditing, while ordinary customers are subject to relatively strict flow control management when submitting transactions or querying information. For VIP customers, the system can ensure that they receive priority service in high-concurrency scenarios by identifying their account or group information.

[0059] By combining the user's business role, account ID, and group information, the system can achieve refined flow control management for different user groups. It can effectively distinguish the needs of users with different permissions, ensure the normal operation of high-privilege users in high-concurrency scenarios, and impose stricter flow control policies on low-privilege users and ordinary users to prevent system resources from being abused. This not only improves the security of the system, but also optimizes the rational use of resources to ensure stable system operation.

[0060] S40, determining a corresponding flow control strategy based on the flow limiting condition of the access user, wherein the flow control strategy is used to limit the key access request of the access user;

[0061] In this embodiment, the system generates flow limiting conditions based on the access user's permission information (such as business role, account ID or user group), and the flow limiting conditions may include request frequency limit, concurrent request number limit, request data size limit, etc. This condition determines which specific restrictions the user's request behavior is subject to.

[0062] After receiving a critical access request, the system will first obtain the user's flow control conditions through the user rights management module. The flow control conditions can be set based on the user's role (such as administrator, VIP user), account identifier (such as sensitive account) or group attribute (such as high-value customer group). The system then generates flow control conditions based on the preset business rules and stores them in the flow control module.

[0063] The system selects the appropriate flow control strategy based on the user's flow limiting conditions. Flow control strategy refers to specific technical means or algorithms, such as fixed window, sliding window, token bucket, leaky bucket, etc., used to control the flow of requests.

[0064] After generating the flow control conditions, the system selects a flow control strategy based on business needs. For example, for users with a large number of concurrent requests, the system can select a token bucket mechanism to control concurrent requests; for users who send requests frequently, the sliding window mechanism can be used to limit the request frequency. These strategies are dynamically adjusted to ensure that user requests meet the preset flow control conditions.

[0065] The selected traffic control strategy will be applied to key requests of accessing users. Specific restrictions can be reflected in request frequency, number of concurrency or request data size, with the aim of preventing overload or malicious requests from putting pressure on the system.

[0066] The system uses the traffic control policy module to monitor the traffic of key access requests in real time. If a request exceeds the flow limit, the system will process it according to the policy, such as discarding the request, delaying processing, or returning an error prompt.

[0067] Example: In a financial system, when a user submits a loan application, transfer operation, or other key requests, the system sets different flow-limiting conditions based on the user's permissions (such as VIP customers, ordinary customers) and account ID. For VIP customers, the system can choose a token bucket mechanism to allow more concurrent requests; for ordinary customers, a sliding window mechanism can be set to limit the request frequency. If a user's requests frequently exceed the flow-limiting conditions, the system will automatically discard or delay processing the request, ensuring the stable operation of financial services in high-concurrency scenarios while avoiding excessive system load caused by malicious requests.

[0068] By selecting appropriate flow control strategies based on the flow limiting conditions of accessing users, the system can effectively control the request flow in high-concurrency scenarios and prevent the negative impact of user request overload on the system. Compared with the existing unified flow limiting method, the personalized flow control strategy based on user permissions can improve resource utilization efficiency while ensuring that the normal requests of high-privileged users are not affected. The system can dynamically adjust the flow control strategy to adapt to the needs of different business scenarios, improving the stability and security of the system.

[0069] S50, monitoring the access request of the service interface that needs to be managed by flow limiting, and executing the corresponding flow control strategy when the key access request of the access user meets the corresponding flow limiting condition.

[0070] In this embodiment, by monitoring the interface requests in the system in real time, all access traffic entering the system is captured, and the requests are monitored and recorded according to pre-set monitoring indicators (such as request frequency, concurrency, etc.).

[0071] The system can use monitoring tools (such as Prometheus, Grafana, ELK, etc.) to continuously monitor all incoming interface requests. By setting up traffic monitoring points on the API gateway, load balancer, or proxy server, the system can capture and analyze the path, method, parameters, and other information of each request.

[0072] During the monitoring process, the system will check whether the key requests of each accessing user meet the preset flow control conditions, such as the request frequency exceeds the flow control threshold, the number of concurrent requests exceeds the allowed flow control standard, etc. Requests that meet the flow control conditions will trigger subsequent flow control strategies.

[0073] The request flow of each user will be compared and verified according to the flow limiting conditions set in the system. The system will check whether the key requests of the user exceed the flow limiting conditions. The flow limiting conditions may be based on the number of requests, request interval time, data size, etc.

[0074] When a user's key access request exceeds the flow limit conditions, the system will automatically execute the flow control strategy to limit the user's request to prevent request overload. The flow control strategy may include delaying requests, discarding requests, returning error prompts, etc. to ensure that system resources are not exhausted due to excessive requests.

[0075] The system executes corresponding strategies through the flow control module. According to the user's flow limit conditions, the system can choose different processing methods, such as delaying the processing of requests that exceed the flow limit, discarding some requests, or directly returning an error response. This process is automatically completed by the flow control module to ensure that the system can remain stable in high-concurrency scenarios.

[0076] Example: In a financial system, users submit requests such as loan applications, transfer operations, account inquiries, etc. through interfaces. The system monitors the request frequency and concurrency of these interfaces in real time. Once a user's key access request exceeds the flow limit conditions, such as the frequency of submitted transfer requests is too high, the system will immediately execute the flow control strategy and reject or return an error message for requests that exceed the flow limit standards. This can prevent users from attacking the system by submitting requests frequently, ensure that financial services can operate stably and safely under high concurrency, and avoid the abuse of system resources by malicious requests.

[0077] By monitoring user interface requests in real time, the system can promptly detect and process key requests that exceed the flow limit conditions. The application of flow control strategies can effectively prevent the impact of high-frequency requests or excessive concurrent requests on system resources, and ensure the stable operation of the system in high-concurrency scenarios.

[0078] The present invention relates to the fields of data security technology and financial technology, and discloses a permission-based interface current limiting method, which obtains the information of the service interface that has been connected, determines the interface that needs current limiting management, receives the access request of the service interface, and screens out the key access request according to the preset interface path rule. According to the user information corresponding to the key access request, combined with the dimensions of business role, account identification or user group, the user is classified for authority. Current limiting conditions are set based on different authority ranges, and corresponding flow control strategies are determined according to these conditions, such as request frequency limit, concurrent request number control or data transmission limit. The access request of the interface is monitored, and when it is found that the access request meets the current limiting condition, the flow control strategy is immediately executed. The present invention can dynamically adjust the current limiting strategy according to the different permissions of the user, ensure that the high-authority user is not subject to too many restrictions, and prevent malicious users from causing excessive pressure on the system through frequent requests. Refined current limiting management is realized, the flexibility and pertinence of flow control are enhanced, malicious attacks can be effectively prevented, and the normal business operation of high-authority users is guaranteed, and the overall security and stability of the system are improved.

[0079] In one embodiment, the above S10 includes:

[0080] S101, obtaining the connected service interface information from the service registration center or configuration file, wherein the service interface information includes the service name, interface address, interface path and request method;

[0081] S102, classifying the service interfaces according to their business types, functional modules, and access frequencies;

[0082] S103, based on the classification result, determining the flow control management priority of the service interface, wherein the priority is used to determine the strictness of executing the flow control policy on the service interface;

[0083] S104, detecting the load of the service interface by monitoring the request frequency, concurrent request volume and resource occupancy of the service interface;

[0084] S105: Based on the load conditions of the service interfaces, mark the service interfaces that require current limiting management.

[0085] In this embodiment, all connected service interface information is obtained from the system's service registration center or configuration file to ensure that the system knows which services are currently running. The service interface information generally includes metadata such as service name, interface address, interface path, and request method.

[0086] In a system based on a microservice architecture, a service registry (such as Eureka, Consul, etc.) is used to store all registered services. The system can call these service registries through APIs to obtain relevant information about all service interfaces. In addition, the system can also directly read service interface data from configuration files (such as YAML, XML, etc.), which is particularly suitable for statically configured service architectures.

[0087] The system classifies the service interfaces by business type (such as financial transactions, data processing), functional module (such as user authentication, account management), and access frequency (high frequency, medium frequency, low frequency). This step helps the system identify which interfaces are key high-frequency access interfaces, so as to determine whether current limiting management needs to be applied.

[0088] The system reads the service interface metadata and classifies the service interface by type, functional module, and access frequency in combination with preset business rules or historical data analysis. For example, the system can count the access frequency of a certain interface based on historical request log data and classify and mark it. Through these classifications, the system can apply different current limiting strategies to different types of interfaces.

[0089] Based on the classification results, the flow control management priority of the service interface is determined. The priority is used to determine the strictness of the flow control strategy for each service interface. According to different priorities, the system sets a looser flow control strategy for high-priority interfaces and implements stricter flow restrictions for low-priority interfaces, ensuring that key interfaces can operate stably under high-load conditions and optimizing the efficiency of system resource usage.

[0090] The system sets different priorities for the classified service interfaces according to business needs or preset rules. Important business interfaces (such as financial transaction interfaces) are usually set to high priority, while secondary business interfaces are marked as low priority. The system can automatically generate the priority of current limiting management through the rule engine or configuration management system.

[0091] The system monitors the operating status of the service interface in real time, including request frequency, number of concurrent requests, and system resource usage (such as CPU, memory, network, etc.). Monitoring these indicators helps identify interfaces that may cause system performance bottlenecks.

[0092] The system can use monitoring tools (such as Prometheus, Grafana, ELK, etc.) to continuously track the operation of the service interface, capture and analyze the request frequency, concurrent request volume, and resource usage of the interface. The system can identify high-load service interfaces by regularly collecting this data and comparing it with the preset threshold.

[0093] Through real-time analysis of the service interface load, the system marks those service interfaces with excessive load that are likely to cause system performance bottlenecks as objects that require current limiting management.

[0094] When the system monitors that the request frequency or concurrency of certain service interfaces exceeds the preset threshold, the interface is automatically marked as an object that needs to be limited. The system can use the dynamic flow control management platform to control the flow of these marked interfaces in real time and adjust the flow control rules according to the actual traffic fluctuations.

[0095] Example: In financial systems, service interfaces such as account management, payment processing, and transaction execution usually require strict flow control. The system obtains information about these interfaces and classifies them according to access frequency and business importance. The payment processing interface is marked as high priority due to its core business nature and high-frequency requests. When its request frequency and concurrency exceed the threshold, the system automatically lists it as an object of flow control management to ensure its stable operation under high load. In contrast, the account management interface is marked as medium priority. When the traffic approaches the threshold, the system will appropriately limit its concurrent requests to prioritize the stability of high-priority interfaces. Low-priority interfaces such as transaction record query may be subject to stricter flow control management when the system load is high to ensure the continued stability of key businesses. Through this classification and differentiated flow control strategy, the system can reasonably allocate resources in high-concurrency scenarios to ensure the normal operation of key business interfaces.

[0096] This embodiment obtains service interface information from the service registration center or configuration file, and classifies it according to business type, functional module and access frequency, so that the system can more effectively identify interfaces that require current limiting management. By monitoring the load of the interface in real time, the system can dynamically mark and manage high-load interfaces to prevent interface overload from causing system performance degradation. This dynamic current limiting management can effectively improve system resource utilization and ensure the stability of the system in high-concurrency scenarios.

[0097] In one embodiment, the above S20 includes:

[0098] S201, extracting preset interface path information from a configuration file, a service registration center or a database, wherein the interface path information includes a static path template and a dynamic path template;

[0099] S202, parsing the interface path and request method in the access request, and matching and verifying with the preset interface path information and the corresponding request method;

[0100] S203: According to the result of the matching verification, an access request that meets the preset interface path information and request method is identified and marked as a critical access request.

[0101] In this embodiment, the system needs to extract interface path information from predefined data sources, which can be configuration files, service registration centers or databases. Interface path information usually includes static paths (such as fixed URLs) and dynamic path templates (URLs with variable parameters).

[0102] The system can extract all registered interface paths from the service registry or database through API or scheduled tasks. For configuration file-based solutions, the system will parse static configuration files (such as YAML, JSON), read the path information and load it into memory for subsequent request matching.

[0103] After receiving an access request, the system needs to parse the request path (such as URL) and request method (such as GET, POST, etc.) in order to compare them with the preset interface path information.

[0104] The system extracts the interface path information by accessing the header and path fields of the request and identifies the HTTP method of the request. The parsed path and method will be used as key parameters for subsequent matching verification.

[0105] The system compares the parsed access request information with the preset interface path and request method one by one to ensure that the request path and method are consistent with the predefined rules.

[0106] The system uses regular expressions or string matching algorithms to compare the path in the access request with the preset static or dynamic path template. If the request path completely matches the preset path template, the system further checks whether the request method meets the preset requirements.

[0107] If the request path and method are verified to be consistent with the preset information, the system marks the request as a critical access request to facilitate the application of subsequent traffic control policies.

[0108] Once the match verification is passed, the system will mark the request as a "critical request" and store it in a temporary cache or database as a basis for subsequent traffic control and priority processing. The system can also monitor and count these critical requests to evaluate traffic conditions.

[0109] Example: In a financial system, service interfaces such as user account query, transaction execution, and payment processing are frequently accessed interfaces that have a critical impact on the business. The system obtains the path information of these interfaces from the service registration center or configuration file, including static paths (such as / api / transaction / execute) and dynamic paths (such as / api / user / {id} / balance).

[0110] When a user initiates a request, the system will parse the request path and request method (such as POST or GET), and match and verify it with the preset interface path and method. For example, when a user initiates an account balance query request, the system parses the path / api / user / 123 / balance and matches it with the dynamic path template / api / user / {id} / balance. If the path and method are consistent, the system will mark the request as a critical access request.

[0111] During financial peak periods, such as promotional activities or transaction settlement peaks, the system can prioritize these critical requests to ensure that payment processing and transaction execution are prioritized and reduce the risk of system overload. In addition, the system can collect statistics and monitor these critical requests to further optimize traffic control strategies and ensure the continuous and stable operation of financial services.

[0112] This embodiment extracts interface path information from different data sources and matches and verifies the paths and methods of access requests, so that the system can efficiently identify key access requests. This screening mechanism can help the system centrally process high-priority requests, reduce resource consumption for ordinary requests, optimize system performance and resource utilization, and ensure the stability and response speed of key business interfaces, especially in high-concurrency scenarios.

[0113] In one embodiment, the above S30 includes:

[0114] S301, extracting the user ID of the current access user, the user ID is used to match with the crowd package ID;

[0115] S302, matching the user ID with the crowd package ID through the big data platform, where the crowd package is a characteristic user group divided based on big data analysis;

[0116] S303, determining whether the accessing user belongs to a predefined characterized user group according to the matching result between the user ID and the crowd package ID;

[0117] S304: if the access user belongs to a characterized user group, classify the access user according to the access user's characteristics and set corresponding flow limiting conditions, which include request frequency limit, concurrent request number limit and request data size limit;

[0118] S305: If the accessing user does not belong to the characterized user group, a preset default flow limiting condition is set.

[0119] In this embodiment, when a key access request is received, the system extracts the user ID corresponding to the request. The user ID is a unique identifier for each user in the system and is used to determine the identity of the user. The user ID will then be matched with the crowd package ID to determine whether the user belongs to a specific user group. The user ID may be used as a key field to associate with other modules in the system (such as big data analysis, risk control system, etc.). For example, through the user ID, the system can associate the user's financial data, transaction records, etc. with the flow control management system to help make more accurate flow control decisions.

[0120] In addition, the system associates the user ID with the permission system to determine the user's role and permission scope, thereby determining the user's access rights and operation rights in the system. The user ID not only represents the user's identity, but is also used to divide the user's permission level, such as administrator, ordinary user or VIP user. The system tracks the user's operation records, access frequency and request history through the user ID. Through these behavioral data, the system can further analyze the user's behavior pattern and then determine the user's characteristics or belonging group, such as high-frequency trading users, low-activity users, etc.

[0121] Through the user ID, the system can aggregate the user's behavior data for big data analysis, and then provide personalized flow control conditions, recommended services or risk warnings. The user ID is not only an identifier of the identity, but also the key data for the system to make intelligent decisions and analysis.

[0122] The system obtains the user ID by parsing the authentication information in the access request (such as JWT token, Session ID, etc.) or directly through the API gateway. The user ID is then used in subsequent matching operations to further identify the user.

[0123] The system matches the user ID with the crowd package ID through the big data platform. A crowd package is a collection of specific users, usually divided based on user behavior, consumption habits and other characteristics through big data analysis. The purpose of matching is to determine whether the user belongs to a specific user group, such as VIP users, high-risk users, etc.

[0124] The system calls the interface of the big data platform, inputs the user ID and performs matching operations. The big data platform pre-groups users through data analysis tools (such as Hadoop and Spark), and divides these groups into different population packages. The system compares the user ID with the population package ID to determine whether the user belongs to a specific group.

[0125] Based on the matching results of the big data platform, the system determines whether the user belongs to a specific user group, such as a high-value customer group, a frequent transaction group, etc. If the user belongs to a specific group, the system can set more appropriate flow limiting conditions for it.

[0126] The matching results are returned to the system through the API, and the system determines the user's category based on the results. If the match is successful, the system marks the user as part of a specific user group and executes subsequent flow control strategies.

[0127] The system determines the user's permission range and corresponding flow control conditions based on the matched user group attributes. For example, VIP users may have a higher request frequency limit, while ordinary users or high-risk users may be subject to stricter flow control restrictions.

[0128] The system uses the current limiting rule engine to set current limiting conditions for specific user groups. Specific current limiting conditions may include request frequency, number of concurrent requests, request data size, etc. The rule engine will dynamically generate applicable current limiting strategies based on the characteristics of the user group.

[0129] For ordinary users who do not belong to a specific group, the system will apply the default rate limiting conditions. The default rate limiting conditions are suitable for most ordinary users and ensure that the request processing of all users can be balanced when resources are tight.

[0130] The system sets predefined throttling policies for users who are not matched to a specific group. These policies are usually more general, such as moderate request frequency limits and concurrent number limits to ensure that system resources are not over-consumed by low-priority users.

[0131] Example: In the financial system, users such as VIP customers, frequent trading customers, and ordinary users have different behavioral characteristics. The system extracts the user ID and uses the big data platform to match the group to which the user belongs, such as high-frequency trading users or high-net-worth customers. For the matched VIP users, the system sets more relaxed flow limiting conditions for them, such as higher request frequency or concurrent number limit, to ensure that their transaction requests are processed first. For ordinary users, the default flow limiting conditions apply, such as lower concurrent request limits, to ensure that the financial system can still operate stably during high concurrent trading periods.

[0132] In this embodiment, the system can achieve accurate flow control management by combining user ID and the population packages divided by the big data platform. Characteristic user group classification and targeted flow control condition setting can ensure that high-value users receive priority services while preventing low-priority users from occupying too much system resources. This dynamic and intelligent flow control strategy improves the resource utilization efficiency of the system and optimizes the user experience, especially in high-concurrency scenarios, which can effectively ensure the stable operation of the system.

[0133] In one embodiment, the above S30 includes:

[0134] S306, determining the business role information of the access user corresponding to the key access request, where the business role information includes administrator, VIP user, common user and guest user;

[0135] S307, based on the business role information, classifying the access users into a high authority category, a medium authority category, a general authority category, and a low authority category;

[0136] S308, setting a flow limiting condition without request frequency limit for access users of high authority categories;

[0137] S309, setting a flow limiting condition of a first preset request frequency for access users of the medium authority category;

[0138] S310, setting a flow limiting condition of a second preset request frequency for an access user with general authority, where the second preset request frequency is less than the first preset request frequency;

[0139] S311, setting a flow limiting condition of a third preset request frequency for access users of a low authority category, wherein the third preset request frequency is less than the second preset request frequency.

[0140] In this embodiment, when the system processes a key access request, it needs to extract the user business role information corresponding to the request. Business roles generally include administrators, VIP users, ordinary users, and guest users, and different roles have different permission levels.

[0141] The system obtains the user's business role information from the permission management module by parsing the user identity information in the access request (such as Session, Token or other authentication mechanisms). The role information is stored in the permission database, and the system can extract relevant information through API or query mechanism.

[0142] Based on the extracted business role information, the system divides users into different permission categories. These categories are used to distinguish the priorities of users. For example, users in high permission categories are usually administrators or VIP users, while users in low permission categories may be visitors.

[0143] The system divides permissions based on business role information, which can be achieved through a preset rule engine. For example, the rules for high-permission categories include administrators and VIP users, the medium-permission category corresponds to ordinary users, and visitors are classified as low-permission categories. After the permissions are divided, the system classifies users into different permission ranges to facilitate the application of subsequent flow control strategies.

[0144] Users of high-privilege categories (such as administrators or VIP users) usually have higher access requirements for system resources, so the system sets loose rate limiting conditions for these users, allowing them to be unrestricted in request frequency.

[0145] The system uses the current limiting management module to set loose request frequency limits for high-privileged users, or completely remove the request frequency limits. The current limiting management module automatically applies these settings based on the user's permission category to ensure that the operations of high-privileged users are not affected by frequent request limits.

[0146] Although medium-privilege users (such as ordinary users) do not have the high priority of administrators and VIP users, they still need certain system resources. Therefore, more relaxed flow limiting conditions are set for them, but they are restricted compared to high-privilege users.

[0147] The system sets the first preset flow limiting condition for users in the medium-level permission category. This condition is usually more relaxed, but it controls the request frequency. For example, the system limits the maximum number of requests per second for these users to ensure that system resources are not over-occupied while ensuring a relatively smooth user experience.

[0148] The access frequency limit for ordinary privilege users is relatively strict, and the current limiting conditions set by the system for them are lower than those for medium privilege users, ensuring that the requests of ordinary users will not affect the overall performance of the system.

[0149] The system sets a second preset flow limiting condition based on the role of ordinary users, which limits the maximum request frequency and concurrency of users. This setting ensures that ordinary users' requests will not affect high-priority users.

[0150] Low-privilege users, such as guest users, have low access requirements to the system. The system sets the most stringent flow limiting conditions for them, limits their request frequency, and ensures that the operations of the core user group are not affected.

[0151] The system sets a third preset flow-limiting condition for low-privileged users (guests). This condition is usually stricter and limits the number of requests per second and the amount of concurrent requests, ensuring that system resources are used first to process requests from high-privileged users.

[0152] In this embodiment, by combining the user's business role information, the system can classify users according to their authority levels and assign different flow limiting conditions to them. High-authority users can enjoy higher system resource guarantees, while ordinary users and low-authority users are subject to certain restrictions, ensuring that the system gives priority to serving core users in high-concurrency scenarios.

[0153] In one embodiment, the above S30 includes:

[0154] S312, extracting account identification information of the accessing user, where the account identification information includes a corporate account, a personal account, and a sensitive account;

[0155] S313, determining the account category of the accessing user based on the account identification information, and judging whether the accessing user is a sensitive account;

[0156] S314, if the accessing user is a sensitive account, the accessing user is classified as an unauthorized category, and a flow limiting condition of prohibiting access is set for the range of users in the unauthorized category;

[0157] S315, if the accessing user does not belong to a sensitive account, a first preset concurrent request number flow limiting condition is set for the accessing user of the enterprise account, and a second preset concurrent request number flow limiting condition is set for the accessing user of the personal account, and the second preset concurrent request number is less than the first preset concurrent request number.

[0158] In this embodiment, the system extracts the user's account identification information from the access request. Account identification is usually used to distinguish the types of users, including corporate accounts, personal accounts, and sensitive accounts. Sensitive accounts usually refer to high-risk accounts that may require special treatment due to security or business rules.

[0159] The system obtains the user's account ID through the authentication token, Session or other login information of the access request. The account ID is stored in the user database, and the system can extract the user's account type by querying the database or permission system.

[0160] Based on the account ID, the system determines the user's account category, which is mainly divided into corporate accounts, personal accounts and sensitive accounts. Sensitive accounts may refer to accounts related to system security or business sensitivity, such as system administrators, important customer accounts, etc.

[0161] The system classifies user accounts through the rule engine or preset classification logic. The system will check whether the account meets the conditions of sensitive accounts, such as high-frequency operations, abnormal activity records, etc., and automatically determine whether the user is a sensitive account.

[0162] If a user is identified as a sensitive account, the system will classify it as unauthorized and impose strict flow control conditions on it, or even prohibit its access. This measure is intended to prevent high-risk or abnormal accounts from excessively accessing the system, leading to potential security risks.

[0163] Based on the judgment results of sensitive accounts, the system applies the current limiting management module to impose strict restrictions on the access requests of these accounts, usually including prohibiting access or significantly limiting their request frequency and number of concurrent requests. Such current limiting conditions can be configured through the rule engine.

[0164] For non-sensitive enterprise accounts, the system sets a higher concurrent request limit for them. Enterprise accounts usually involve large business volumes, so the system allows these users to execute more requests under high concurrency.

[0165] The system sets a higher upper limit on the number of concurrent requests for enterprise account users through the current limiting module to ensure that enterprise users can perform large-scale business operations. The current limiting condition is automatically configured based on the business needs of the enterprise account and the system capacity.

[0166] Users with personal accounts usually have lower system resource requirements than corporate accounts. Therefore, the system sets a lower concurrent request limit for personal users to prevent personal user requests from affecting system performance.

[0167] The system sets a second preset concurrent request limit for individual users, which is lower than the current limit for enterprise users. The current limit module automatically applies these settings for individual users through the rule engine to ensure that resources are properly allocated and prevent low-priority users from occupying too many resources.

[0168] This embodiment distinguishes user types based on account identification information and sets different current limiting conditions for different types of accounts, so that the system can effectively manage resource allocation. For sensitive accounts, the system takes strict restrictive measures to prevent potential security threats, while for corporate accounts, the system allows a higher number of concurrent requests to ensure normal operation of corporate users in high-concurrency scenarios. The current limiting conditions for personal accounts are relatively low, which can prevent low-priority users from over-consuming system resources.

[0169] In one embodiment, in the above S40, after generating the comprehensive data set, the following step is further included:

[0170] S401, based on the flow limiting condition of the access user, determining a corresponding flow control strategy, including:

[0171] S402, determining the current limiting conditions of the accessing user, wherein the current limiting conditions include request frequency limit, concurrent request number limit and request data size limit;

[0172] S403, when the flow limiting condition is request frequency limiting, selecting a fixed window mechanism or a sliding window mechanism as a flow control strategy;

[0173] S404, when the flow limiting condition is the number of concurrent requests, select a token bucket mechanism or a leaky bucket mechanism as a flow control strategy;

[0174] S405: When the flow limiting condition is the request data size limit, a fixed rate transmission mechanism or a segment processing mechanism is selected as a flow control strategy.

[0175] In this embodiment, the system determines the applicable flow limiting conditions based on the user's business role, account ID or other attributes. The flow limiting conditions may include three aspects: request frequency limit (number of requests per second), concurrent request limit (number of requests made simultaneously) and request data size limit (data transfer volume for a single request).

[0176] The system dynamically generates corresponding flow limiting conditions for each user based on the user's permissions and activity frequency through the rule engine or preset strategies. For example, the system will set a higher request frequency limit for high-frequency trading users and a lower concurrent request limit for ordinary users.

[0177] When the system determines that the user's flow control condition is the request frequency limit, the system will select an appropriate flow control strategy. The fixed window mechanism calculates the number of requests within a fixed time window, while the sliding window mechanism provides more refined control, real-time monitoring and adjustment of the request frequency.

[0178] The system can choose a fixed window or sliding window mechanism based on the user's actual request frequency and current limiting requirements. The fixed window mechanism is suitable for relatively stable request frequencies, while the sliding window mechanism is suitable for frequently changing request scenarios, ensuring that the system can accurately control requests in each time period.

[0179] If the system sets a flow control condition for users based on the number of concurrent requests, the token bucket mechanism or leaky bucket mechanism is used for flow control. The token bucket mechanism allows users to send concurrent requests in a more flexible way, while the leaky bucket mechanism maintains a stable request processing rate.

[0180] The system selects the corresponding mechanism based on the number of concurrent requests from users. The token bucket mechanism is suitable for scenarios that require a certain burst request capacity, allowing users to accumulate request tokens within a certain period of time; the leaky bucket mechanism strictly controls the request rate and is suitable for scenarios that require smooth traffic.

[0181] If the user's flow limiting condition involves the size of the requested data, the system will select an appropriate strategy to control the data transmission rate. The fixed-rate transmission mechanism controls the flow by limiting the data transmission rate, while the segmented processing mechanism divides large data requests into multiple small segments to reduce the instantaneous pressure on the system.

[0182] The system selects a fixed rate or segmented processing mechanism based on the size of the user's requested data. Fixed rate transmission is suitable for scenarios where small data is continuously transmitted, while segmented processing is suitable for processing larger data requests, ensuring that the system can smoothly handle large data transmissions during traffic peaks.

[0183] This embodiment selects different flow control strategies according to the flow limiting conditions of the accessing user, so that the system can flexibly respond to different types of request scenarios, ensuring that the system can still run smoothly under high concurrency and large data transmission conditions. The control of request frequency, number of concurrent requests and data size enables the effective allocation of system resources, avoids individual users occupying too many system resources, and ensures the overall stability and efficiency of the system.

[0184] In one embodiment, a permission-based interface current limiting device is provided, and the permission-based interface current limiting device corresponds one-to-one to the permission-based interface current limiting method in the above embodiment. Figure 3 , Figure 3 This is a functional module diagram of a preferred embodiment of the interface current limiting device based on permissions of the present invention. Service interface identification module 10, access request screening module 20, current limiting condition configuration module 30, flow control strategy module 40 and flow monitoring and current limiting module 50. The functional modules are described in detail as follows:

[0185] The service interface identification module 10 is used to obtain information about the connected service interfaces and identify the service interfaces that need to be managed by current limiting;

[0186] An access request screening module 20 is used to obtain access requests of the service interface that needs to be managed by current limiting, and screen out key access requests according to a preset interface path;

[0187] The flow limiting condition configuration module 30 is used to classify the access users according to the business role, account ID or user group of the access users corresponding to the key access requests, and set corresponding flow limiting conditions for access users with different permission ranges;

[0188] A flow control strategy module 40, used to determine a corresponding flow control strategy based on the flow limiting conditions of the accessing user, wherein the flow control strategy is used to limit the key access requests of the accessing user;

[0189] The flow monitoring and flow limiting module 50 is used to monitor the access requests of the service interface that needs to be flow limited, and when the key access request of the access user meets the corresponding flow limiting condition, execute the corresponding flow control strategy.

[0190] In one embodiment, the service interface identification module 10 is specifically used for:

[0191] Obtaining the connected service interface information from the service registration center or configuration file, wherein the service interface information includes the service name, interface address, interface path and request method;

[0192] Classify service interfaces according to their business type, functional module, and access frequency;

[0193] Based on the classification result, determine the flow control management priority of the service interface, where the priority is used to determine the strictness of executing the flow control policy on the service interface;

[0194] Detect the load of the service interface by monitoring the request frequency, concurrent request volume and resource usage of the service interface;

[0195] Based on the load of the service interface, mark the service interface that needs current limiting management.

[0196] In one embodiment, the access request screening module 20 is specifically configured to:

[0197] Extracting preset interface path information from a configuration file, a service registration center or a database, wherein the interface path information includes a static path template and a dynamic path template;

[0198] Parse the interface path and request method in the access request, and match and verify with the preset interface path information and the corresponding request method;

[0199] According to the matching verification results, access requests that meet the preset interface path information and request methods are identified and marked as critical access requests.

[0200] In one embodiment, the current limiting condition configuration module 30 is specifically used to:

[0201] Extract the user ID of the current access user, which is used to match the crowd package ID;

[0202] Matching user IDs with crowd package IDs through a big data platform, where the crowd package is a characterized user group divided based on big data analysis;

[0203] According to the matching result between the user ID and the crowd package ID, determine whether the accessing user belongs to the predefined characteristic user group;

[0204] If the access user belongs to a characterized user group, the access user is classified according to the access user's characteristics, and corresponding flow limiting conditions are set, including request frequency limit, concurrent request number limit and request data size limit;

[0205] If the accessing user does not belong to the characterized user group, the preset default flow limiting condition is set.

[0206] In one embodiment, the current limiting condition configuration module 30 is specifically used to:

[0207] Determine the business role information of the access user corresponding to the key access request, wherein the business role information includes administrator, VIP user, ordinary user and guest user;

[0208] Based on the business role information, the access users are divided into a high-authority category, a medium-authority category, a general-authority category, and a low-authority category;

[0209] Set a flow-limiting condition without request frequency limit for high-authority access users;

[0210] Setting a flow limiting condition of a first preset request frequency for access users of the medium authority category;

[0211] Setting a current limiting condition of a second preset request frequency for access users with general permissions, where the second preset request frequency is less than the first preset request frequency;

[0212] A current limiting condition of a third preset request frequency is set for access users of a low authority category, where the third preset request frequency is less than the second preset request frequency.

[0213] In one embodiment, the current limiting condition configuration module 30 is specifically used to:

[0214] Extracting account identification information of accessing users, wherein the account identification information includes corporate accounts, personal accounts, and sensitive accounts;

[0215] Determine the account category of the accessing user based on the account identification information, and judge whether the accessing user is a sensitive account;

[0216] If the access user is a sensitive account, the access user will be classified as unauthorized, and a flow restriction condition will be set for the unauthorized user to prohibit access;

[0217] If the accessing user does not belong to a sensitive account, a first preset concurrent request number limiting condition is set for the accessing user of the enterprise account, and a second preset concurrent request number limiting condition is set for the accessing user of the personal account, and the second preset concurrent request number is smaller than the first preset concurrent request number.

[0218] In one embodiment, the flow control strategy module 40 is specifically configured to:

[0219] Determine the current limiting conditions for access users, wherein the current limiting conditions include request frequency limit, concurrent request number limit and request data size limit;

[0220] When the flow limiting condition is request frequency limit, select fixed window mechanism or sliding window mechanism as the flow control strategy;

[0221] When the flow limiting condition is the number of concurrent requests, select the token bucket mechanism or leaky bucket mechanism as the flow control strategy;

[0222] When the flow limiting condition is the request data size limit, a fixed rate transmission mechanism or a segmented processing mechanism is selected as the flow control strategy.

[0223] In one embodiment, a computer device is provided. The computer device may be a server, and its internal structure diagram may be as follows: Figure 4 As shown. The computer device includes a processor, a memory, a network interface and a database connected via a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile and / or volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external user terminal through a network connection. When the computer program is executed by the processor, it implements the functions or steps of a permission-based interface current limiting method service side.

[0224] In one embodiment, a computer device is provided. The computer device may be a user terminal, and its internal structure diagram may be as follows: Figure 5 As shown. The computer device includes a processor, a memory, a network interface, a display screen and an input device connected through a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external server through a network connection. When the computer program is executed by the processor, it implements the functions or steps of a user-side method of interface current limiting based on permissions

[0225] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the following steps when executing the computer program:

[0226] Obtain information about connected service interfaces and identify service interfaces that require current limiting management;

[0227] Obtain access requests for the service interface that needs to be current limited, and filter out key access requests according to a preset interface path;

[0228] According to the business role, account ID or user group of the access user corresponding to the key access request, the access user is classified by permission, and corresponding flow limiting conditions are set for access users with different permission ranges;

[0229] Based on the flow limiting conditions of the accessing user, determine the corresponding flow control strategy, wherein the flow control strategy is used to limit the key access requests of the accessing user;

[0230] The access requests of the service interface that needs to be managed by flow limiting are monitored, and when the key access requests of the access users meet the corresponding flow limiting conditions, the corresponding flow control strategy is executed.

[0231] In one embodiment, a computer readable storage medium is provided, on which a computer program is stored, and when the computer program is executed by a processor, the following steps are implemented:

[0232] Obtain information about connected service interfaces and identify service interfaces that require current limiting management;

[0233] Obtain access requests for the service interface that needs to be current limited, and filter out key access requests according to a preset interface path;

[0234] According to the business role, account ID or user group of the access user corresponding to the key access request, the access user is classified by permission, and corresponding flow limiting conditions are set for access users with different permission ranges;

[0235] Based on the flow limiting conditions of the accessing user, determine the corresponding flow control strategy, wherein the flow control strategy is used to limit the key access requests of the accessing user;

[0236] The access requests of the service interface that needs to be managed by flow limiting are monitored, and when the key access requests of the access users meet the corresponding flow limiting conditions, the corresponding flow control strategy is executed.

[0237] It should be noted that the above functions or steps that can be implemented by the computer-readable storage medium or computer device can refer to the relevant descriptions on the server side and the user side in the aforementioned method embodiment. To avoid repetition, they will not be described one by one here.

[0238] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0239] Those skilled in the art can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0240] It should be noted that if software tools or components other than those of the Company appear in the embodiments of the present application, they are only used for illustration and do not represent actual use. The above-described embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit them; although the present invention has been described in detail with reference to the above-mentioned embodiments, a person of ordinary skill in the art should understand that the technical solutions described in the above-mentioned embodiments can still be modified, or some of the technical features thereof can be replaced by equivalents; and these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included in the protection scope of the present invention.

Claims

1. A permission-based interface current limiting method, characterized in that: The following steps are involved: Obtain information about connected service interfaces and identify service interfaces that require current limiting management; Obtain access requests for the service interface that needs to be current limited, and filter out key access requests according to a preset interface path; According to the business role, account ID or user group of the access user corresponding to the key access request, the access user is classified by permission, and corresponding flow limiting conditions are set for access users with different permission ranges; Based on the flow limiting conditions of the accessing user, determine the corresponding flow control strategy, wherein the flow control strategy is used to limit the key access requests of the accessing user; The access requests of the service interface that needs to be managed by flow limiting are monitored, and when the key access requests of the access users meet the corresponding flow limiting conditions, the corresponding flow control strategy is executed.

2. The permission-based interface current limiting method according to claim 1, characterized in that: Obtain information about connected service interfaces and identify service interfaces that require current limiting management, including: Obtaining the connected service interface information from the service registration center or configuration file, wherein the service interface information includes the service name, interface address, interface path and request method; Classify service interfaces according to their business type, functional module, and access frequency; Based on the classification result, determine the flow control management priority of the service interface, where the priority is used to determine the strictness of executing the flow control policy on the service interface; Detect the load of the service interface by monitoring the request frequency, concurrent request volume and resource usage of the service interface; Based on the load of the service interface, mark the service interface that needs current limiting management.

3. The permission-based interface current limiting method as described in claim 1, characterized in that: Obtain access requests for the service interface that needs to be managed by current limiting, and filter out key access requests according to a preset interface path, including: Extracting preset interface path information from a configuration file, a service registration center or a database, wherein the interface path information includes a static path template and a dynamic path template; Parse the interface path and request method in the access request, and match and verify with the preset interface path information and the corresponding request method; According to the matching verification results, access requests that meet the preset interface path information and request methods are identified and marked as critical access requests.

4. The method for limiting interface current based on permissions according to claim 1, characterized in that: According to the business role, account ID or user group of the access user corresponding to the key access request, the access user is classified by permission, and corresponding flow limiting conditions are set for access users with different permission ranges, including: Extract the user ID of the current access user, which is used to match the crowd package ID; Matching user IDs with crowd package IDs through a big data platform, where the crowd package is a characterized user group divided based on big data analysis; According to the matching result between the user ID and the crowd package ID, determine whether the accessing user belongs to the predefined characteristic user group; If the access user belongs to a characterized user group, the access user is classified according to the access user's characteristics, and corresponding flow limiting conditions are set, including request frequency limit, concurrent request number limit and request data size limit; If the accessing user does not belong to the characterized user group, the preset default flow limiting condition is set.

5. The permission-based interface current limiting method according to claim 1, characterized in that: According to the business role, account ID or user group of the access user corresponding to the key access request, the access user is classified by permission, and corresponding flow limiting conditions are set for access users with different permission ranges, including: Determine the business role information of the access user corresponding to the key access request, wherein the business role information includes administrator, VIP user, ordinary user and guest user; Based on the business role information, the access users are divided into a high-authority category, a medium-authority category, a general-authority category, and a low-authority category; Set a flow-limiting condition without request frequency limit for high-authority access users; Setting a flow limiting condition of a first preset request frequency for access users of the medium authority category; Setting a current limiting condition of a second preset request frequency for access users with general permissions, where the second preset request frequency is less than the first preset request frequency; A current limiting condition of a third preset request frequency is set for access users of a low authority category, where the third preset request frequency is less than the second preset request frequency.

6. The permission-based interface current limiting method according to claim 1, characterized in that: According to the business role, account ID or user group of the access user corresponding to the key access request, the access user is classified by permission, and corresponding flow limiting conditions are set for access users with different permission ranges, including: Extracting account identification information of accessing users, wherein the account identification information includes corporate accounts, personal accounts, and sensitive accounts; Determine the account category of the accessing user based on the account identification information, and judge whether the accessing user is a sensitive account; If the access user is a sensitive account, the access user will be classified as unauthorized, and a flow restriction condition will be set for the unauthorized user to prohibit access; If the accessing user does not belong to a sensitive account, a first preset concurrent request number limiting condition is set for the accessing user of the enterprise account, and a second preset concurrent request number limiting condition is set for the accessing user of the personal account, and the second preset concurrent request number is smaller than the first preset concurrent request number.

7. The permission-based interface current limiting method according to claim 1, characterized in that: Based on the access user's flow limiting conditions, determine the corresponding flow control strategy, including: Determine the current limiting conditions for access users, wherein the current limiting conditions include request frequency limit, concurrent request number limit and request data size limit; When the flow limiting condition is request frequency limit, select fixed window mechanism or sliding window mechanism as the flow control strategy; When the flow limiting condition is the number of concurrent requests, select the token bucket mechanism or leaky bucket mechanism as the flow control strategy; When the flow limiting condition is the request data size limit, a fixed rate transmission mechanism or a segmented processing mechanism is selected as the flow control strategy.

8. A permission-based interface current limiting device, characterized in that: The permission-based interface current limiting device includes: The service interface identification module is used to obtain the information of the connected service interfaces and identify the service interfaces that need to be managed by current limiting; An access request screening module is used to obtain access requests of the service interface that needs to be current limited and screen out key access requests according to a preset interface path; The flow limiting condition configuration module is used to classify the access users according to their business roles, account IDs or user groups corresponding to key access requests, and set corresponding flow limiting conditions for access users with different permission ranges; A flow control strategy module, used to determine a corresponding flow control strategy based on the flow limiting conditions of the accessing user, wherein the flow control strategy is used to limit the key access requests of the accessing user; The flow monitoring and flow limiting module is used to monitor the access requests of the service interface that needs to be flow limited, and when the key access requests of the accessing users meet the corresponding flow limiting conditions, execute the corresponding flow control strategy.

9. A computer device, characterized in that: The computer device includes a memory, a processor, and a permission-based interface current limiting program stored in the memory and executable on the processor. When the permission-based interface current limiting program is executed by the processor, the steps of the permission-based interface current limiting method as described in any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium, characterized in that: The storage medium stores a permission-based interface current limiting program, and when the permission-based interface current limiting program is executed by the processor, the steps of the permission-based interface current limiting method according to any one of claims 1 to 7 are implemented.

Images