Methods, devices, equipment, and storage media for flow control of interface requests

Abstract

This invention relates to the fields of computer science and digital healthcare, and discloses a method for traffic control of interface requests. The method includes: obtaining a traffic control region covered by a test project; defining a scanning range for a traffic control tool based on the traffic control region; determining a target traffic limiting strategy to be used from a pre-configured traffic limiting strategy library within the scanning range using aspect classes and conditional annotations. The traffic limiting strategy library includes traffic limiting strategies applicable to different use cases. The method also involves real-time monitoring of interface request traffic information and applying the target traffic limiting strategy to control the traffic of the interface request resources based on the traffic information. This invention, by using aspect classes and conditional annotations to select a target traffic limiting strategy, can flexibly adapt the target traffic limiting strategy to unbound interfaces and perform traffic control for the corresponding interface requests.

Description

Technical Field

[0001] This invention relates to the fields of computers and digital healthcare, and in particular to methods, apparatus, devices and storage media for flow control of interface requests. Background Technology

[0002] In computer networks, internet healthcare platforms can access data access interface services through intranets. For example, offline hospitals can access real-name interfaces on online platforms such as Guanwang and mini-programs, allowing patients to make appointments in advance according to their own needs, greatly reducing queuing and waiting time.

[0003] However, with the increasing number of online patients, internet healthcare platforms generate a large amount of data exchanged via APIs, such as data related to diagnosis and treatment, public services, and medical insurance payments. To ensure the security of internet healthcare, traffic control for API requests is essential. Traffic control regulates the rate at which network APIs send or receive requests. By controlling the traffic of API requests, the number of times an API is called per unit of time can be limited to a certain extent, protecting backend services and ensuring the stable operation of the system.

[0004] In related technologies, rate limiting policies can be created for interfaces to provide stable services, thereby controlling the flow of interface requests. However, interfaces and rate limiting policies are independent of each other. A rate limiting policy only takes effect on an interface after it is bound to it. This means that rate limiting policies cannot be adapted to unbound interfaces, and cannot control the flow of requests to those interfaces. If interface requests are too frequent in a short period of time, the service may not be able to keep up with the demand, affecting the presentation of page content. Summary of the Invention

[0005] In view of this, the present invention provides a method, apparatus and device for traffic control of interface requests, the main purpose of which is to solve the problem that the existing rate limiting strategy cannot be adapted to unbound interfaces and cannot perform traffic control for the corresponding interface requests.

[0006] According to one aspect of the present invention, a method for flow control of interface requests is provided, comprising:

[0007] Obtain the traffic control area covered by the test project, and define the scanning range of the traffic control tool based on the traffic control area;

[0008] Within the scanning range, the target rate limiting strategy to be used is determined from a pre-configured rate limiting strategy library using aspect classes and conditional annotations. The rate limiting strategy library includes rate limiting strategies applicable to different use cases.

[0009] Real-time monitoring of interface request traffic information, and using the target rate limiting strategy to control the traffic of interface request resources based on the traffic information.

[0010] Furthermore, before obtaining the flow control area covered by the test item and defining the applicable scanning range of the flow control tool based on the flow control area, the method further includes:

[0011] Obtain the current service metrics of the test project, and determine whether the service is in an overload state based on the current service metrics;

[0012] If so, in response to the triggering of the flow control command, the flow control function of the test project is enabled using the flow control framework.

[0013] Furthermore, the step of obtaining the traffic control area covered by the test project and defining the scanning range of the traffic control tool based on the traffic control area includes:

[0014] Obtain the traffic control area covered by the test project, and determine the traffic density associated with different file resources in the test project within the traffic control area;

[0015] The scanning range of the traffic control tool is defined based on the traffic density associated with different file resources in the test project.

[0016] Further, the step of obtaining the traffic control area covered by the test project, and determining the traffic density associated with different file resources in the test project within the traffic control area, includes:

[0017] During the requirements phase of the test project, traffic prediction is performed for each interface in the test project to determine the traffic control area covered by the test project.

[0018] Based on the access attributes corresponding to different file resources in the project under test, the traffic density associated with different file resources in the test project is determined in the traffic control area.

[0019] Furthermore, during the requirements phase of the test project, traffic prediction is performed for each interface in the test project to determine the traffic control area covered by the test project, including:

[0020] During the requirements phase of a test project, the resource consumption and functional parameters of each interface in the test project are determined based on the information exchanged between functional modules in the test project.

[0021] Using the resource consumption and functional parameters of each interface in the test project as evaluation parameters, traffic prediction is performed on each interface in the test project using historical access data.

[0022] Based on the traffic prediction results of each interface in the test project, the traffic control area covered by the test project is determined.

[0023] Further, determining the target rate limiting policy to be used from a pre-configured rate limiting policy library within the scan range using aspect classes and conditional annotations includes:

[0024] Define aspect classes that implement different flow limiting strategies within the scanning range, and record the corresponding flow control logic in the aspect classes;

[0025] Add conditional annotations to classes and / or methods that require flow control, and specify the use case of the aspect class through the conditional annotations;

[0026] The target rate limiting strategy to be used is determined from the pre-configured rate limiting strategy library based on the use case of the described aspect class.

[0027] Furthermore, the real-time monitoring of interface request traffic information, and the application of the target rate limiting strategy to control the traffic of the requested resources based on the traffic information, include:

[0028] Real-time monitoring of interface request traffic information, and control and prediction of the current interface request based on the number of interface calls recorded in the traffic information;

[0029] If the current interface request is within the control prediction range, then the current interface request will be allowed.

[0030] If the current interface request exceeds the control prediction, the target rate limiting strategy will be used to intercept the current interface request.

[0031] The interception of the current interface request using the target rate limiting strategy specifically includes:

[0032] When the current interface request calls a class and / or method, the target aspect class of the use case is located from the target rate limiting strategy, and the current interface request is intercepted according to the traffic control logic recorded in the target aspect class.

[0033] According to another aspect of the present invention, a flow control device for interface requests is provided, comprising:

[0034] A definition unit is used to obtain the flow control area covered by the test project and define the scanning range of the flow control tool based on the flow control area;

[0035] The determining unit is configured to determine the target rate limiting strategy to be used from a pre-configured rate limiting strategy library within the scanning range by using aspect classes and conditional annotations. The rate limiting strategy library includes rate limiting strategies applicable to different use cases.

[0036] The control unit is used to monitor the traffic information of interface requests in real time, and to control the traffic of the interface requests using the target rate limiting strategy based on the traffic information.

[0037] Furthermore, the device also includes:

[0038] The judgment unit is used to obtain the current service indicators of the test project before obtaining the traffic control area covered by the test project and defining the scanning range applicable to the traffic control tool according to the traffic control area, and to determine whether the service is in an overload state according to the current service indicators.

[0039] The enable unit is used to enable the flow control function of the test project using the flow control framework in response to the triggering of a flow control command.

[0040] Furthermore, the defining unit includes:

[0041] The determination module is used to obtain the traffic control area covered by the test project, and determine the traffic density associated with different file resources in the test project within the traffic control area;

[0042] The definition module is used to define the scanning range of the traffic control tool based on the traffic density associated with different file resources in the test project.

[0043] Furthermore, the determining module is specifically used to perform traffic prediction for each interface in the test project during the requirements phase of the test project, and determine the traffic control area covered by the test project; based on the access attributes corresponding to different file resources in the test project, determine the traffic density associated with different file resources in the test project within the traffic control area.

[0044] Furthermore, the determining module is specifically used to determine the resource consumption and functional parameters of each interface in the test project during the requirements phase of the test project, based on the information transmitted between functional modules in the test project; to use the resource consumption and functional parameters of each interface in the test project as evaluation parameters, and to perform traffic prediction for each interface in the test project using historical access data of the interface; and to determine the traffic control area covered by the test project based on the traffic prediction results of each interface in the test project.

[0045] Furthermore, the determining unit is specifically used to define aspect classes that implement different rate limiting strategies within the scanning range, wherein the aspect classes record corresponding flow control logic; add condition annotations to the classes and / or methods that need to implement flow control, and specify the use case of the aspect class through the condition annotations; and determine the target rate limiting strategy to be used from the pre-configured rate limiting strategy library according to the use case of the aspect class.

[0046] Furthermore, the control unit is specifically used to monitor the traffic information of interface requests in real time, and to make a control prediction on the current interface request based on the number of interface calls recorded in the traffic information; if the current interface request is within the control prediction, the current interface request is allowed; if the current interface request exceeds the control prediction, the target rate limiting strategy is used to intercept the current interface request.

[0047] The control unit is further configured to locate the target aspect class of the usage scenario from the target rate limiting strategy when the current interface request calls the class and / or method, and to intercept the current interface request according to the traffic control logic recorded in the target aspect class.

[0048] According to another aspect of the present invention, a computer device is provided, including a memory and a processor, the memory storing a computer program, wherein the processor executes the computer program to implement the steps of a flow control method for interface requests.

[0049] According to another aspect of the present invention, a computer storage medium is provided having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of a flow control method for interface requests.

[0050] By employing the above technical solution, this invention provides a method, apparatus, device, and storage medium for traffic control of interface requests. It obtains the traffic control area covered by the test project, defines the scanning range of the traffic control tool based on the traffic control area, and determines the target traffic limiting strategy to be used from a pre-configured traffic limiting strategy library using aspect classes and conditional annotations within the scanning range. The traffic limiting strategy library includes traffic limiting strategies applicable to different usage scenarios. It monitors the traffic information of interface requests in real time and uses the target traffic limiting strategy to control the traffic of the interface request resources based on the traffic information. Compared with the prior art of implementing traffic control for interface requests by binding traffic limiting strategies to interfaces, this application defines the scanning range of the traffic control tool by the traffic control area. It eliminates the need for developing separate traffic control for each functional interface in the test project. By selecting the target traffic limiting strategy using aspect classes and conditional annotations, the target traffic limiting strategy can be flexibly adapted to unbound interfaces, and traffic control can be performed on the corresponding interface requests. This avoids excessively frequent interface requests in a short period and ensures that the page content corresponding to the interface request achieves the expected presentation effect. Attached Figure Description

[0051] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0052] Figure 1 This is a schematic diagram of an application environment for a flow control method for interface requests in one embodiment of the present invention;

[0053] Figure 2 This is a flowchart illustrating a flow control method for interface requests in one embodiment of the present invention;

[0054] Figure 3 yes Figure 2 A schematic diagram of a specific implementation method for step S10;

[0055] Figure 4 This is another flowchart illustrating the flow control method for interface requests in one embodiment of the present invention;

[0056] Figure 5 yes Figure 2 A flowchart illustrating a specific implementation of step S20

[0057] Figure 6 yes Figure 2 A schematic diagram of a specific implementation method for step S30;

[0058] Figure 7 This is a schematic diagram of a flow control device for interface requests in one embodiment of the present invention;

[0059] Figure 8 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention;

[0060] Figure 9 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0061] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0062] The flow control method for interface requests provided in this embodiment of the invention can be applied to, for example... Figure 1In this application environment, the client communicates with the server via a network. The client can trigger traffic control commands for the test project. The server obtains the traffic control area covered by the test project, defines the scanning range of the traffic control tool based on the traffic control area, and determines the target traffic limiting strategy to be used from a pre-configured traffic limiting strategy library using aspect classes and conditional annotations within the scanning range. The traffic limiting strategy library includes traffic limiting strategies applicable to different use cases. The server monitors the traffic information of interface requests in real time and uses the target traffic limiting strategy to control the traffic of the requested resources based on the traffic information. In this invention, defining the scanning range of the traffic control tool by the traffic control area eliminates the need for developing separate traffic control for each functional interface in the test project. By selecting the target traffic limiting strategy using aspect classes and conditional annotations, the target traffic limiting strategy can be flexibly adapted to unbound interfaces, and traffic control can be performed on the corresponding interface requests, avoiding excessively frequent interface requests in a short period of time and ensuring that the page content corresponding to the interface requests achieves the expected presentation effect. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster consisting of multiple servers. The present invention will now be described in detail through specific embodiments.

[0063] Please see Figure 2 As shown, Figure 2 A flowchart illustrating the flow control method for interface requests provided in this embodiment of the invention includes the following steps:

[0064] S10. Obtain the flow control area covered by the test project, and define the scanning range of the flow control tool according to the flow control area.

[0065] Since the load capacity of business application systems is limited, in order to prevent unexpected interface requests from putting excessive pressure on the system and causing it to crash, traffic control zones can be pre-defined for test projects within the business system. These traffic control zones can be set for different business scenarios. For example, for front-end rate limiting scenarios, traffic control can be supported by zones such as account, IP, and system call logic. For business application system rate limiting scenarios, traffic control can be supported by zones such as client-side rate limiting and server-side rate limiting. For database rate limiting scenarios, traffic control can be supported by zones such as red line zones and database protection zones. Traffic control can also be set for a global zone within the test project.

[0066] In this embodiment, the flow control tool can use aspect-oriented enhancements in the application framework. These aspect-oriented enhancements can be applied to the classes and / or methods in the project test that require flow control by limiting the scan scope, so as to perform flow control on the interface requests of the methods and / or classes that require flow control.

[0067] In practical applications, if the flow control area covered by the test project is the entire test project that supports flow control, the scanning scope of the flow control tool can be defined as a point of entry. Exceptions can then be caught and handled globally through this defined point of entry. If the flow control area covered by the test project is all classes under a specific package that support flow control, the scanning scope of the flow control tool can be defined as the specific package path, such as "com.xxx.xx". Exceptions can then be caught and handled for all classes under a specified package through this defined package path. If the flow control area covered by the test project is a specific class and / or method that supports flow control, the scanning scope of the flow control tool can be defined as the conditional annotations added to that class and / or method. Exceptions can then be caught and handled for the method and / or class through these conditional annotations.

[0068] It's important to understand that different file resources in the test project have different access attributes, resulting in varying traffic densities. For example, some file resources receive more frequent API requests, while others receive fewer. Furthermore, some file resources have specific access permissions and are therefore less frequently requested. Specifically, such as... Figure 3 As shown, step S10, which involves obtaining the flow control area covered by the test project and defining the scanning range of the flow control tool based on the flow control area, includes the following steps:

[0069] S11. Obtain the traffic control area covered by the test project, and determine the traffic density associated with different file resources in the test project within the traffic control area.

[0070] S12. Define the scanning range of the traffic control tool based on the traffic density associated with different file resources in the test project.

[0071] In this embodiment, the scanning scope of the flow control tool can be implemented through the annotated container management objects in the application framework. The control scanning tool will only scan the container management objects in the application framework if they are annotated.

[0072] Since different business needs require interfaces to handle varying request volumes and peak request volumes, we can pre-predict traffic for the interfaces and define the areas covered by file resources with predicted traffic values ​​higher than expected as the traffic control zones for the test project. Specifically, in determining the traffic density associated with different file resources in the test project, traffic prediction can be performed for each interface in the test project during the requirements phase to determine the traffic control zones covered by the test project. Then, based on the access attributes of different file resources in the test project, the traffic density associated with different file resources in the test project can be determined within the traffic control zones. For example, if the access attribute of file resource A is "open," the traffic density associated with that file resource can be determined to be relatively high.

[0073] Specifically, in the process of traffic prediction for each interface in a test project, during the requirements phase of the test project, the resource consumption and functional parameters of each interface in the test project can be determined based on the information transmitted between functional modules. Using these resource consumption and functional parameters as evaluation parameters, historical access data of each interface is used to predict traffic for that interface. Based on the traffic prediction results for each interface, the traffic control area covered by the test project is determined. Here, the resource consumption of each interface can include CPU, memory, network bandwidth, etc. Historical access data can reflect the traffic situation of the interface in different historical time intervals to a certain extent. Further combining the resource consumption and functional parameters of each interface, the interface request traffic in future time intervals is predicted, and it is determined whether the predicted interface request traffic is within the interface's capacity. If the predicted interface request traffic exceeds the interface's capacity, the interface is assigned to the traffic control area of ​​the test project.

[0074] Understandably, the test projects here can be applied to medical clouds. A medical cloud refers to a cloud platform for healthcare services created using cloud computing, combining medical technology with new technologies such as cloud computing, mobile technology, multimedia, 4G communication, big data, and the Internet of Things. This enables the sharing of medical resources and expands the scope of medical care. Because of the application of cloud computing technology, medical clouds improve the efficiency of medical institutions and facilitate access to medical care for residents. Features like hospital appointment booking, electronic medical records, and medical insurance are all products of the integration of cloud computing and the medical field. Medical clouds also offer advantages such as data security, information sharing, dynamic expansion, and a global deployment.

[0075] Furthermore, to improve the flexibility of flow control during interface requests, enabling the test project to automatically trigger flow control commands under overload conditions, such as... Figure 4 As shown, prior to step 101, the method further includes the following steps:

[0076] S40. Obtain the current service metrics of the test project, and determine whether the service is in an overload state based on the current service metrics.

[0077] S50. If so, then in response to the triggering of the flow control command, use the flow control framework to enable the flow control function of the test project.

[0078] The current service metrics can include CPU, memory usage, evaluation time, etc. The current server metrics are used to determine whether the service is overloaded. If so, requests should be rejected as soon as possible with a special error code. At the same time, upstream and downstream services should be notified that the service is in an overloaded state. The traffic control function of the test project should be enabled using a traffic control framework to control the traffic of the corresponding interface requests of the service.

[0079] S20. Within the scan range, the target rate limiting strategy to be used is determined from the pre-configured rate limiting strategy library using aspect classes and conditional annotations.

[0080] The rate limiting strategy library includes rate limiting strategies suitable for different use cases. These can include: degradation processing, where when the number of requests per second exceeds a threshold, a friendly message is returned reminding the user to try again later (e.g., too many users are currently accessing the site, please try again later); queuing, where users are redirected to a queue page and processed sequentially (i.e., overflowing requests are cached in a message queue, and messages are retrieved from the queue in order for execution, achieving peak smoothing); countdown processing, where the processing time of currently backlogged requests is estimated, and the estimated countdown is displayed on the interface. If the server has available resources to process the request before the countdown ends, the request is processed successfully and a return message is sent; otherwise, degradation processing is applied, i.e., a friendly message is returned; and asynchronous processing, returning a "successfully received" notification to the user, with subsequent notifications sent asynchronously. The system can inform users of the processing results in various ways. For example, upon successful receipt, it can return "Request received, processing in progress. You will be notified via xxx upon successful processing." Successful processing can be achieved asynchronously via SMS, message, or application notification. It can also implement blacklist access restrictions. A common scenario is a unified IP address making too many requests in a short period; in this case, the IP is added to the blacklist for xx hours, and a message is returned stating "Request frequency too high, please retry in xx hours." Furthermore, it can provide alert notifications, such as sending alert emails or SMS messages to operations and development personnel to assess whether load balancing can improve performance or code execution efficiency can be optimized to increase processing speed. Finally, it can persist data, such as persisting request data per second to a database. If Y seconds of requests within X seconds exceed a threshold, a fallback mechanism is used to remind the user to try again later.

[0081] The corresponding traffic control logic can be implemented by defining aspect classes. Specifically, aspect classes can be created using annotations or XML configuration provided by the application framework.

[0082] It's understandable that objects requiring traffic control cannot trigger rate limiting policies automatically. Instead, aspects are defined in the application framework's configuration file, and conditional annotations are used to connect these aspects to the rate limiting policies for the specific use case, thus introducing the aspects into the objects requiring traffic control. Specifically, for example... Figure 5 As shown, in step S40, that is, within the scan range, the target rate limiting policy to be used is determined from the pre-configured rate limiting policy library using aspect classes and conditional annotations, including the following steps:

[0083] S21. Define aspect classes that implement different flow limiting strategies within the scanning range, and record the corresponding flow control logic in the aspect classes.

[0084] S22. Add conditional annotations to the classes and / or methods that require flow control, and specify the use case of the aspect class through the conditional annotations.

[0085] S23. Determine the target rate limiting strategy to be used from the pre-configured rate limiting strategy library according to the usage scenario of the aspect class.

[0086] In this embodiment, aspects and aspect points can be defined in the application framework's configuration file. The aspect point defines the rate limiting policy that needs to be traffic controlled, and an around advice is created in the aspect. This advice is triggered when the method matching the pointcut is called. In the around advice, the IP address of the request can be obtained by calling the response object in the method parameter. Then, the aspect is introduced into the object that needs to be traffic controlled based on the IP address, and the interface request is traffic controlled according to the rate limiting policy defined in the aspect point.

[0087] Specifically, an aspect class A can be defined within the scan scope, and annotation conditions can be added to the method m that needs to be flow-controlled. At the same time, a pointcut can be defined that matches the method that needs to be controlled. In the around advice, the IP address of the request is obtained from the response object, and then the flow control logic in aspect class A is called to determine the target flow-limiting policy to be used from the pre-configured flow-limiting policy library. If the target flow-limiting policy allows the method to access, the method call continues to be executed; otherwise, an exception is thrown.

[0088] In this embodiment, methods and / or classes requiring traffic control are introduced into the objects requiring traffic control by defining aspect classes. Conditional annotations are used to configure aspects and pointcuts, associating aspects with pointcuts. Conditional annotations are added to the classes and / or methods requiring traffic control, specifying the use case of the aspect class. Based on the use case, the target rate limiting strategy is determined to achieve traffic control of interface requests. Specifically, the process of adding conditional annotations to the classes and / or methods requiring traffic control mainly includes the following parameters: rate limiting name (name), whether rate limiting is enabled (open if true), request threshold (cnt), and rate limiting policy type (limitType).

[0089] It should be noted that in the application framework, only objects managed by the container can be scanned and proxied by aspect classes. If a class or method is not an object managed by the container, it will not be scanned and proxied by aspect classes even if conditional annotations are added.

[0090] S30. Monitor the traffic information of interface requests in real time, and use the target rate limiting strategy to control the traffic of the resources requested by the interface based on the traffic information.

[0091] Typically, a system is designed with an estimated capacity. If this capacity is exceeded for an extended period, the system may be overwhelmed, ultimately leading to insufficient service. To avoid this, it's necessary to monitor API request traffic in real time. This traffic information mainly records the number of API requests, request time, and request duration. When the number of API requests exceeds the estimated capacity, traffic limiting is implemented. The purpose of traffic limiting is to protect the system by limiting the rate of concurrent access requests or the number of requests within a window. Once the rate limit is reached, rate-limiting strategies can be used to deny service, queue, or wait API requests.

[0092] Understandably, rate limiting requirements in testing projects arise in various common scenarios. For example, during flash sales, malicious software may be used to fraudulently grab orders, necessitating rate limiting to prevent bots from participating. Another example is when a particular API is widely used by various systems, severely consuming network and memory resources, requiring appropriate rate limiting. The purpose of rate limiting is to protect the system by restricting concurrent access / requests or limiting the rate of requests within a time window. Once the rate limit is reached, service can be denied or traffic can be shaped.

[0093] Common flow control methods and scenarios can include, but are not limited to: limiting total concurrency (database connection pools, thread pools), limiting instantaneous concurrency (such as nginx's `limit_conn` module, used to limit the number of instantaneous concurrent connections; Java's `Semaphore` can also achieve this), and limiting the average rate within a time window (such as Guava's `RateLimiter` and nginx's `limitreq` module, limiting the average rate per second); others include limiting remote API calls and limiting the consumption rate of message queues (MQ). Flow control can also be implemented based on network connections, network traffic, CPU or memory load, etc.

[0094] For example, if you need to limit the number of concurrent calls to no more than 100 (the number of concurrent calls at the same time), you can use a semaphore. If you want to limit the average number of times a method is called to no more than 100 over a period of time, you need to use a RateLimiter.

[0095] Traffic shaping here aims to match the packet rate with downstream devices. When a high-speed link transmits data to a low-speed link, or when a sudden traffic surge occurs, bandwidth bottlenecks can appear at the low-speed link's exit point, leading to significant data loss. In such cases, traffic shaping needs to be performed at the exit point of the device entering the high-speed link. Specifically, this can be achieved by configuring traffic shaping on the outgoing interface of the upstream device to smooth out irregular upstream traffic, resulting in a more uniform output and resolving the instantaneous congestion problem of downstream devices. Typically, traffic shaping can be accomplished using buffers and token buckets. When the packet transmission rate is too fast, the packets are first buffered, and then evenly transmitted under the control of the token bucket. On routers, tokens are added periodically during traffic shaping, with an interval of CBS / CIR, and the number of tokens added each time is CBS.

[0096] It's important to note that rate limiting will cause system unavailability for users for a short period (milliseconds). If the system's traffic threshold per second is set to 100, theoretically, the 101st and subsequent API requests within a second will be rejected, while requests arriving in the next second will be responded to normally. Specifically, for example... Figure 6 As shown, step S30, which involves real-time monitoring of the interface request traffic information and using the target rate limiting strategy to control the traffic of the interface request resources based on the traffic information, includes the following steps:

[0097] S31. Monitor the traffic information of interface requests in real time, and make control predictions on the current interface requests based on the number of interface calls recorded in the traffic information.

[0098] S32a. If the current interface request is within the control prediction range, then the current interface request is allowed.

[0099] S32b. If the current interface request exceeds the control prediction, the target rate limiting strategy is used to intercept the current interface request.

[0100] Understandably, the number of API calls recorded in the API request traffic information can reflect the current API request call status to a certain extent. If the current API call status indicates that the number of API requests exceeds the set number within the request interval, it means that the number of API requests is too high and exceeds the control prediction. In this case, the target rate limiting strategy is used to intercept the current API request. If the current API call status indicates that the number of API requests exceeds the set number within the request interval, it means that the API request does not exceed the control prediction and the current API request is allowed.

[0101] Specifically, when using the target rate limiting strategy to intercept and process the current interface request, the target aspect class of the use case can be located from the target rate limiting strategy when the current interface request calls the class and / or method, and the current interface request can be intercepted and processed according to the traffic control logic recorded in the target aspect class.

[0102] This embodiment provides a method for traffic control of interface requests. It obtains the traffic control area covered by the test project, defines the scanning range of the traffic control tool based on the traffic control area, and determines the target traffic limiting strategy to be used from a pre-configured traffic limiting strategy library using aspect classes and conditional annotations within the scanning range. The traffic limiting strategy library includes traffic limiting strategies applicable to different use cases. It monitors the traffic information of interface requests in real time and uses the target traffic limiting strategy to control the traffic of the interface request resources based on the traffic information. Compared with the prior art of implementing traffic control of interface requests by binding traffic limiting strategies to interfaces, this application defines the scanning range of the traffic control tool by the traffic control area. It eliminates the need for developing separate traffic control for each functional interface in the test project. By selecting the target traffic limiting strategy using aspect classes and conditional annotations, the target traffic limiting strategy can be flexibly adapted to unbound interfaces, and traffic control can be performed on the corresponding interface requests. This avoids excessively frequent interface requests in a short period and ensures that the page content corresponding to the interface request achieves the expected presentation effect.

[0103] In one embodiment, a flow control device for interface requests is provided, which corresponds one-to-one with the flow control methods for interface requests in the above embodiments. For example... Figure 7 As shown, the flow control device requested by this interface includes: a definition unit 101, a determination unit 102, and a control unit 103. Detailed descriptions of each functional module are as follows:

[0104] Definition unit 101 is used to obtain the flow control area covered by the test project and define the scanning range of the flow control tool according to the flow control area;

[0105] The determining unit 102 is used to determine the target rate limiting strategy to be used from a pre-configured rate limiting strategy library within the scanning range by using aspect classes and conditional annotations. The rate limiting strategy library includes rate limiting strategies applicable to different use cases.

[0106] The control unit 103 is used to monitor the traffic information of interface requests in real time, and to perform traffic control on the resources requested by the interface using the target rate limiting strategy based on the traffic information.

[0107] In one embodiment, the device further includes:

[0108] The judgment unit is used to obtain the current service indicators of the test project before obtaining the traffic control area covered by the test project and defining the scanning range applicable to the traffic control tool according to the traffic control area, and to determine whether the service is in an overload state according to the current service indicators.

[0109] The enable unit is used to enable the flow control function of the test project using the flow control framework in response to the triggering of a flow control command.

[0110] In one embodiment, the defining unit 101 includes:

[0111] The determination module is used to obtain the traffic control area covered by the test project, and determine the traffic density associated with different file resources in the test project within the traffic control area;

[0112] The definition module is used to define the scanning range of the traffic control tool based on the traffic density associated with different file resources in the test project.

[0113] In one embodiment, the determining module is specifically used to perform traffic prediction for each interface in the test project during the requirements phase of the test project, determine the traffic control area covered by the test project, and determine the traffic density associated with different file resources in the test project within the traffic control area based on the access attributes corresponding to different file resources in the test project.

[0114] In one embodiment, the determining module is further configured to, during the requirements phase of the test project, determine the resource consumption and functional parameters of each interface in the test project based on the information transmitted between functional modules in the test project; use the resource consumption and functional parameters of each interface in the test project as evaluation parameters, and perform traffic prediction for each interface in the test project using historical access data of the interface; and determine the traffic control area covered by the test project based on the traffic prediction results of each interface in the test project.

[0115] In one embodiment, the determining unit 102 is specifically used to define aspect classes that implement different rate limiting strategies within the scanning range, wherein the aspect classes record corresponding flow control logic; add condition annotations to the classes and / or methods that need to implement flow control, and specify the use case of the aspect class through the condition annotations; and determine the target rate limiting strategy to be used from the pre-configured rate limiting strategy library according to the use case of the aspect class.

[0116] In one embodiment, the control unit 103 is specifically used to monitor the traffic information of interface requests in real time, and to make a control prediction on the current interface request based on the number of interface calls recorded in the traffic information; if the current interface request is within the control prediction, the current interface request is allowed; if the current interface request exceeds the control prediction, the target rate limiting strategy is used to intercept the current interface request.

[0117] The control unit is further configured to locate the target aspect class of the usage scenario from the target rate limiting strategy when the current interface request calls the class and / or method, and to intercept the current interface request according to the traffic control logic recorded in the target aspect class.

[0118] This embodiment provides a traffic control device for interface requests. It obtains the traffic control area covered by the test project, defines the scanning range of the traffic control tool based on the traffic control area, and determines the target traffic limiting strategy to be used from a pre-configured traffic limiting strategy library using aspect classes and conditional annotations within the scanning range. The traffic limiting strategy library includes traffic limiting strategies applicable to different use cases. It monitors the traffic information of interface requests in real time and uses the target traffic limiting strategy to control the traffic of the interface request resources based on the traffic information. Compared with the prior art of implementing traffic control for interface requests by binding traffic limiting strategies to interfaces, this application defines the scanning range of the traffic control tool by the traffic control area. It eliminates the need for developing separate traffic control for each functional interface in the test project. By selecting the target traffic limiting strategy using aspect classes and conditional annotations, the target traffic limiting strategy can be flexibly adapted to unbound interfaces, and traffic control can be performed on the corresponding interface requests. This avoids excessively frequent interface requests in a short period and ensures that the page content corresponding to the interface request achieves the expected presentation effect.

[0119] Specific limitations regarding the flow control device for interface requests can be found in the limitations of the flow control method for interface requests above, and will not be repeated here. Each module in the aforementioned flow control device for interface requests can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0120] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 8 As shown. The computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When executed by the processor, the computer program implements a flow control method for interface requests, fulfilling server-side functions or steps.

[0121] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 9 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The network interface is used to communicate with an external server via a network connection. When executed by the processor, the computer program implements client-side functions or steps of a flow control method for interface requests.

[0122] 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 executes the computer program to perform the following steps:

[0123] Obtain the traffic control area covered by the test project, and define the scanning range of the traffic control tool based on the traffic control area;

[0124] Within the scanning range, the target rate limiting strategy to be used is determined from a pre-configured rate limiting strategy library using aspect classes and conditional annotations. The rate limiting strategy library includes rate limiting strategies applicable to different use cases.

[0125] Real-time monitoring of interface request traffic information, and using the target rate limiting strategy to control the traffic of interface request resources based on the traffic information.

[0126] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor:

[0127] Obtain the traffic control area covered by the test project, and define the scanning range of the traffic control tool based on the traffic control area;

[0128] Within the scanning range, the target rate limiting strategy to be used is determined from a pre-configured rate limiting strategy library using aspect classes and conditional annotations. The rate limiting strategy library includes rate limiting strategies applicable to different use cases.

[0129] Real-time monitoring of interface request traffic information, and using the target rate limiting strategy to control the traffic of interface request resources based on the traffic information.

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

[0131] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, 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. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0132] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to 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.

[0133] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A method for flow control of interface requests, characterized in that, The method includes: Obtaining the traffic control area covered by the test project and defining the scanning range of the traffic control tool based on the traffic control area includes: obtaining the traffic control area covered by the test project, determining the traffic density associated with different file resources in the test project within the traffic control area, and defining the scanning range of the traffic control tool based on the traffic density associated with different file resources in the test project. Within the scanning range, the target rate limiting strategy to be used is determined from a pre-configured rate limiting strategy library using aspect classes and conditional annotations. The rate limiting strategy library includes rate limiting strategies applicable to different use cases. Real-time monitoring of interface request traffic information, and using the target rate limiting strategy to control the traffic of interface request resources based on the traffic information.

2. The method according to claim 1, characterized in that, Before obtaining the flow control area covered by the test item and defining the applicable scanning range of the flow control tool based on the flow control area, the method further includes: Obtain the current service metrics of the test project, and determine whether the service is in an overload state based on the current service metrics; If so, in response to the triggering of the flow control command, the flow control function of the test project is enabled using the flow control framework.

3. The method according to claim 1, characterized in that, The process of obtaining the traffic control area covered by the test project and determining the traffic density associated with different file resources in the test project within the traffic control area includes: During the requirements phase of the test project, traffic prediction is performed for each interface in the test project to determine the traffic control area covered by the test project. Based on the access attributes corresponding to different file resources in the project under test, the traffic density associated with different file resources in the test project is determined in the traffic control area.

4. The method according to claim 3, characterized in that, During the requirements phase of the test project, traffic prediction is performed for each interface in the test project to determine the traffic control area covered by the test project, including: During the requirements phase of a test project, the resource consumption and functional parameters of each interface in the test project are determined based on the information exchanged between functional modules in the test project. Using the resource consumption and functional parameters of each interface in the test project as evaluation parameters, traffic prediction is performed on each interface in the test project using historical access data. Based on the traffic prediction results of each interface in the test project, the traffic control area covered by the test project is determined.

5. The method according to any one of claims 1-4, characterized in that, The process of determining the target rate limiting policy to be used from a pre-configured rate limiting policy library within the scanning range using aspect classes and conditional annotations includes: Define aspect classes that implement different flow limiting strategies within the scanning range, and record the corresponding flow control logic in the aspect classes; Add conditional annotations to classes and / or methods that require flow control, and specify the use case of the aspect class through the conditional annotations; The target rate limiting strategy to be used is determined from the pre-configured rate limiting strategy library based on the use case of the described aspect class.

6. The method according to any one of claims 1-4, characterized in that, The real-time monitoring interface requests traffic information, and the application of the target rate limiting strategy to control the traffic of the requested resources based on the traffic information, including: Real-time monitoring of interface request traffic information, and control and prediction of the current interface request based on the number of interface calls recorded in the traffic information; If the current interface request is within the control prediction range, then the current interface request will be allowed. If the current interface request exceeds the control prediction, the target rate limiting strategy will be used to intercept the current interface request. The interception of the current interface request using the target rate limiting strategy specifically includes: When the current interface request calls a class and / or method, the target aspect class of the use case is located from the target rate limiting strategy, and the current interface request is intercepted according to the traffic control logic recorded in the target aspect class.

7. A flow control device for interface requests, characterized in that, The device includes: A definition unit is used to obtain the traffic control area covered by the test project and define the scanning range of the traffic control tool based on the traffic control area. This includes: obtaining the traffic control area covered by the test project; determining the traffic density associated with different file resources in the test project within the traffic control area; and defining the scanning range of the traffic control tool based on the traffic density associated with different file resources in the test project. The determining unit is configured to determine the target rate limiting strategy to be used from a pre-configured rate limiting strategy library within the scanning range by using aspect classes and conditional annotations. The rate limiting strategy library includes rate limiting strategies applicable to different use cases. The control unit is used to monitor the traffic information of interface requests in real time, and to control the traffic of the interface requests using the target rate limiting strategy based on the traffic information.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images