API (Application Program Interface) request routing method and device, storage medium and computer equipment

Abstract

The invention relates to the technical field of Internet technology and smart medical treatment, and particularly discloses an API request routing method and device, a storage medium and computer equipment, and the method comprises the steps: monitoring the current API request flow of a target server cluster and the current performance data of each server in the target server cluster in real time; determining input data of a preset traffic prediction model according to the current API request traffic and the API request traffic in a first preset time period before the current time, and obtaining predicted traffic trend data in a second preset time period through the preset traffic prediction model based on the input data; and determining a traffic peak value in a second preset time period based on the predicted traffic trend data, updating a current request routing strategy according to current performance data of each server in the target server cluster when the traffic peak value is greater than a preset peak threshold value, and routing a subsequent API request based on the updated request routing strategy.

Description

Technical Field

[0001] The present application relates to the fields of Internet technology and smart medical technology, and in particular to a routing method and device for API requests, a storage medium, and a computer device. Background Art

[0002] With the rapid development of Internet technology, cloud computing and distributed system architecture have gradually become the infrastructure supporting large-scale online services and applications. In such a system, API (Application Programming Interface) serves as a bridge for communication between services, and its performance and stability directly determine the user experience and reliability of the entire system. However, with the increase in the number of users and business complexity, API request traffic has become highly dynamic and unpredictable, which poses severe challenges to the load management and resource allocation of server clusters.

[0003] Traditional API request routing systems usually use static configuration files to define routing rules. These configuration files are usually loaded when the server starts and are not dynamically adjusted at runtime. For example, the configuration file specifies which server is used to handle which API request. This method performs well in static or low-traffic environments, but when faced with sudden API request traffic peaks, it is easy to cause some servers to be overloaded while other servers are idle, resulting in uneven resource allocation and increased response delays.

[0004] For example, for a medical consultation platform, most of the time, the traffic environment corresponding to the medical consultation platform is a low-traffic, stable traffic environment. However, during an epidemic outbreak, or when a new function is added to the medical consultation platform, the number of user visits and consultations will increase significantly, causing the medical consultation platform to experience a sudden peak in API request traffic. At this time, if the target server cluster corresponding to the medical consultation platform uses a static configuration file to define the routing rules for API requests, then some servers in the target server cluster are bound to be overloaded, while some servers are idle. The processing time of the API requests of the overloaded servers is bound to be extended, thereby affecting the processing efficiency of the API requests and even affecting the user experience. Summary of the invention

[0005] In view of this, the present application provides an API request routing method and device, storage medium, and computer equipment, which can realize refined resource management of server clusters, ensuring that stable and efficient API request processing services can be provided even in high-concurrency scenarios; by predicting traffic peaks in advance and adjusting request routing strategies accordingly, it can effectively balance server loads, reduce response time, and improve user experience, while optimizing resource utilization and reducing operating costs.

[0006] According to one aspect of the present application, a method for routing an API request is provided, comprising:

[0007] Monitor the current API request traffic of the target server cluster and the current performance data of each server in the target server cluster in real time, wherein the current performance data includes current load data and / or current response time;

[0008] Determine input data of a preset traffic prediction model according to the current API request traffic and the API request traffic in a first preset time period before the current time, and obtain predicted traffic trend data in a second preset time period through the preset traffic prediction model based on the input data;

[0009] Based on the predicted traffic trend data, the traffic peak value within the second preset time period is determined. When the traffic peak value is greater than the preset peak threshold, the current request routing strategy is dynamically updated according to the current performance data of each server in the target server cluster, and subsequent API requests are routed based on the updated request routing strategy.

[0010] According to another aspect of the present application, there is provided a routing device for an API request, comprising:

[0011] A request traffic monitoring module, used to monitor the current API request traffic of the target server cluster and the current performance data of each server in the target server cluster in real time, wherein the current performance data includes current load data and / or current response time;

[0012] A traffic trend prediction module, used to determine input data of a preset traffic prediction model according to the current API request traffic and the API request traffic in a first preset time period before the current time, and based on the input data, obtain predicted traffic trend data in a second preset time period through the preset traffic prediction model;

[0013] A routing strategy update module is used to determine the traffic peak value within the second preset time period based on the predicted traffic trend data. When the traffic peak value is greater than the preset peak threshold, the current request routing strategy is dynamically updated according to the current performance data of each server in the target server cluster, and subsequent API requests are routed based on the updated request routing strategy.

[0014] According to another aspect of the present application, a storage medium is provided, on which a computer program is stored, and when the program is executed by a processor, the routing method of the above-mentioned API request is implemented.

[0015] According to another aspect of the present application, a computer device is provided, including a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein the processor implements the above-mentioned API request routing method when executing the program.

[0016] By means of the above technical scheme, the present application provides a method and device for routing API requests, a storage medium, and a computer device. By real-time collection and analysis of the API request traffic of the target server cluster and the performance data of each server (such as current load, response time, etc.), it can not only reflect the operating status of the target server cluster in real time, but also predict the traffic trend in the future period of time based on historical data through a preset traffic prediction model. By predicting the future traffic peak, the request routing strategy can be actively and dynamically adjusted based on the actual performance of each server before the traffic peak arrives, such as adjusting the weight of each server, so as to effectively avoid server overload and improve the overall throughput and response speed. The embodiment of the present application can realize the refined management of the resources of the server cluster, ensuring that stable and efficient API request processing services can be provided in high concurrency scenarios; by predicting the traffic peak in advance and adjusting the request routing strategy accordingly, it can effectively balance the server load, reduce the response time, improve the user experience, and optimize resource utilization and reduce operating costs.

[0017] The above description is only an overview of the technical solution of the present application. In order to more clearly understand the technical means of the present application, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0019] Figure 1 A schematic diagram of a process flow of a method for routing an API request provided in an embodiment of the present application is shown;

[0020] Figure 2 A schematic diagram of a process flow of another API request routing method provided in an embodiment of the present application is shown;

[0021] Figure 3 A schematic diagram of the structure of a routing device for API requests provided in an embodiment of the present application is shown;

[0022] Figure 4 A schematic diagram of the device structure of a computer device provided in an embodiment of the present application is shown. DETAILED DESCRIPTION

[0023] The present application will be described in detail below with reference to the accompanying drawings and in combination with embodiments. It should be noted that the embodiments and features in the embodiments of the present application can be combined with each other without conflict.

[0024] In this embodiment, a routing method for API requests is provided, such as Figure 1 As shown, the method includes:

[0025] Step 101, monitor the current API request traffic of the target server cluster and the current performance data of each server in the target server cluster in real time, wherein the current performance data includes current load data and / or current response time.

[0026] A routing method for API requests provided in an embodiment of the present application can dynamically update the request routing strategy according to the changes in the API request traffic, so that the server cluster can cope with the sudden increase in API request traffic well. The target server cluster can be a server cluster corresponding to a certain platform or a certain company, a certain business, etc. In order to be able to discover the sudden increase in API request traffic as early as possible, the API request traffic that needs to be processed corresponding to the target server cluster can be monitored in real time, and the number of API requests that need to be processed by the server cluster can be continuously tracked. At the same time, in order to timely understand the current ability of each server in the target server cluster to process API requests, the current performance data of each server can also be monitored. Here, the current performance data may include the current load data of the server (such as CPU usage, memory usage, etc.) and / or the current response time (the time required to process the request).

[0027] Step 102, according to the current API request traffic and the API request traffic in a first preset time period before the current time, determine the input data of the preset traffic prediction model, and based on the input data, obtain the predicted traffic trend data in a second preset time period through the preset traffic prediction model.

[0028] In this embodiment, the input data is then determined based on the current API request traffic and the API request traffic within a first preset time period before the current time (such as the past hour). Here, the first preset time period can be determined based on actual needs and is not limited here. Next, the input data is used to predict the traffic trend in the future through a preset traffic prediction model. The preset traffic prediction model can be based on machine learning training and is used to predict the API request traffic trend in the future second preset time period (such as the next half hour or one hour), that is, the API request traffic change in the second preset time period. The predicted traffic trend data output by the preset traffic prediction model may include the change in the number of each API request in the second preset time period, and may also include some other data. The types of API requests may include payment API requests, browsing API requests, search API requests, etc.

[0029] Step 103, based on the predicted traffic trend data, determine the traffic peak value within the second preset time period. When the traffic peak value is greater than the preset peak threshold, dynamically update the current request routing strategy according to the current performance data of each server in the target server cluster, and route subsequent API requests based on the updated request routing strategy.

[0030] In this embodiment, after obtaining the predicted traffic trend data, further, the traffic peak value within the second preset time period can be determined based on the predicted traffic trend data. It should be noted that the traffic peak value can be directly output by the preset traffic prediction model, that is, directly included in the predicted traffic trend data, or it can be inferred from the predicted traffic trend data. If the predicted traffic peak value exceeds the preset peak threshold, it can be considered that routing API requests according to the original request routing strategy may cause certain servers to face overload risks. Here, the preset peak threshold can be determined according to actual needs. When the traffic peak value is greater than the preset peak threshold, it means that the current target server cluster is about to deal with a sudden increase in API request traffic. Therefore, in order to ensure that these API requests can be processed normally when the API request traffic suddenly increases, the current request routing strategy can be dynamically updated according to the current performance data of each server. For example, more API requests are routed to servers with lower current loads and faster response times.

[0031] By applying the technical solution of this embodiment, by real-time collection and analysis of the API request traffic of the target server cluster and the performance data of each server (such as current load, response time, etc.), not only can the operating status of the target server cluster be reflected immediately, but also the traffic trend in the future can be predicted based on historical data through a preset traffic prediction model. By predicting future traffic peaks, the request routing strategy can be actively and dynamically adjusted based on the actual performance of each server before the traffic peak arrives, such as adjusting the weight of each server, so as to effectively avoid server overload and improve overall throughput and response speed. The embodiment of the present application can realize the refined management of the resources of the server cluster, ensuring that stable and efficient API request processing services can be provided in high-concurrency scenarios; by predicting the traffic peak in advance and adjusting the request routing strategy accordingly, it can effectively balance the server load, reduce the response time, improve the user experience, and optimize resource utilization and reduce operating costs.

[0032] Further, as a refinement and extension of the specific implementation of the above embodiment, in order to fully illustrate the specific implementation process of this embodiment, another routing method for API requests is provided, such as Figure 2 As shown, the method includes:

[0033] Step 201 , monitor the current API request traffic of the target server cluster and the current performance data of each server in the target server cluster in real time, wherein the current performance data includes current load data and / or current response time.

[0034] Step 202, based on the current API request traffic and the API request traffic within a first preset time period before the current time, determine the API request basic data sequence, the API request time dimension data sequence and the API request pattern data sequence, wherein the API request basic data includes request quantity data and / or request type data, the API request time dimension data includes request time data and / or request date data, and the API request pattern data includes at least one of request device type data, request geographic location data, and new and old user identification data.

[0035] In this embodiment, according to the API request traffic within the first preset time period, the API request basic data sequence, the API request time dimension data sequence and the API request pattern data sequence can be determined. Here, the API request basic data includes request quantity data and / or request type data. The request quantity data reflects the total number of requests at a certain moment, while the request type data reflects what types of API requests (such as payment, search, browsing, etc.) exist at a certain moment, and can also include the number of each API request. The API request time dimension data includes request time data and / or request date data. The request time data is used to indicate the time at which the request was issued, such as 15:33; the request date data is used to indicate the specific date when the request occurred, such as June 18, 2024, etc. The API request pattern data includes request device type data (such as mobile phones, tablets, desktop computers, etc.), request geographic location data (such as countries, regions, cities, etc.), and new and old user identification data (such as new users, returning users, active users, etc.). These data are of great significance for subsequent traffic prediction.

[0036] Step 203, based on the current time, obtain external event information, and use the external event information, API request basic data sequence, API request time dimension data sequence and API request mode data sequence as the input data, wherein the external event information includes at least one of promotional activities, version releases and news events.

[0037] In this embodiment, external event information can also be obtained. Here, the external event information can be obtained based on the current time, including promotional activities, version releases, news events, and other events that may have a significant impact on API request traffic. These events are usually sudden and uncertain, so their introduction can significantly improve the accuracy of traffic prediction. Afterwards, the external event information, as well as the API request basic data sequence, API request time dimension data sequence, and API request mode data sequence obtained in the previous step can be integrated together as input data for the preset traffic prediction model.

[0038] For example, in the smart medical scenario, promotional activities can include medical discount package activities, health lectures or free clinics, etc. Medical discount package activities: In order to attract patients, medical institutions can launch a series of medical discount packages, such as physical examination packages, treatment packages, etc. At this time, patients may query and purchase these packages through medical apps, websites and other channels, resulting in a significant increase in the request traffic of related APIs (such as package query API, purchase API, etc.). Health lectures or free clinics: Medical institutions or communities organize health lectures, free clinics and other activities to promote health knowledge and provide preliminary medical consultations. At this time, before the event, patients may query event information and make appointments to participate through medical apps, websites and other channels, resulting in a significant increase in the request traffic of related APIs (such as appointment API, query API, etc.).

[0039] Version releases may include new version releases of medical apps and medical system upgrades. New version release of medical apps: Medical institutions update their medical apps, adding new features and optimizing user experience. After the new version is released, users may download and update the apps and try new features in a centralized manner, resulting in an increase in request traffic for related APIs (such as user login APIs, function usage APIs, etc.). Medical system upgrades: Medical institutions upgrade their internal medical systems to improve system stability and security. During system upgrades, data migration, system testing, and other operations may need to be performed through the API, resulting in an increase in request traffic for related APIs. At the same time, after the upgrade, the improvement in system performance may also attract more users to use related features, further increasing API request traffic.

[0040] News events may include public health emergencies, etc. Public health emergencies: such as epidemic outbreaks, epidemics, and other public health emergencies. These events may lead to a surge in patients' demand for medical information and medical resources, such as checking epidemic dynamics, making appointments, and purchasing protective equipment. At this time, the request traffic of related APIs (such as epidemic query APIs, registration APIs, shopping APIs, etc.) may increase significantly.

[0041] Step 204: input the input data into the preset traffic prediction model, and respectively extract the external event features corresponding to the external event information, as well as the API request basic data features, API request time dimension data features, and API request pattern data features through the preset traffic prediction model; and based on the external event features, API request basic data features, API request time dimension data features, and API request pattern data features, obtain fused data features; and based on the fused data features, determine the predicted traffic trend data within the second preset time period.

[0042] In this embodiment, then, the input data is input into the preset traffic prediction model. Inside the preset traffic prediction model, first, the external event features corresponding to the external event information, as well as the API request basic data features, API request time dimension data features, and API request pattern data features are extracted respectively. These feature extraction processes may include technical means such as data preprocessing, feature selection, and feature scaling. Next, the extracted external event features, API request basic data features, API request time dimension data features, and API request pattern data features are fused to form fused data features. Finally, based on the fused data features, the preset traffic prediction model performs traffic prediction to obtain predicted traffic trend data within a second preset time period. These data can be presented in the form of a time series, reflecting the changing trend of API request traffic in the future period. Here, the preset traffic prediction model can be a traditional machine learning model, a deep learning model, and the like. During the training process of the preset traffic prediction model, the input can be historical external event information, historical API request basic data series, historical API request time dimension data series and historical API request pattern data series, and the initial traffic prediction model can be trained with real traffic trend data. When the error between the model output result and the actual result is less than the preset error, the accuracy of the model is considered to be acceptable. At this time, the trained model can be used as the preset traffic prediction model.

[0043] The embodiment of the present application achieves accurate prediction of API request traffic by integrating and analyzing the basic data, time dimension data, pattern data and external event information of API requests. This prediction method not only takes into account the changing rules of the request traffic itself, but also takes into account the impact of external factors on the request traffic, which can significantly improve the accuracy and reliability of the prediction.

[0044] Step 205, based on the predicted traffic trend data, determine the traffic peak value within the second preset time period. When the traffic peak value is greater than the preset peak threshold, dynamically update the current request routing strategy according to the current performance data of each server in the target server cluster, and route subsequent API requests based on the updated request routing strategy.

[0045] In an embodiment of the present application, optionally, when the current performance data includes current load data and current response time, the "dynamically updating the current request routing policy according to the current performance data of each server in the target server cluster" in step 205 includes: calculating the weight corresponding to each server according to the current load data and current response time corresponding to each server in the target server cluster; calculating the request allocation ratio corresponding to each server according to the weight, and updating the current request routing policy based on the request allocation ratio.

[0046] In this embodiment, for a server, the current load data can reflect the request processing capability of the server; the current response time can reflect the time required for the server to process the request, including the entire process from receiving the request to returning the response. The length of the response time directly affects the user experience and service quality. If the current performance data includes both the current load data and the current response time, the current request routing policy can be updated through the following steps.

[0047] First, a weight is calculated for each server based on the collected current load data and current response time. This weight can reflect the relative processing capacity of the server, that is, the higher the weight, the stronger the current processing capacity of the server, and the more efficient it can be in processing more requests. In one embodiment, the weight calculation formula can be expressed as follows:

[0048] Weight = 1 / (current load × current response time);

[0049] Next, based on the weight of each server, calculate its request allocation ratio in the entire server cluster. The request allocation ratio is proportional to the weight, that is, the server with a higher weight can be allocated more requests in the future. Assuming that the target server cluster includes n servers, namely server 1 to server n, and the corresponding weights are weight 1 to weight n, then for a server m, its request allocation ratio can be calculated by the following formula:

[0050] Request allocation ratio m = weight m / (weight 1 + weight 2 + ... + weight n);

[0051] After calculating the request allocation ratio corresponding to each server, the current request routing policy can be updated based on the calculated request allocation ratio. Here, the request routing policy refers to the policy on how to distribute API requests to each server in the server cluster. In one embodiment, the request allocation ratio corresponding to each server can be used to update the request allocation rules configured for each server in the current request routing policy. The updated request routing policy can ensure that subsequent API requests are allocated to each server according to the calculated ratio, thereby achieving load balancing.

[0052] In one embodiment, after implementing a new request routing strategy, the current performance data of each server in the server cluster can be continuously monitored, including load conditions, response time, etc. If it is found that the load of some servers is higher than the load threshold and / or the response time is longer than the time threshold, the weight and request allocation ratio can be recalculated, and the request routing strategy can be updated again. This process can be a continuous cycle to ensure that the server cluster can always maintain the best operating state.

[0053] The embodiment of the present application realizes the automation and intelligence of load balancing by dynamically calculating the weight according to the current load and response time of the server and distributing the request according to the weight. This can not only improve the utilization rate of server resources, but also improve the stability of the service and user experience.

[0054] For example, for a large medical consultation platform, there are three servers in its target server cluster to process API requests, namely ServerA, ServerB, and ServerC. It is pre-defined that ServerA is used to process browsing API requests such as browsing health articles and browsing physical examination packages, ServerB is used to process payment API requests for physical examination packages and online drug purchases, and ServerC is used to process search API requests such as drug search and doctor search. The current performance data of each server is as follows: ServerA: load 30%, response time 100ms; ServerB: load 70%, response time 200ms; ServerC: load 50%, response time 150ms.

[0055] Calculate the weight of each server based on the current performance data: ServerA: Weight A = 1 /

[0056] (100ms*0.3)=33.33; ServerB: Weight B=1 / (200ms*0.7)=7.14; ServerC: Weight C=1 / (150ms*0.5)=13.33. The result shows that ServerA has the highest weight, so more API requests will be assigned to ServerA first.

[0057] After the weight calculation is completed, the request allocation ratio can be calculated based on the weight: 62% of the subsequent API requests are allocated to ServerA; 13% of the API requests are allocated to ServerB; 25% of the API requests are allocated to ServerC with a higher load. As the API request traffic changes, the weight can be continuously monitored in real time and adjusted dynamically. For example, when the load of ServerA gradually increases, the CPU load reaches 60%, and the response time increases to 180ms, the weight of ServerA can be reduced, and more API requests can be allocated to ServerC or ServerB to maintain the balance of the overall performance of the server cluster.

[0058] In an embodiment of the present application, optionally, the "routing subsequent API requests based on the updated request routing strategy" in step 205 includes: when an API request is received, identifying the importance level corresponding to the API request, and based on the importance level, adding the API request to a request queue of corresponding priority; according to the request allocation ratio corresponding to each server in the updated request routing strategy, and the order of priority from high to low corresponding to each request queue, polling the API requests stored in each request queue according to the request allocation ratio.

[0059] In this embodiment, after the request routing policy is updated, the target server cluster can then normally receive API requests. After receiving the API request, for each received API request, its importance level is identified. In one embodiment, the importance level of the API request can be determined according to the type of API request. For example, for key business operations such as payment requests, order confirmation requests, and inventory update requests, these API requests require a quick response, so a higher importance level can be set; for common business operations such as product search requests and user information update requests, they do not affect the core business functions, so a lower importance level can be set.

[0060] Next, according to the identified importance level, the API request is added to the request queue of the corresponding priority. Among them, API requests with high importance level are added to the high priority queue to ensure that they can be processed faster; conversely, API requests with low importance level are added to the low priority queue. After that, according to the updated request routing strategy and the priority order of each request queue, the API requests stored in each request queue are polled and processed. Specifically, the API requests in the queue with the highest priority are processed first, and the API requests are distributed to different servers according to the request allocation ratio. For example, the request allocation ratio corresponding to ServerA is 62%, the request allocation ratio corresponding to ServerB is 13%, and the request allocation ratio corresponding to ServerC is 25%. Then, when performing API request polling processing, 6 API requests can be allocated to ServerA, 1 API request to ServerB, and 2 API requests to ServerC in order according to the order of the API requests in the queue. When the API requests in the high priority queue are processed, the same method is used to process the API requests in the queue with lower priority. During the processing, when new API requests are added to the high-priority queue, they can be processed instead, thus ensuring that important API requests can be processed in a timely manner.

[0061] The embodiment of the present application realizes priority management of request processing and optimal resource allocation by identifying the importance level of API requests and adding them to the request queue of the corresponding priority, and performing round-robin processing based on the request routing strategy of dynamic load balancing. This can not only improve the response speed and throughput of the server cluster, but also ensure that high-priority requests are processed in a timely manner, thereby improving the user experience.

[0062] In an embodiment of the present application, optionally, the method also includes: real-time monitoring of the number of pending API requests corresponding to each server in the target server cluster; when the number of pending API requests corresponding to any server is greater than a first preset number threshold, and the current performance data corresponding to any server indicates that the request processing performance of any server does not meet the preset request allocation conditions, the server identifier corresponding to any server is removed from the current request routing policy, and subsequent API requests are routed based on the request routing policy after removal; and, when the number of pending API requests corresponding to any server is less than or equal to a second preset number threshold, and the current performance data corresponding to any server indicates that the request processing performance of any server meets the preset request allocation conditions, based on the current performance data of each server in the target server cluster, the current request routing policy is dynamically updated.

[0063] In this embodiment, the number of pending API requests for each server can also be monitored in real time. When the number of pending API requests for any server in the target server cluster exceeds the first preset number threshold, and at the same time, the current performance data of the server indicates that its request processing performance does not meet the preset request allocation conditions, the server identifier of this server can be removed from the current request routing policy, so that subsequent new API requests will no longer be routed to this server, which can avoid further deterioration of the performance of the server. Here, the preset request allocation conditions can be restrictions on the server load, response time, etc. For example, the server load is limited to less than 70% and / or the response time is less than 150ms, which is determined to meet the preset request allocation conditions.

[0064] In addition, when the number of pending API requests of any server is less than or equal to the second preset number threshold, and at the same time, the current performance data of the server indicates that its request processing performance meets the preset request allocation conditions, then the current request routing strategy is dynamically updated based on the current performance data of each server in the target server cluster. Here, the server cluster includes servers that were previously eliminated due to overload. If the server meets the preset request allocation conditions again, then the server can be re-included in the request routing strategy, or the proportion of requests received by different servers can be adjusted according to the performance differences of each server to optimize the load balancing of the overall cluster. It should be noted that the above-mentioned first preset number threshold and second preset number threshold can be determined based on experience and are not limited here.

[0065] The embodiment of the present application optimizes the performance of the server cluster by real-time monitoring and dynamically adjusting the request routing strategy, and takes prompt measures when a server overload is detected to prevent the occurrence of performance bottlenecks; at the same time, after the server performance is restored, it can be flexibly reintegrated into the service to fully utilize the cluster resources. Such a mechanism helps to improve the response speed of API requests while ensuring the effective use of server resources.

[0066] In an embodiment of the present application, optionally, the method further includes: counting the request objects corresponding to historical API requests within a third preset time period according to a preset period, and counting the request frequency corresponding to each request object; storing the request objects whose request frequency is greater than the preset frequency in a preset cache space; accordingly, the method further includes: when an API request is received, determining whether the request object corresponding to the API request is stored in the preset cache space, and when the result is yes, routing the API request to the preset cache space, otherwise, routing the API request based on the current request routing policy.

[0067] In this embodiment, it is also possible to analyze which request objects have a higher request frequency, and these request objects can be stored in the cache space, and the request objects can be directly obtained from the cache space later. Specifically, the request objects corresponding to the historical API requests within the third preset time period can be counted according to the preset period. Here, the preset period can be a fixed time interval, such as a week, half a month, etc., which is used to regularly perform subsequent operations; the third preset time period refers to a specific time window, such as the most recent week, month, etc., for collecting and counting request objects corresponding to API requests. It should be noted that the duration of the preset period can be equal to the duration of the third preset time period, or it can be less than the duration of the third preset time period. The third preset time period can be determined according to actual needs; historical API requests refer to all API requests that occurred within the third preset time period.

[0068] Next, for each request object, calculate the number of times it appears in the third preset time period, that is, the request frequency of the request object. Among them, each API request corresponds to a request object. For example, for a medical consultation APP, the API request may be a request to obtain a list of doctors, then the request object is the corresponding list of doctors. For those request objects whose request frequency is greater than the preset frequency, they can be stored in a preset cache space. This cache space can be a memory database, a Redis cache, or other fast-access data storage space. For example, product lists, user personal information queries, etc., the request objects of such API requests are frequently accessed in a short period of time, and the response data changes little, then the request objects of such API requests can be considered for caching to ensure that high-frequency access data can be read from the cache space as much as possible, so as to reduce direct access to the database, which can not only reduce the pressure on the database or server, but also improve the response speed. For low-frequency request objects, such as order status updates, they can be generated dynamically.

[0069] In addition, in the embodiment of the present application, whenever a new API request is received, it is first checked whether the request object corresponding to the API request has been stored in the preset cache space. If the request object exists in the preset cache space, it means that the request object is a high-frequency request object, and the API request can be directly routed to the preset cache space to obtain the request object from the preset cache space; if the request object is not in the preset cache space, the request is processed according to the current request routing strategy, and it is routed to the server for subsequent processing by the server.

[0070] The embodiment of the present application regularly counts the frequency of request objects corresponding to API requests and stores high-frequency request objects in a preset cache space, so that when a new API request is received, it can quickly determine whether the corresponding request object is a high-frequency request object, and determine the optimal routing strategy accordingly. This mechanism helps to optimize the use of server cluster resources and improve the processing efficiency of API requests, especially when facing a large number of concurrent requests, it can reduce the response time and load of the server cluster. In addition, the embodiment of the present application counts the request frequency of the request object corresponding to the API request according to a preset period, and updates the request object in the preset cache space in a timely manner, so that the high-frequency request object can change continuously over time, so as to be more in line with the actual situation and improve the utilization rate of the preset cache space.

[0071] In an embodiment of the present application, optionally, after step 205, the method further includes: monitoring the execution of the updated request routing policy in real time, and when an abnormal event is monitored, executing a configuration rollback function to replace the updated request routing policy with the request routing policy before the update.

[0072] In this embodiment, after the request routing policy is updated, the performance of the updated request routing policy in actual application can also be continuously checked or monitored. Specifically, the content of monitoring can include the hit rate of the routing policy (i.e., how many API requests are correctly routed), the response time (the time from the issuance of the API request to the response), the error rate (the proportion of the error request caused by the routing policy), etc. In the monitoring process, which situations are considered abnormal can be pre-defined. For example, if the updated routing policy causes a sharp increase in the error rate, or the response time is significantly extended, these can be regarded as abnormal events. When an abnormal event is detected, a rollback operation can be automatically performed, that is, the updated request routing policy is replaced with the policy before the update. It should be noted that each version of the request routing policy can be stored, or at least the request routing policy of the previous version can be stored, so that when an abnormality occurs, it can be quickly restored to this old version to ensure the stability and continuity of the service. The embodiment of the present application ensures the stability and reliability of the system by monitoring the execution of the updated request routing policy in real time, and automatically executing the configuration rollback function when an abnormality is detected, which can significantly reduce the risk of service interruption or performance degradation caused by policy updates.

[0073] Further, as Figure 1 The specific implementation of the method, the embodiment of the present application provides a routing device for API requests, such as Figure 3 As shown, the device comprises:

[0074] A request traffic monitoring module, used to monitor the current API request traffic of the target server cluster and the current performance data of each server in the target server cluster in real time, wherein the current performance data includes current load data and / or current response time;

[0075] A traffic trend prediction module, used to determine input data of a preset traffic prediction model according to the current API request traffic and the API request traffic in a first preset time period before the current time, and based on the input data, obtain predicted traffic trend data in a second preset time period through the preset traffic prediction model;

[0076] A routing strategy update module is used to determine the traffic peak value within the second preset time period based on the predicted traffic trend data. When the traffic peak value is greater than the preset peak threshold, the current request routing strategy is dynamically updated according to the current performance data of each server in the target server cluster, and subsequent API requests are routed based on the updated request routing strategy.

[0077] Optionally, the traffic trend prediction module is used to:

[0078] According to the current API request traffic and the API request traffic in a first preset time period before the current time, determine an API request basic data sequence, an API request time dimension data sequence, and an API request pattern data sequence, wherein the API request basic data includes request quantity data and / or request type data, the API request time dimension data includes request time data and / or request date data, and the API request pattern data includes at least one of request device type data, request geographic location data, and new and old user identification data;

[0079] Based on the current time, external event information is obtained, and the external event information, the API request basic data sequence, the API request time dimension data sequence, and the API request mode data sequence are used as the input data, wherein the external event information includes at least one of a promotion activity, a version release, and a news event;

[0080] Accordingly, the traffic trend prediction module is also used to:

[0081] The input data is input into the preset traffic prediction model, and the external event features corresponding to the external event information, as well as the API request basic data features, API request time dimension data features, and API request pattern data features are respectively extracted through the preset traffic prediction model, and based on the external event features, API request basic data features, API request time dimension data features, and API request pattern data features, fused data features are obtained, and based on the fused data features, the predicted traffic trend data within a second preset time period is determined.

[0082] Optionally, when the current performance data includes current load data and current response time, the routing policy updating module is used to:

[0083] Calculate the weight of each server according to the current load data and current response time of each server in the target server cluster;

[0084] According to the weights, the request allocation ratio corresponding to each server is calculated respectively, and based on the request allocation ratio, the current request routing strategy is updated.

[0085] Optionally, the routing policy updating module is further used to:

[0086] When an API request is received, identifying an importance level corresponding to the API request, and adding the API request to a request queue of a corresponding priority based on the importance level;

[0087] According to the request allocation ratio corresponding to each server in the updated request routing strategy, and the order of priority corresponding to each request queue from high to low, the API requests stored in each request queue are polled according to the request allocation ratio.

[0088] Optionally, the device further comprises:

[0089] A request quantity monitoring module, used to monitor in real time the number of pending API requests corresponding to each server in the target server cluster;

[0090] The routing policy update module is also used to remove the server identifier corresponding to any server from the current request routing policy when the number of pending API requests corresponding to any server is greater than a first preset number threshold and the current performance data corresponding to any server indicates that the request processing performance of any server does not meet the preset request allocation conditions, and to route subsequent API requests based on the request routing policy after removal; and, when the number of pending API requests corresponding to any server is less than or equal to a second preset number threshold and the current performance data corresponding to any server indicates that the request processing performance of any server meets the preset request allocation conditions, dynamically update the current request routing policy based on the current performance data of each server in the target server cluster.

[0091] Optionally, the device further comprises:

[0092] A frequency statistics module, used to count the request objects corresponding to the historical API requests within the third preset time period according to a preset period, and count the request frequency corresponding to each request object;

[0093] A storage module, used for storing request objects whose request frequency is greater than a preset frequency into a preset cache space;

[0094] Accordingly, the device further comprises:

[0095] The judgment module is used to judge whether the request object corresponding to the API request is stored in the preset cache space when an API request is received, and when the result is yes, route the API request to the preset cache space; otherwise, route the API request based on the current request routing strategy.

[0096] Optionally, the device further comprises:

[0097] The policy rollback module is used to monitor the execution of the updated request routing policy in real time after the subsequent API requests are routed based on the updated request routing policy, and when an abnormal event is monitored, execute the configuration rollback function to replace the updated request routing policy with the request routing policy before the update.

[0098] It should be noted that for other corresponding descriptions of the functional units involved in the routing device for an API request provided in the embodiment of the present application, please refer to Figure 1 to Figure 2 The corresponding description in the method will not be repeated here.

[0099] The present application also provides a computer device, which may be a personal computer, a server, a network device, etc. Figure 4 As shown, the computer device includes a bus, a processor, a memory and a communication interface, and may also include an input and output interface and a display device. 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, 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 database of the computer device is used to store location information. The network interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, the steps in each method embodiment are implemented.

[0100] Those skilled in the art will understand that Figure 4 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0101] In one embodiment, a computer-readable storage medium is provided. The computer-readable storage medium may be non-volatile or volatile, and stores a computer program thereon. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.

[0102] In one embodiment, a computer program product is provided, including a computer program, which implements the steps in the above method embodiments when executed by a processor.

[0103] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties.

[0104] 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 the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, etc., but are not limited to this.

[0105] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0106] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A routing method for API requests, characterized in that: include: Monitor the current API request traffic of the target server cluster and the current performance data of each server in the target server cluster in real time, wherein the current performance data includes current load data and / or current response time; Determine input data of a preset traffic prediction model according to the current API request traffic and the API request traffic in a first preset time period before the current time, and obtain predicted traffic trend data in a second preset time period through the preset traffic prediction model based on the input data; Based on the predicted traffic trend data, the traffic peak value within the second preset time period is determined. When the traffic peak value is greater than the preset peak threshold, the current request routing strategy is dynamically updated according to the current performance data of each server in the target server cluster, and subsequent API requests are routed based on the updated request routing strategy.

2. The method according to claim 1, characterized in that The step of determining input data of a preset traffic prediction model according to the current API request traffic and the API request traffic in a first preset time period before the current time includes: According to the current API request traffic and the API request traffic in a first preset time period before the current time, determine an API request basic data sequence, an API request time dimension data sequence, and an API request pattern data sequence, wherein the API request basic data includes request quantity data and / or request type data, the API request time dimension data includes request time data and / or request date data, and the API request pattern data includes at least one of request device type data, request geographic location data, and new and old user identification data; Based on the current time, external event information is obtained, and the external event information, the API request basic data sequence, the API request time dimension data sequence, and the API request mode data sequence are used as the input data, wherein the external event information includes at least one of a promotion activity, a version release, and a news event; Accordingly, based on the input data, the predicted traffic trend data within the second preset time period is obtained through the preset traffic prediction model, including: The input data is input into the preset traffic prediction model, and the external event features corresponding to the external event information, as well as the API request basic data features, API request time dimension data features, and API request pattern data features are respectively extracted through the preset traffic prediction model, and based on the external event features, API request basic data features, API request time dimension data features, and API request pattern data features, fused data features are obtained, and based on the fused data features, the predicted traffic trend data within a second preset time period is determined.

3. The method according to claim 2, characterized in that When the current performance data includes current load data and current response time, dynamically updating the current request routing strategy according to the current performance data of each server in the target server cluster includes: Calculate the weight of each server according to the current load data and current response time of each server in the target server cluster; According to the weights, the request allocation ratio corresponding to each server is calculated respectively, and based on the request allocation ratio, the current request routing strategy is updated.

4. The method according to claim 3, characterized in that: The routing of subsequent API requests based on the updated request routing strategy includes: When an API request is received, identifying an importance level corresponding to the API request, and adding the API request to a request queue of a corresponding priority based on the importance level; According to the request allocation ratio corresponding to each server in the updated request routing strategy, and the order of priority corresponding to each request queue from high to low, the API requests stored in each request queue are polled according to the request allocation ratio.

5. The method according to any one of claims 1 to 4, characterized in that The method further comprises: Monitor in real time the number of pending API requests corresponding to each server in the target server cluster; When the number of pending API requests corresponding to any server is greater than a first preset number threshold, and the current performance data corresponding to any server indicates that the request processing performance of any server does not meet the preset request allocation conditions, the server identifier corresponding to any server is removed from the current request routing policy, and subsequent API requests are routed based on the request routing policy after removal; and, when the number of pending API requests corresponding to any server is less than or equal to a second preset number threshold, and the current performance data corresponding to any server indicates that the request processing performance of any server meets the preset request allocation conditions, the current request routing policy is dynamically updated based on the current performance data of each server in the target server cluster.

6. The method according to claim 1, characterized in that The method further comprises: Counting the request objects corresponding to the historical API requests within the third preset time period according to the preset period, and counting the request frequency corresponding to each request object; Storing request objects whose request frequency is greater than a preset frequency in a preset cache space; Accordingly, the method further comprises: When an API request is received, it is determined whether the request object corresponding to the API request is stored in the preset cache space, and if the result is yes, the API request is routed to the preset cache space, otherwise, the API request is routed based on the current request routing policy.

7. The method according to claim 1, characterized in that After routing subsequent API requests based on the updated request routing strategy, the method further includes: The execution of the updated request routing policy is monitored in real time, and when an abnormal event is monitored, a configuration rollback function is executed to replace the updated request routing policy with the request routing policy before the update.

8. A routing device for API requests, characterized in that: include: A request traffic monitoring module, used to monitor the current API request traffic of the target server cluster and the current performance data of each server in the target server cluster in real time, wherein the current performance data includes current load data and / or current response time; A traffic trend prediction module, used to determine input data of a preset traffic prediction model according to the current API request traffic and the API request traffic in a first preset time period before the current time, and based on the input data, obtain predicted traffic trend data in a second preset time period through the preset traffic prediction model; A routing strategy update module is used to determine the traffic peak value within the second preset time period based on the predicted traffic trend data. When the traffic peak value is greater than the preset peak threshold, the current request routing strategy is dynamically updated according to the current performance data of each server in the target server cluster, and subsequent API requests are routed based on the updated request routing strategy.

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

10. A computer device comprising a storage medium, a processor, and a computer program stored in the storage medium and executable on the processor, characterized in that: When the processor executes the computer program, the method according to any one of claims 1 to 7 is implemented.

Images