Method and device for collecting and analyzing API call status based on multi-tenant SaaS gateway

Abstract

The present invention provides a method and device for collecting and analyzing API call situations based on a multi-tenant SaaS gateway, and relates to the field of communication technology. The present invention obtains the observation value results of an autoregressive AR model, conducts in-depth analysis on API call data, improves the accuracy of feature extraction, establishes a prediction scoring model S(t), predicts API traffic patterns, generates an automatic adjustment scaling strategy to cope with peak hours, obtains scaling rules set by the automatic adjustment scaling strategy to determine performance indicators, and automatically performs resource adjustment through a cloud platform API based on the scaling rules. According to monitoring results and performance indicators, the accuracy of scaling rules and resource utilization are predicted. Finally, according to the predicted scaling rule accuracy and resource utilization, the prediction scoring model S(t) and scaling rules are continuously optimized to identify and evaluate API call patterns, improve system efficiency and response speed, self-adjust according to actual conditions, and improve prediction accuracy and resource utilization efficiency.

Description

Technical Field

[0001] The present invention relates to the field of communication technology, and in particular to a method and device for collecting and analyzing API call situations based on a multi-tenant SaaS gateway. Background Art

[0002] In the online ride-hailing platform, multi-tenants can represent different service providers or business partners, sharing the same SaaS gateway system, which helps operators understand the call status of different business interfaces through the following key steps and technologies:

[0003] Multi-tenant architecture: Each service provider acts as a tenant in the online ride-hailing platform and shares the same application instance, but their operational data and configurations are isolated from each other to ensure that their respective businesses run independently;

[0004] API Gateway: Introduce a dedicated API gateway as the entry point for all business interface calls, responsible for processing and routing business requests from different service providers, and realizing centralized management of business interfaces;

[0005] Call collection: The gateway centrally collects the service interface call data of all service providers entering the system, including detailed information of requests and responses, so as to fully understand the usage of each service interface;

[0006] Real-time monitoring: Use real-time monitoring tools to monitor business interfaces in real time, capture system performance, errors, and abnormal situations, and help operators discover and solve problems in a timely manner;

[0007] Logging: Record detailed logs of business interface calls, including request parameters, response data, call time and other information to support auditing, troubleshooting and problem tracking;

[0008] Multi-tenant isolation: ensures that the business data and operations of different service providers are isolated from each other, maintaining data security and privacy;

[0009] Analysis and reporting: Use analytical tools to analyze the collected business interface call data, generate reports and visualizations, and help operations personnel understand the business activities of each service provider on the platform, optimize bottlenecks, and improve services;

[0010] Through this method, operators of online ride-hailing platforms can fully understand the calling status of different business interfaces, improve their control over platform operations, and ensure efficient, safe and reliable service operations.

[0011] For example, the Chinese patent with announcement number CN115834481A discloses a method and device for implementing an API gateway based on a SAAS cloud platform, wherein the method includes: the tenant subscribes to the API gateway service from the SAAS cloud platform; the SAAS cloud platform allocates the forwarding plane resources, control plane resources, network resources and database resources of the API gateway to the tenant according to the API gateway service subscribed by the tenant; the tenant configures and manages the API gateway through the access method provided by the SAAS cloud platform, publishes the domain name and API to the outside through the control system of the SAAS cloud platform, and monitors the life cycle of the API; the tenant's traffic is pulled to the API gateway based on the SAAS cloud platform through CNAME, and the API gateway implements proxy and security protection for the tenant's external API. The method and device implement API gateway based on the SAAS cloud platform, improves resource utilization and reduces the cost of resource deployment.

[0012] The shortcomings are as follows: The patent with announcement number CN115834481A only describes how to implement the application process of API gateway based on SAAS cloud platform, but does not solve the following problems:

[0013] How to use machine learning technology to predict API traffic patterns, automatically adjust scaling strategies to cope with peak hours, and optimize system performance and reduce response delays are the areas that need improvement at present;

[0014] The above information disclosed in this Background section is only for enhancement of understanding of the background of the present disclosure and therefore it may contain information that does not constitute the prior art that is already known to one of ordinary skill in the art. Summary of the invention

[0015] The purpose of the present invention is to provide a method and device for collecting and analyzing API call situations based on a multi-tenant SaaS gateway to solve the problems raised in the above background technology.

[0016] To achieve the above object, the present invention provides the following technical solutions:

[0017] A method for collecting and analyzing API call status based on a multi-tenant SaaS gateway, the specific steps include:

[0018] S1. Collect API call history data, resource usage data, and external factor data related to the current time t of multiple tenants based on the SaaS gateway, pre-process the collected data through the data cleaning algorithm, extract features from the pre-processed data through feature extraction, use the autoregressive AR model in the time series analysis technology to process the extracted features and generate observation results, and determine the trend and seasonality of API call frequency through the observation results;

[0019] S2. Obtain the observation results of the autoregressive AR model, establish a prediction scoring model S(t) to predict the API traffic pattern, and generate an automatic adjustment scaling strategy to cope with the API call demand during peak hours;

[0020] S3. Obtain the scaling rules set by the automatic adjustment scaling strategy to determine the performance indicators, and automatically perform resource adjustments through the cloud platform API based on the scaling rules, obtain the predicted traffic output by the prediction scoring model S(t), compare the actual traffic with the predicted traffic and record the effect of resource adjustment to generate monitoring results, and predict the accuracy of the scaling rules and resource utilization based on the monitoring results and performance indicators. Finally, continuously optimize the prediction scoring model S(t) and scaling rules based on the predicted accuracy of the scaling rules and resource utilization to identify and evaluate API call patterns.

[0021] A device for collecting and analyzing API call situations based on a multi-tenant SaaS gateway, the device being used to execute the method described, comprising:

[0022] Data collection and feature engineering module: Based on the SaaS gateway, it collects API call history data, resource usage data, and external factor data related to the current time t of multiple tenants, and pre-processes the collected data through the data cleaning algorithm. Then, it extracts features from the pre-processed data through feature extraction. The autoregressive AR model in the time series analysis technology is used to process the extracted features and generate observation results. The trend and seasonality of the API call frequency are determined through the observation results.

[0023] Model building and traffic prediction module: obtains the observation results of the autoregressive AR model, builds a prediction scoring model S(t) to predict the API traffic pattern, and generates an automatic adjustment scaling strategy to cope with the API call demand during peak hours;

[0024] Automatic scaling strategy and continuous optimization module: obtain the scaling rules set by the automatic adjustment scaling strategy to determine the performance indicators, and automatically perform resource adjustments through the cloud platform API based on the scaling rules, obtain the predicted traffic output by the prediction scoring model S(t), compare the actual traffic with the predicted traffic and record the effect of resource adjustment to generate monitoring results, and predict the accuracy of scaling rules and resource utilization based on the monitoring results and performance indicators. Finally, the prediction scoring model S(t) and scaling rules are continuously optimized based on the predicted accuracy of scaling rules and resource utilization to identify and evaluate API call patterns.

[0025] Compared with the prior art, the present invention has the following beneficial effects:

[0026] By using the autoregressive AR model in the time series analysis technology to process the extracted features and generate observation results, the observation results of the autoregressive AR model are obtained, the API call data is deeply analyzed to improve the accuracy of feature extraction, and a prediction scoring model S(t) is established to predict the API traffic pattern and generate an automatic adjustment scaling strategy to cope with peak hours. The scaling rules set by the automatic adjustment scaling strategy are obtained to determine the performance indicators, and the resource adjustment is automatically performed through the cloud platform API based on the scaling rules. Based on the prediction scoring model S(t), the actual traffic is compared with the predicted traffic and the effect of the resource adjustment is recorded to generate monitoring results. According to the monitoring results and performance indicators, the accuracy of the scaling rules and the resource utilization are predicted. Finally, the prediction scoring model S(t) and the scaling rules are continuously optimized according to the predicted scaling rule accuracy and resource utilization to identify and evaluate the API call pattern, continuously optimize the resource allocation strategy, improve the efficiency and response speed of the system, and self-adjust according to the actual situation to improve the accuracy of the prediction and the efficiency of resource utilization. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] Figure 1 It is a schematic diagram of the overall method flow of the present invention;

[0028] Figure 2 It is a block diagram of the device logic module of the present invention. DETAILED DESCRIPTION

[0029] In order to make the objectives, technical solutions and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with specific embodiments.

[0030] It should be noted that, unless otherwise defined, the technical terms or scientific terms used in the present invention should be understood by people with ordinary skills in the field to which the present invention belongs. The words "first", "second" and similar words used in the present invention do not indicate any order, quantity or importance, but are only used to distinguish different components. "Include" or "comprise" and similar words mean that the elements or objects appearing before the word include the elements or objects listed after the word and their equivalents, without excluding other elements or objects. "Connect" or "connected" and similar words are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. "Up", "down", "left", "right" and the like are only used to indicate relative positional relationships. When the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0031] See also Figure 1 and Figure 2 , the present invention provides a technical solution:

[0032] Embodiment 1:

[0033] A method for collecting and analyzing API call situations based on a multi-tenant SaaS gateway, the specific steps include:

[0034] S1. Collect API call history data, resource usage data, and external factor data related to the current time t of multiple tenants based on the SaaS gateway, pre-process the collected data through the data cleaning algorithm, extract features from the pre-processed data through feature extraction, use the autoregressive AR model in the time series analysis technology to process the extracted features and generate observation results, and determine the trend and seasonality of API call frequency through the observation results;

[0035] S2. Obtain the observation results of the autoregressive AR model and establish a prediction scoring model S(t) to predict the API traffic pattern and generate an automatic adjustment scaling strategy to cope with the API call demand during peak hours, while optimizing system performance and reducing response delays;

[0036] S3. Obtain the scaling rules set by the automatic adjustment scaling strategy to determine the performance indicators, and automatically perform resource adjustments through the cloud platform API based on the scaling rules, obtain the predicted traffic output by the prediction scoring model S(t), compare the actual traffic with the predicted traffic and record the effect of resource adjustment to generate monitoring results, and predict the accuracy of the scaling rules and resource utilization based on the monitoring results and performance indicators. Finally, continuously optimize the prediction scoring model S(t) and scaling rules based on the predicted accuracy of the scaling rules and resource utilization to identify and evaluate API call patterns.

[0037] Embodiment 2:

[0038] Further explanation based on the first embodiment, the SaaS gateway-based collection of multi-tenant API call history data, resource usage data, and external factor data related to the current time t specifically includes the following:

[0039] The API call history data collected from multiple tenants includes: request timestamp, duration, request type and status. The acquisition steps are:

[0040] Timestamp and duration: record the start and end time of each API request. The timestamp is obtained from the system log or API gateway.

[0041] Request type and status: Categorize and record API functions (such as data query and update) and response status (such as success and error) in the API gateway or service log;

[0042] The resource usage data collection includes using system monitoring tools (such as Nagios, Prometheus) to record the CPU utilization and memory usage at each time point in real time;

[0043] The collecting of external factor data related to the current time t includes the distance between the current timestamp t and a specific season or holiday;

[0044] The acquisition steps are:

[0045] External factor analysis: Collect relevant external factor data, including season and holiday information, which can be obtained from the calendar API or dedicated date and time libraries (such as Python's pandas library);

[0046] The distance between the current request timestamp T and a specific season or holiday, the specific acquisition steps are:

[0047] Step 1: Calculate the time difference between the current timestamp T and the most recent or most recent past season or holiday, and incorporate this information into the analysis;

[0048] Step 2: Calculate the time difference between seasons:

[0049] 2.1. Get the season of the current timestamp, such as spring, summer, autumn, and winter;

[0050] 2.2. Calculate the time difference to the next or previous specific season;

[0051] Example: If the current date is January 15, 2024, the season is winter, and the time difference to the next season, spring, is 2 months;

[0052] Step 3: Calculate the time difference of holidays:

[0053] 3.1. Get the nearest holiday date;

[0054] 3.2. Calculate the time difference between the current timestamp and the date;

[0055] Example: If the current date is May 1, 2024, and the nearest holiday is Labor Day, on May 1, the time difference between the current timestamp and Labor Day is 0 days;

[0056] Step 4. Give examples of seasons or holidays:

[0057] Examples of seasons:

[0058] Spring: March 20th - June 20th

[0059] Summer: June 21st - September 22nd

[0060] Autumn: September 23 - December 21

[0061] Winter: December 22 - March 19

[0062] Examples of holidays: New Year's Day: January 1, National Day: October 1, Thanksgiving: the fourth Thursday of November in the United States;

[0063] When selecting the above seasons or holidays, you can select any one of them as the distance between the current request timestamp T and a specific season or holiday, or you can first select the season to understand the changes in the API call history data and resource usage, and then determine the distance to the nearest holiday to obtain more accurate API call history data and resource usage data;

[0064] Through such analysis, the system can understand whether there are changes in API call history data and resource usage during different seasons or holidays. For example, during holidays, users may have more query demands, while more computing resources may be required in winter to cope with peak hours.

[0065] Embodiment three:

[0066] Further explanation is given on the basis of the second embodiment, the collected data is preprocessed by a data cleaning algorithm, specifically including:

[0067] For missing value interpolation and outlier detection in the collected data, and data standardization, the MinMaxScaler method is used to convert the API call history data, resource usage data, and external factor data into values ​​within the range of 0-1 to eliminate the impact of dimension and unify the data format;

[0068] The specific steps are:

[0069] Step 1: Missing value interpolation and outlier detection

[0070] Missing value interpolation: Use the mean, median, or interpolation algorithm to fill in missing values ​​in API call history data and resource usage data;

[0071] Outlier detection: Use statistical methods or machine learning algorithms to detect outliers to ensure data quality. Specifically, use Z-score and IQR methods to identify and process outliers.

[0072] Step 2: Data Standardization

[0073] Timestamps and Durations: Timestamps are processed and converted to date and time formats, durations can be kept in their original format or converted to seconds;

[0074] Request type and status: Encode categorical data independently or encode labels to ensure that machine learning algorithms can understand these non-numeric data;

[0075] Resource usage data: CPU utilization, memory usage, etc. are standardized to conform to the normal distribution, using the Z-score standardization method;

[0076] Step 3: Min-Max Scaling

[0077] Use the MinMaxScaler method to convert the standardized API call history data, resource usage data, and external factor data into values ​​in the range of 0-1 to eliminate the dimensional impact of different features and unify the data format;

[0078] The formula for Min-Max scaling is:

[0079]

[0080] Among them, X is the original data, X min and X max are the minimum and maximum values ​​of the data respectively;

[0081] The feature extraction is used to extract features from the preprocessed data, and the autoregressive AR model in the time series analysis technology is used to process the extracted features and generate observation results. The trend and seasonality of the API call frequency are determined by the observation results, which specifically includes the following contents:

[0082] The AR model of the autoregressive model is used to analyze the trend and seasonality of the API call frequency. The formula of the AR model is:

[0083]

[0084] Where X t is the observed value at the current moment, that is, the value of the API call frequency at time point t;

[0085] c: is a constant term, representing the intercept or base level of the model;

[0086] φ i : is the autoregressive coefficient, which indicates the relationship between the observed value at time ti and the current observed value X t The influence of , where i ranges from 1 to p, where p is the order of the model;

[0087] X t-i : is the observed value at time ti;

[0088] μ3 t : is the error term, which represents the random part that cannot be explained by the model, that is, the current observation value Xt The residuals from the predicted values ​​of the AR model;

[0089] The formula for calculating the average response time is:

[0090]

[0091] The standard deviation formula is:

[0092]

[0093] Where n represents the total number of observations;

[0094] Trend and seasonality analysis:

[0095] Trend analysis: Check the constant term c and autoregressive coefficient φ in the AR model i The sign and size of the trend to determine its direction and strength;

[0096] Seasonality analysis: Observe the autoregression coefficient φ i The periodicity of the regression model determines the presence of seasonality, which manifests itself as a repetitive pattern of the autoregressive coefficients at certain specific lag orders.

[0097] Specifically, check the constant term c:

[0098] Symbols: The constant term c represents the intercept or base level of the model, a positive value indicates an upward trend, a negative value indicates a downward trend, and zero indicates no constant term;

[0099] Size: The larger the absolute value of c, the stronger the trend. By comparing the size of c, we can understand the relative strength of the trend.

[0100] Check the autoregressive coefficient φ i :

[0101] Symbol: Autoregressive coefficient φ i Indicates the impact of past observations on current observations. A positive value indicates a positive correlation, and a negative value indicates a negative correlation. By observing the sign, you can understand the direction of the trend.

[0102] Size: The larger the absolute value of the autoregressive coefficient, the greater the influence of past observations on the current observations. By comparing φ i The size of the trend can help you understand the relative strength of the trend.

[0103] Embodiment 4:

[0104] Further explanation based on the third embodiment, the observation results of the autoregressive AR model are obtained to establish a prediction scoring model S(t), and the specific logic includes:

[0105] The prediction scoring model S(t) formula is as follows:

[0106]

[0107] in:

[0108] S(t) represents the system performance score at the current time t;

[0109] e is the base of the natural logarithm; k is a normalization coefficient used to balance the influence of the summation function;

[0110] D(t') represents the historical data of API calls at time t', including the timestamp, duration, request type and status of the request;

[0111] f(D(t′),λ): is a high-level integral function used to evaluate the pattern and frequency of API usage at time t′, analyze API usage patterns, and help predict future traffic trends;

[0112] C i (t): indicates the resource usage at the current time t, including CPU utilization and memory usage data;

[0113] g(C i (t),α i ): is a summation function used to analyze resource usage C i (t) Impact on system performance;

[0114] h(T j ,β,γ): is a complex information filtering function used to analyze external factors T j (e.g. seasonal changes, holidays) on API calls, β and γ are the parameters of the function;

[0115] Φ: is the normal cumulative distribution function, which is used to model the impact of historical scaling activities on system performance;

[0116] R(t): indicates the historical scaling activity record corresponding to the time period of the day at the current time t, recording the time, scale and effect of each resource scaling;

[0117] R: represents the recorded value of historical scaling activity, μ and σ2 are the mean and standard deviation of R respectively;

[0118] X t : is the AR model observation value at the current time t;

[0119] x: average value of response time;

[0120] σ1: standard deviation of response time;

[0121] S(t) range explanation:

[0122] The value range of S(t) is [0,∞), which represents the system performance score at time t. The larger the value, the better the system performance.

[0123] The corresponding data is analyzed through functions f, g, and h to predict and optimize system performance and reduce response delay.

[0124] Embodiment five:

[0125] Further explanation based on the fourth embodiment, the acquisition of D(t') includes the following steps:

[0126] Assume that in time period t', data of N API calls are collected. For each call i, we record the following data:

[0127] T i : Timestamp of the request; ΔT i : Duration of the request; R i : The type of request is coded with numbers, and GET=1, POST=2, S i : Request status, set 200 for success, 500 for server error;

[0128] GET request:

[0129] Purpose: Used to request data from the server, usually used to obtain resources. GET requests should be idempotent, that is, multiple requests to the same resource should return the same result;

[0130] OST Request:

[0131] Purpose: Used to submit data to the server for processing, usually used to create new resources on the server;

[0132] Denote D(t') as a set containing the data of all API calls within time t', and obtain the following formula:

[0133] D(t′)=(T1,ΔT1,R1,S1),(T2,ΔT2,R2,S2),...(T i ,ΔT i ,R i ,S i )...,(T N ,ΔT N ,R N ,S N )

[0134] Among them, λ is a parameter used to adjust the influence of D(t') in the f function;

[0135] The acquisition of f(D(t′),λ) comprises the following steps:

[0136] The function f(D(t′),λ) will be calculated based on the historical data D(t′) of the API call and the adjustment parameter λ;

[0137] Assume that the calculation formula of f is:

[0138]

[0139] in:

[0140] w(T i ,λ) is a weight function used to adjust the parameter λ and the timestamp T i Adjust the influence of each call; make the most recent call have a greater weight, the weight function is an exponential decay form, expressed as follows:

[0141]

[0142] Where t: represents the current time;

[0143] g(ΔT i ,R i ,S i ): It is a scoring function that scores each call based on the duration, type and status of the request. The scoring rule is set as follows: longer response time or failed status gets lower scores.

[0144] This example aims to verify the effectiveness of the proposed prediction scoring model S(t) in API traffic management and system performance optimization. The core of the model is to use historical API call data to predict future traffic trends. The experimental environment settings are:

[0145] Build a simulated API service environment that can simulate different types of API requests and record necessary data;

[0146] The experiment time was set to 3 hours, during which API call requests were automatically generated, covering both peak and off-peak periods;

[0147] Data Collection:

[0148] For each API request, the following information is recorded:

[0149] T i : Timestamp of the request;

[0150] ΔT i : Duration of the request;

[0151] R i : Set the request type to GET=1, POST=2;

[0152] S i: The request status is set to 200 for success and 500 for server error;

[0153] Implementation steps:

[0154] Apply the S(t) model to calculate the system performance score for each API call;

[0155] A traditional static resource allocation system was also run as a comparison group;

[0156] Compare the performance of the two systems in terms of response time, resource utilization efficiency, and system performance score;

[0157] Table 1 below shows the data recorded in the simulation experiment. Each row represents an API call instance, including the necessary parameters and the system performance scores under the two methods;

[0158]

[0159] Table 1

[0160] Data analysis

[0161] Improvements in performance scores:

[0162] The performance scores of the S(t) model at each time point are generally higher than those of the traditional method, which shows that the model can effectively predict traffic trends based on historical data and dynamically adjust resources;

[0163] Reduction in response time:

[0164] During the peak period of API requests, the S(t) model shows a shorter response time, which reflects its excellent traffic prediction ability and resource adjustment strategy;

[0165] Optimization of resource usage:

[0166] Compared with traditional methods, the S(t) model is more efficient in CPU utilization and memory usage, especially when the number of requests is large, it can allocate resources more reasonably;

[0167] The embodiment of innovation and novelty:

[0168] The S(t) model innovatively optimizes resource allocation and system performance by combining historical API call data and resource usage, which is impossible to achieve with traditional methods, especially in dealing with traffic forecasting and dynamic resource adjustment during peak hours.

[0169] Through data analysis, it can be clearly seen that the S(t) model has made great progress in reducing response delays and improving system performance compared to existing technologies.

[0170] Embodiment six:

[0171] Further explanation is given on the basis of Example 4, the C i The acquisition of (t) comprises the following steps:

[0172] Assuming that CPU utilization and memory usage data are the main resources, the design for each resource i is as follows:

[0173] CPU t : CPU utilization at time t, expressed in %;

[0174] MEM t : Memory usage at time t, expressed in GB;

[0175] Then C i (t) is expressed as:

[0176] [C i (t) = {CPU t for i=1MEM t for i=2]

[0177] The g(C i (t),α i ) includes the following steps:

[0178] The calculation formula is as follows:

[0179]

[0180] where α i It is a coefficient used to adjust the importance of CPU utilization and memory usage data on system performance. For example, for CPU utilization, α1 is greater than α2 for memory usage;

[0181] This example aims to demonstrate the innovation and advantages of the model in predicting API traffic patterns, automatically adjusting scaling strategies to cope with peak hours, and optimizing system performance to reduce response latency;

[0182] Experimental setup:

[0183] Build a simulated server environment to simulate and record API traffic and system resource usage;

[0184] The experimental time span is set to one week to capture the traffic changes in different time periods;

[0185] Data Collection:

[0186] Collect historical data D(t') of API calls, including request timestamp, duration, type, and status;

[0187] Real-time monitoring and recording of system resource usage, such as CPU utilization t and memory usage MEM t ;

[0188] Implementation steps:

[0189] Apply the S(t) model to predict future API traffic patterns and dynamically adjust resources;

[0190] The control group used a traditional static resource allocation strategy;

[0191] Compare the two groups in terms of system performance, response time, and resource usage efficiency;

[0192] Table 2 records the key data during the experiment, including the details of the API requests and the performance scores under the two strategies;

[0193]

[0194] Table 2

[0195] Data analysis

[0196] Significant improvement in system performance:

[0197] As can be seen from the table, the performance scores of the S(t) model are generally higher than those of the traditional method, which proves the effectiveness of the model in predicting traffic and dynamically adjusting resources. Especially during peak hours, the model can significantly optimize system performance.

[0198] Significant reduction in response time:

[0199] During the peak period of API requests, the S(t) model shows a shorter response time, which shows that the model can effectively predict traffic trends based on historical data and adjust resources in time to cope with traffic peaks;

[0200] Optimization of resource utilization efficiency:

[0201] Comparing the CPU utilization and memory usage of the two methods, the S(t) model uses resources more efficiently while maintaining high system performance. Especially during traffic peaks, the model can allocate CPU and memory resources more reasonably to avoid resource waste.

[0202] Demonstration of creativity and novelty:

[0203] Compared with the traditional static resource allocation method, the S(t) model provides more accurate data support for system performance optimization by comprehensively considering historical API call data, resource usage and external factors. This method shows significant innovation and novelty in dynamic resource allocation, predicting traffic trends and reducing response delays.

[0204] Through these data analysis, we can clearly see the obvious advantages of the S(t) model over existing technologies in improving system performance, optimizing resource allocation, and reducing response time.

[0205] Embodiment seven:

[0206] Further explanation based on Example 4, the h(T j The acquisition of ,β,γ) includes the following steps:

[0207] Programming to implement h(T j ,β,γ) function, using the input external factor data T j , combined with the set parameters β and γ, calculate their impact on API calls;

[0208] Define h(T j ,β,γ) is a weighted function, and the following formula is obtained by taking into account the time-related factors:

[0209] h(T j ,β,γ)=β·e γ·J

[0210] in:

[0211] J represents the time-related factor, which represents the distance between the current time and a specific season or holiday;

[0212] β and γ are influencing parameters, which are used to adjust the influence of time factors on system performance. β and γ are adaptively adjusted according to historical API call data, which will not be described in detail.

[0213] h(T j ,β,γ) depends on the values ​​of β and γ and is a positive number used to adjust the impact of external time factors on API performance.

[0214] Embodiment eight:

[0215] Further illustrating on the basis of the fourth embodiment, the step of obtaining Φ includes the following contents:

[0216] The formula for defining the normal cumulative distribution function Φ(x) is as follows:

[0217]

[0218] Where erf(x) is the error function, defined as:

[0219]

[0220] The value range of Φ(x) is [0,1], which provides a smooth way to consider the relationship between historical data and current data. The larger the value, the greater the impact of simulated historical scaling activities on system performance.

[0221] Embodiment nine:

[0222] Further explanation is given on the basis of Example 4, the scaling rules set by the automatic adjustment scaling strategy are obtained to determine the performance indicators, and the resource adjustment is automatically performed through the cloud platform API based on the scaling rules, the predicted traffic output by the prediction scoring model S(t) is obtained, the actual traffic is compared with the predicted traffic and the effect of the resource adjustment is recorded to generate the monitoring results, and the accuracy of the scaling rules and the resource utilization are predicted according to the monitoring results and the performance indicators. Finally, the prediction scoring model S(t) and the scaling rules are continuously optimized according to the predicted accuracy of the scaling rules and the resource utilization to identify and evaluate the API call mode, which specifically includes the following contents:

[0223] Automatically adjust the scaling policy to set scaling rules: if the predicted traffic exceeds 80% of the current capacity, automatically increase resources, such as adding API gateway instances;

[0224] The automatic resource adjustment using the cloud platform API is based on the automatic expansion function of AWS or Azure cloud services;

[0225] The identification and evaluation of API call patterns includes the following:

[0226] a. Peak and trough periods: The predictive scoring model S(t) identifies the peak and trough periods of each day by analyzing the historical API call data (D(t')), which is achieved by evaluating the request frequency and type in different time periods;

[0227] The specific judgment criteria are:

[0228] Threshold setting: Set the peak threshold and trough threshold to be λ respectively. Gf , Dg ;

[0229] Peak threshold λ Gf : When the API request frequency exceeds 1,000 times per minute or the proportion of data queries in the request type exceeds 80%, it is considered a peak period;

[0230] Valley threshold λ Dg :When the API request frequency is less than 200 times per minute, and the proportion of data update requests is less than 20%, it is considered a low period;

[0231] Interaction effect: The system calculates the frequency and type of current API requests in real time, compares them with the peak and trough thresholds, and dynamically identifies the peak or trough periods;

[0232] b. Periodic patterns: The predictive scoring model S(t) identifies periodic patterns, such as weekly or monthly recurring patterns, obtained by observing the request data D(t') over a long period of time;

[0233] The specific judgment criteria are:

[0234] Periodic pattern identification: By analyzing the data from the past three months, a periodic pattern was identified in which the average number of API requests per hour on weekdays was 500, while on weekends it was 300.

[0235] Interaction effect: The system predicts the next API request trend based on the identified periodic patterns and adjusts resources accordingly;

[0236] c. Evaluate API call frequency: The prediction scoring model S(t) comprehensively considers the frequency of API calls through the f(D(t′),λ) function, including the call frequency per second, per minute, or per hour;

[0237] The specific judgment criteria are:

[0238] Frequency assessment: set the number of API calls per second, per minute, and per hour. If the number of requests exceeds 50 per second, it is considered high frequency.

[0239] The interactive effect is: according to the change of API call frequency, the system adjusts the calculation prediction scoring model S(t) in real time, which is reflected in the system performance score;

[0240] Automatic adjustment of scaling policies:

[0241] The peak scaling threshold and the trough scaling threshold are set as S Gf , S Dg ;

[0242] Set when the value of S(t) exceeds the set peak scaling threshold S Gf When , it indicates that the peak period has arrived, and the model will automatically trigger dynamic adjustments such as adding server instances;

[0243] When the value of S(t) is lower than the set valley scaling threshold S Dg When , it indicates that the peak period has arrived, and the model will automatically trigger dynamic adjustments such as reducing server instances.

[0244] This adjustment is based on S(t)’s continuous monitoring and evaluation of API usage patterns and frequency;

[0245] The specific judgment criteria are:

[0246] Scaling threshold setting: Peak scaling threshold S Gf : Set to trigger dynamic adjustment of additional resources when the system performance score reaches 80 points;

[0247] Trough scaling threshold S Dg : When the system performance score drops below 40 points, dynamic adjustment to reduce resources is triggered;

[0248] The interactive effect is: the system automatically increases or decreases server instances based on the comparison of S(t) calculated in real time with the preset threshold, thereby optimizing resource utilization.

[0249] This example aims to verify and demonstrate our automatic scaling strategy and its superiority in API management. The experiment includes two main parts: automatic resource adjustment test based on cloud platform, and system monitoring and model optimization test;

[0250] Automatic resource adjustment test based on cloud platform:

[0251] Set up the cloud environment: Select AWS as the cloud platform and configure the required API gateway instances and monitoring systems;

[0252] Scaling rule definition: Set peak and valley thresholds, such as the peak threshold is more than 1,000 API requests per minute or the query ratio is more than 80%, and the valley threshold is less than 200 API requests per minute and the update request ratio is less than 20%;

[0253] Test scenario simulation: Generate different patterns of API requests through simulation tools, such as periodic patterns (weekdays and weekends) and different request frequencies (every second, every minute, every hour).

[0254] Scaling strategy execution: The monitoring system calculates the current API request frequency and type in real time, and automatically triggers the strategy of increasing or decreasing server instances when it reaches or falls below the preset peak and valley thresholds;

[0255] System monitoring and model optimization testing:

[0256] Real-time monitoring settings: ensure that the system can monitor actual traffic and predicted traffic in real time, as well as the effect of resource allocation;

[0257] Performance indicator evaluation: collect indicator data such as prediction accuracy and resource utilization;

[0258] Model optimization: Based on monitoring results, continuously adjust the prediction model and scaling rules to improve efficiency and accuracy;

[0259]

[0260] Table 3

[0261] Data analysis: From the above table, we can clearly see that the embodiment system is superior to the traditional API management system in various performance indicators, especially in the recognition accuracy during peak hours and off-peak hours. The embodiment system is 15-20 percentage points higher than the traditional system, which shows that our prediction scoring model can more accurately identify different traffic patterns;

[0262] In terms of resource adjustment, the scaling response score of the embodiment system is significantly shorter than that of the traditional system, with an average reduction of 83 points, which means that our system can respond to traffic changes more quickly, thereby improving user experience and system efficiency;

[0263] Resource utilization and system performance scores are also key indicators for measuring the innovation and advantages of our invention. The resource utilization of the implementation example system has increased by an average of 20-30 percentage points, and the system performance score has improved.

[0264] Embodiment ten:

[0265] A device for collecting and analyzing API call situations based on a multi-tenant SaaS gateway, the device being used to execute the method described, comprising:

[0266] Data collection and feature engineering module: Based on the SaaS gateway, it collects API call history data, resource usage data, and external factor data related to the current time t of multiple tenants, and pre-processes the collected data through the data cleaning algorithm. Then, it extracts features from the pre-processed data through feature extraction. The autoregressive AR model in the time series analysis technology is used to process the extracted features and generate observation results. The trend and seasonality of the API call frequency are determined through the observation results.

[0267] Model building and traffic prediction module: obtains the observation results of the autoregressive AR model, builds a prediction scoring model S(t) to predict the API traffic pattern, and generates an automatic adjustment scaling strategy to cope with the API call demand during peak hours;

[0268] Automatic scaling strategy and continuous optimization module: obtain the scaling rules set by the automatic adjustment scaling strategy to determine the performance indicators, and automatically perform resource adjustments through the cloud platform API based on the scaling rules, obtain the predicted traffic output by the prediction scoring model S(t), compare the actual traffic with the predicted traffic and record the effect of resource adjustment to generate monitoring results, and predict the accuracy of scaling rules and resource utilization based on the monitoring results and performance indicators. Finally, the prediction scoring model S(t) and scaling rules are continuously optimized based on the predicted accuracy of scaling rules and resource utilization to identify and evaluate API call patterns.

[0269] The above formulas are all dimensionless and numerical calculations. The formula is a formula for the most recent real situation obtained by collecting a large amount of data and performing software simulation. The preset parameters in the formula are set by technicians in this field according to actual conditions.

[0270] The specific values ​​of δ, ε, σ, etc. in the formula are generally determined by those skilled in the art according to actual conditions. The essence of the formula of the present application is to perform comprehensive analysis by weighted summation. Those skilled in the art collect multiple groups of sample data and set corresponding preset proportional coefficients for each group of sample data; substitute the preset proportional coefficients and the collected sample data into the formula, and any four formulas constitute a set of four-variable linear equations. The calculated coefficients are screened and averaged to obtain the values ​​of δ, ε, σ, etc.;

[0271] The above embodiments may be implemented in whole or in part by software, hardware, firmware or any other combination thereof. When implemented using software, the above embodiments may be implemented in whole or in part in the form of a computer program product. Those skilled in the art may appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein may be implemented by computer software, electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed by hardware or software depends on the specific application and design constraints of the technical solution.

[0272] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, and may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0273] The above description is only a specific implementation manner of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application.

Claims

1. A method for collecting and analyzing API call situations based on a multi-tenant SaaS gateway, characterized in that: The specific steps include: S1. Collect API call history data, resource usage data, and external factor data related to the current time t of multiple tenants based on the SaaS gateway, pre-process the collected data through the data cleaning algorithm, extract features from the pre-processed data through feature extraction, use the autoregressive AR model in the time series analysis technology to process the extracted features and generate observation results, and determine the trend and seasonality of API call frequency through the observation results; For missing value interpolation and outlier detection in the collected data, and data standardization, the MinMaxScaler method is used to convert the API call history data, resource usage data, and external factor data into values ​​within the range of 0-1 to eliminate the impact of dimensions and unify the data format; The feature extraction is used to extract features from the preprocessed data, and the autoregressive AR model in the time series analysis technology is used to process the extracted features and generate observation results. The trend and seasonality of the API call frequency are determined by the observation results, which specifically includes the following contents: The AR model of the autoregressive model is used to analyze the trend and seasonality of the API call frequency. The formula of the AR model is: Among them, X t is the observed value at the current moment, that is, the value of the API call frequency at time point t; c: is a constant term, representing the intercept or base level of the model; φ i : is the autoregressive coefficient, which indicates the relationship between the observed value at time ti and the current observed value X t The influence of , where i ranges from 1 to p, where p is the order of the model; X t-i : is the observed value at time ti; μ3 t : is the error term, which represents the random part that cannot be explained by the model, that is, the current observation value X t The residuals from the predicted values ​​of the AR model; The formula for calculating the average response time is: The standard deviation formula is: Where n represents the total number of observations; Trend and seasonality analysis: Trend analysis: Check the constant term c and autoregressive coefficient φ in the AR model i The sign and size of the trend to determine its direction and strength; Seasonality analysis: Observe the autoregression coefficient φ i The periodicity of , confirms the presence of seasonality, which manifests itself as a repetitive pattern of autoregressive coefficients at certain specific lag orders; S2. Obtain the observation results of the autoregressive AR model, establish a prediction scoring model S(t) to predict the API traffic pattern, and generate an automatic adjustment scaling strategy to cope with the API call demand during peak hours; The prediction scoring model S(t) formula is as follows: in: S(t) represents the system performance score at the current time t; e is the base of the natural logarithm; k is a normalization coefficient used to balance the influence of the summation function; D(t') represents the historical data of API calls at time t', including the timestamp, duration, request type and status of the request; f(D(t′),λ): is a high-level integral function used to evaluate the pattern and frequency of API usage in time period t′, analyze API usage patterns, and help predict future traffic trends; C i (t): indicates the resource usage at the current time t, including CPU utilization and memory usage data; g(C i (t),α i ): is a summation function used to analyze resource usage C i (t) Impact on system performance; h(T j ,β,γ): is a complex information filtering function used to analyze external factors T j Impact on API calls, β and γ are the parameters of the function; Φ: is the normal cumulative distribution function, which is used to model the impact of historical scaling activities on system performance; R(t): represents the historical scaling activity record corresponding to the time period of the day at the current time t, recording the time, scale and effect of each resource scaling; R: represents the recorded value of historical scaling activity, μ and σ2 are the mean and standard deviation of R respectively; X t : is the AR model observation value at the current time t; The average response time; σ1: standard deviation of response time; λ: adjustment parameter; S(t) range explanation: The value range of S(t) is [0,∞), which represents the system performance score at time t. The larger the value, the better the system performance. Analyze the corresponding data through functions f, g and h to predict and optimize system performance and reduce response delay; S3. Obtain the scaling rules set by the automatic adjustment scaling strategy to determine the performance indicators, and automatically perform resource adjustments through the cloud platform API based on the scaling rules, obtain the predicted traffic output by the prediction scoring model S(t), compare the actual traffic with the predicted traffic and record the effect of resource adjustment to generate monitoring results, and predict the accuracy of the scaling rules and resource utilization based on the monitoring results and performance indicators. Finally, continuously optimize the prediction scoring model S(t) and scaling rules based on the predicted accuracy of the scaling rules and resource utilization to identify and evaluate API call patterns.

2. The method for collecting and analyzing API call situations based on a multi-tenant SaaS gateway according to claim 1 is characterized in that: The SaaS gateway-based collection of multi-tenant API call history data, resource usage data, and external factor data related to the current time t specifically includes the following: The API call history data collected from multiple tenants includes: request timestamp, duration, request type and status. The acquisition steps are: Timestamp and duration: record the start and end time of each API request; Request type and status: Categorize and record the API functions and response status; The collecting of resource usage data includes using a system monitoring tool to record the CPU utilization and memory usage at each time point in real time; The external factor data related to the current time t collected includes the distance between the current request timestamp T and a specific season or holiday; External factor analysis: Collect relevant external factor data, including season and holiday information.

3. The method for collecting and analyzing API call situations based on a multi-tenant SaaS gateway according to claim 1 is characterized in that: The acquisition of D(t') comprises the following steps: Assume that in time period t', data of N API calls are collected. For each call i, we record the following data: T i : Timestamp of the request; ΔT i : Duration of the request; R i : The type of request is coded with numbers, and GET=1, POST=2, S i : Request status, set 200 for success, 500 for server error; Denote D(t') as a set containing the data of all API calls within time t', and obtain the following formula: D(t′)=(T1,ΔT1,R1,S1),(T2,ΔT2,R2,S2),...(T i ,ΔT i ,R i ,S i )...,(T N ,ΔT N ,R N ,S N ) Among them, λ is a parameter used to adjust the influence of D(t') in the f function; The acquisition of f(D(t′),λ) comprises the following steps: The function f(D(t′),λ) will be calculated based on the historical data D(t′) of the API call and the adjustment parameter λ; Assume that the calculation formula of f is: in: w(T i ,λ) is a weight function used to adjust the parameter λ and the timestamp T i Adjust the influence of each call; make the most recent call have a greater weight, the weight function is an exponential decay form, expressed as follows: Where t: represents the current time; g(ΔT i ,R i ,S i ): It is a scoring function that scores each call based on the duration, type and status of the request. The scoring rule is set as follows: longer response time or failed status gets lower scores.

4. The method for collecting and analyzing API call situations based on a multi-tenant SaaS gateway according to claim 1 is characterized in that: The C i The acquisition of (t) comprises the following steps: Assuming that CPU utilization and memory usage data are the main resources, the design for each resource i is as follows: CPU t : CPU utilization at time t, expressed in %; MEM t : Memory usage at time t, expressed in GB; Then C i (t) is expressed as: [C i (t)={CPU t for i=1MEM t for i=2] The g(C i (t),α i ) includes the following steps: The calculation formula is as follows: where α i A coefficient used to adjust the importance of CPU utilization and memory usage data on system performance.

5. The method for collecting and analyzing API call situations based on a multi-tenant SaaS gateway according to claim 1 is characterized in that: The h(T j The acquisition of ,β,γ) includes the following steps: Programming to implement h(T j ,β,γ) function, using the input external factor data T j , combined with the set parameters β and γ, calculate their impact on API calls; Define h(T j ,β,γ) is a weighted function, and the following formula is obtained by taking into account the time-related factors: h(T j ,β,γ)=β·e γ·J in: J represents the time-related factor, which represents the distance between the current time and a specific season or holiday; β and γ are influencing parameters, which are used to adjust the influence of time factors on system performance; h(T j ,β,γ) depends on the values ​​of β and γ, and is used to adjust the impact of external time factors on API performance.

6. The method for collecting and analyzing API call situations based on a multi-tenant SaaS gateway according to claim 1 is characterized in that: The step of obtaining Φ includes the following contents: The formula for defining the normal cumulative distribution function Φ(x) is as follows: Where erf(x) is the error function, defined as: The value range of Φ(x) is [0,1], which provides a smooth way to consider the relationship between historical data and current data. The larger the value, the greater the impact of simulated historical scaling activities on system performance.

7. The method for collecting and analyzing API call situations based on a multi-tenant SaaS gateway according to claim 1 is characterized in that: The method obtains the scaling rules set by the automatic adjustment scaling strategy to determine the performance indicators, and automatically performs resource adjustment through the cloud platform API based on the scaling rules, obtains the predicted traffic output by the prediction scoring model S(t), compares the actual traffic with the predicted traffic and records the effect of resource adjustment to generate monitoring results, predicts the accuracy of the scaling rules and the resource utilization rate according to the monitoring results and performance indicators, and finally continuously optimizes the prediction scoring model S(t) and the scaling rules according to the predicted accuracy of the scaling rules and the resource utilization rate to identify and evaluate the API call pattern, specifically including the following contents: Automatically adjust the scaling rules set by the scaling policy: if the predicted traffic exceeds 80% of the current capacity, automatically increase resources; The automatic resource adjustment using the cloud platform API is based on the automatic expansion function of AWS or Azure cloud services; The identification and evaluation of API call patterns includes the following: a. Peak and trough periods: The prediction scoring model S(t) identifies the peak and trough periods of each day by analyzing the historical data of API calls D(t'). The specific judgment criteria are: Threshold setting: Set the peak threshold and the trough threshold to be λ respectively. Gf , Dg ; Peak threshold λ Gf : When the API request frequency exceeds 1,000 times per minute or the proportion of data queries in the request type exceeds 80%, it is considered a peak period; Valley threshold λ Dg :When the API request frequency is less than 200 times per minute, and the proportion of data update requests is less than 20%, it is considered a low period; b. Periodic patterns: The predictive scoring model S(t) identifies periodic patterns, including weekly or monthly recurring patterns, obtained by observing the request data D(t') over a long period of time; The specific judgment criteria are: Periodic pattern recognition: Identify a periodic pattern where the average number of API requests per hour is 500 on weekdays and 300 on weekends. c. Evaluate API call frequency: The prediction scoring model S(t) comprehensively considers the frequency of API calls through the f(D(t′),λ) function, including the call frequency per second, per minute, or per hour; The specific judgment criteria are: Frequency assessment: Set the number of API calls per second, per minute, and per hour. If the number of requests exceeds 50 per second, it is considered a high frequency.

8. A device for collecting and analyzing API call situations based on a multi-tenant SaaS gateway, characterized in that: The device is used to perform the method according to any one of claims 1 to 7, comprising: Data collection and feature engineering module: Based on the SaaS gateway, it collects API call history data, resource usage data, and external factor data related to the current time t of multiple tenants, and pre-processes the collected data through the data cleaning algorithm. Then, it extracts features from the pre-processed data through feature extraction. The autoregressive AR model in the time series analysis technology is used to process the extracted features and generate observation results. The trend and seasonality of the API call frequency are determined through the observation results. Model building and traffic prediction module: obtains the observation results of the autoregressive AR model, builds a prediction scoring model S(t) to predict the API traffic pattern, and generates an automatic adjustment scaling strategy to cope with the API call demand during peak hours; Automatic scaling strategy and continuous optimization module: obtain the scaling rules set by the automatic adjustment scaling strategy to determine the performance indicators, and automatically perform resource adjustments through the cloud platform API based on the scaling rules, obtain the predicted traffic output by the prediction scoring model S(t), compare the actual traffic with the predicted traffic and record the effect of resource adjustment to generate monitoring results, and predict the accuracy of scaling rules and resource utilization based on the monitoring results and performance indicators. Finally, the prediction scoring model S(t) and scaling rules are continuously optimized based on the predicted accuracy of scaling rules and resource utilization to identify and evaluate API call patterns.

Images