Serverless platform instance health management method and system

Abstract

The invention provides a short life cycle instance health management method and a short life cycle instance health management system in a Server FaaS platform. The method is characterized in that a unique identifier is allocated to each instance, an instance health score is calculated based on a lightweight health index after each request processing, an accumulated health score is updated, and request allocation of the instances is determined accordingly. When the idle time of the instance exceeds a predetermined threshold, the system releases the instance. The method further comprises cross-instance data analysis, function level health assessment and abnormal instance rapid identification. The system comprises an instance identification module, a health scoring module, a request distribution module, an instance management module, a data analysis module and the like. According to the method and the system, the resource utilization efficiency can be improved while the performance of the Serverless platform is ensured, the health management problem of the short-life-cycle instance is effectively solved, and the quality and the reliability of the Serverless service are remarkably improved.

Description

Technical Field

[0001] The present invention relates to the field of cloud computing technology, and in particular to instance management technology in a Serverless Function as a Service (FaaS) platform. Specifically, the present invention provides a method and system for monitoring, evaluating and managing the health status of short-lifecycle computing instances. Background Art

[0002] As an emerging paradigm of cloud computing, serverless computing has important applications in the field of modern software development and deployment. Among them, the Function as a Service (FaaS) platform allows developers to focus on writing and deploying independent functions without having to consider the management of the underlying infrastructure. This model greatly simplifies the application development process, improves resource utilization efficiency, and shows significant advantages in scenarios such as microservice architecture, event-driven applications, and rapid prototyping.

[0003] Currently, major Serverless FaaS platforms use instance reuse and automatic scaling solutions to manage computing resources. This solution usually includes steps such as creating function instances, processing requests, reusing idle instances, and releasing instances after a certain period of no requests. For example, some platforms will quickly start a function instance when receiving a request, and keep it in hot standby state for a period of time after processing the request, so as to quickly respond to subsequent requests, thereby reducing the delay caused by cold start.

[0004] However, this solution has the problem of difficult to accurately control the health status of instances. Due to the short life cycle of instances in the Serverless environment, traditional periodic health check mechanisms are difficult to detect and handle problematic instances in a timely manner. In addition, instance reuse may cause instances with abnormal performance to continue to be used, affecting service quality. Frequent creation and destruction of instances may lead to resource waste and performance overhead, especially in scenarios with large load fluctuations.

[0005] To solve the above problems, some studies have proposed dynamic instance management methods based on monitoring indicators. These methods judge the health status of instances and make corresponding management decisions by real-time monitoring of indicators such as CPU usage and memory usage. Although this method improves the accuracy of instance management to a certain extent, due to the transient nature of instances in the Serverless environment, it is difficult to collect enough data to make accurate judgments. At the same time, these methods often ignore cross-instance data analysis and cannot fully evaluate the overall performance of the function.

[0006] Therefore, developing an accurate health management system for short-lifecycle instances has become a research hotspot for optimizing ServerlessFaaS platforms. Such a system needs to be able to quickly evaluate the health status of instances within a limited time, while considering cross-instance data analysis to provide a more comprehensive and accurate instance management strategy, thereby improving the service quality and resource utilization efficiency of the platform. Summary of the invention

[0007] The main purpose of the present invention is to solve the problem of short-lifecycle instance health management in the Serverless FaaS platform, especially to provide solutions to the problems that the instance health status is difficult to accurately control, the performance abnormal instances may continue to be used, and the cross-instance data analysis is insufficient. In addition, the present invention also aims to improve the resource utilization efficiency of the Serverless platform, reduce the performance overhead caused by cold start, and provide platform managers with a more comprehensive function-level performance evaluation tool.

[0008] To achieve the above objectives, the present invention provides a Serverless platform instance health management method and system, characterized in that: a unique identifier is assigned to each instance, the instance health score is calculated based on lightweight health indicators after each request is processed, the cumulative health score is updated, and the request allocation and lifecycle management of the instance are determined accordingly. In some embodiments, the method also includes functions such as cross-instance data analysis, function-level health assessment, and rapid identification of abnormal instances.

[0009] Specifically, the method of the present invention first allocates a globally unique identifier to each created instance for tracking and managing the entire life cycle of the instance.

[0010] Furthermore, the present invention defines a set of lightweight health indicators, including but not limited to startup time, memory usage, single request processing time and request success rate. These indicators are selected to quickly evaluate the health status of the instance.

[0011] Preferably, after each request is processed, the system immediately calculates the health score of the instance and updates the cumulative health score. The cumulative health score is calculated using a weighted average method to ensure that it can reflect the overall performance of the instance.

[0012] Optionally, the system decides whether to continue allocating new requests to the instance based on the cumulative health score of the instance. When the score is below a predetermined threshold, the instance will be marked as unavailable and stop receiving new requests.

[0013] In one embodiment, the present invention further includes dynamically adjusting the idle time allowed for an instance. For an instance with a high cumulative health score, the system may allow it to have a longer idle time to reduce the number of cold starts.

[0014] In some embodiments, the method of the present invention also includes a cross-instance data analysis function. The system collects and analyzes all instance data of the same function, evaluates the overall health of the function, and provides platform managers with more comprehensive performance insights.

[0015] In addition, the present invention can also compare the performance of different configuration instances, automatically generate optimal configuration recommendations, and help users optimize their function deployment.

[0016] In other embodiments, the present invention uses statistical methods to perform outlier detection, which can quickly identify instances that exhibit abnormal performance and improve the reliability and stability of the system.

[0017] In a preferred embodiment, the system of the present invention includes an instance identification module, a health scoring module, a request allocation module, an instance management module and a data analysis module. These modules work together to achieve full process automation from instance creation, health assessment to lifecycle management.

[0018] In another preferred embodiment, the method of the present invention is applied to Serverless application scenarios with high concurrency and large load fluctuations, such as the homework grading system of an online education platform or the flash sale activity backend of an e-commerce platform.

[0019] By adopting the above scheme, the present invention has the following beneficial effects: (1) Accurate health management of short-lifecycle instances is achieved, improving the service quality and reliability of the Serverless platform; (2) Through rapid health assessment and intelligent request allocation, the impact of performance anomalies on service quality is significantly reduced; (3) Introducing cross-instance data analysis to provide platform managers with a more comprehensive function-level performance evaluation tool; (4) By dynamically adjusting instance idle time and intelligent preheating, the performance overhead caused by cold start is effectively reduced; (5) Automatically generate optimal configuration recommendations to help users better optimize their function deployment and resource utilization.

[0020] In summary, the present invention not only solves the key problem of short-lifecycle instance health management in the Serverless FaaS platform, but also provides a comprehensive performance optimization and resource management solution, which is of great significance to improving the efficiency and reliability of Serverless computing. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the technical solution of the present invention, the following briefly introduces the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present invention, and for those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative work.

[0022] Figure 1 This is an overall flow chart of the Serverless platform instance health management method. It shows the complete process from instance creation to lifecycle management, including health indicator collection, score calculation, and request allocation decision.

[0023] Figure 2 It is a lightweight health indicator set and health score calculation method diagram. It details the process of health indicator definition, data collection, score calculation and dynamic threshold adjustment.

[0024] Figure 3 This is a diagram of the cumulative health score update and request allocation decision mechanism. This diagram shows the health score update process, anomaly detection mechanism, and score-based request allocation strategy.

[0025] Figure 4 It is a dynamic instance management and resource optimization diagram. It describes the implementation process of optimization strategies such as instance lifecycle adjustment, intelligent preheating, and dynamic resource allocation.

[0026] Figure 5 This is a cross-instance data analysis and function-level health assessment diagram. This diagram shows the entire process from data collection to function-level health report generation, including abnormal pattern detection and resource utilization analysis.

[0027] Figure 6 It is an instance configuration optimization and adaptive resource allocation diagram. It describes the complete process from performance analysis to resource utilization optimization, including configuration efficiency curve generation and dynamic scaling strategies.

[0028] Figure 7 This is a diagram of anomaly detection and automatic recovery mechanism. This diagram shows the implementation process of multi-dimensional anomaly detection, root cause analysis, automatic recovery strategy, and continuous learning and optimization mechanism.

[0029] Figure 8 It is a system architecture and module interaction diagram. It shows the core module composition of the entire system and the way in which the modules communicate through the event bus, highlighting the modular design and event-driven architecture of the system. DETAILED DESCRIPTION

[0030] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0031] In the description of the present invention, it should be noted that the terms "center", "up", "down", "left", "right", "vertical", "horizontal", "inside", "outside" and the like indicate directions or positional relationships based on the directions or positional relationships shown in the accompanying drawings, and are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific direction, be constructed and operated in a specific direction, and therefore should not be understood as a limitation on the present invention.

[0032] Example 1: Overall process of the Serverless platform instance health management method. Figure 1 This embodiment provides an overall process of a Serverless platform instance health management method. The method aims to solve the problem of accurate health management of short-lifecycle instances and improve the service quality and resource utilization efficiency of the platform.

[0033] Step 101: Instance creation and unique identifier assignment. When the Serverless platform receives a function call request, it first creates a function instance. In order to accurately track and manage instances, the system immediately assigns a globally unique identifier (Instance ID) to the newly created instance. This identifier uses the UUID (Universally Unique Identifier) ​​format to ensure uniqueness throughout the platform. For example: 550e8400-e29b-41d4-a716-446655440000.

[0034] Step 102: Request processing. After the instance is created, it immediately starts processing requests. During this process, the system records key performance indicators to prepare for subsequent health assessments.

[0035] Step 103: Lightweight health indicator collection. After the request processing is completed, the system immediately collects a set of predefined lightweight health indicators. These indicators include but are not limited to: (1) Startup time (ms) (2) Memory usage (%) (3) CPU usage (%) (4) Request processing time (ms) (5) Request success rate (%) The selection of these indicators takes into account the real-time nature of data collection and the minimum impact on instance performance.

[0036] Step 104: Calculate the health score. Based on the collected health indicators, the system calculates the health score of the instance using the following formula: HealthScore = w1 * (1 - StartupTime / MaxStartupTime) +w2 * (1 -MemoryUsage / MaxMemoryUsage) +w3 * (1 - CPUUsage / MaxCPUUsage) +w4 * (1 -ProcessingTime / MaxProcessingTime) +w5 * SuccessRate Among them, w1 to w5 are the weights of each indicator, and their sum is equal to 1. MaxStartupTime, MaxMemoryUsage, etc. are preset thresholds. This calculation method ensures that the health score is between 0 and 1. The higher the score, the better the instance performance.

[0037] Step 105: Cumulative health score update. To reflect the overall performance of the instance, the system maintains a cumulative health score. After each request is processed, the cumulative score is updated using the following formula: CumulativeScore = (PreviousScore * RequestCount + CurrentScore) / (RequestCount + 1) Among them, PreviousScore is the previous cumulative score, RequestCount is the number of processed requests, and CurrentScore is the health score of the current request. This method ensures that the cumulative score can smoothly reflect the performance changes of the instance.

[0038] Step 106: Request allocation decision. The system decides whether to continue to allocate new requests to the instance based on the cumulative health score of the instance. The specific strategy is as follows: if the cumulative score is >= 0.8, continue to allocate new requests; if 0.6 <= cumulative score < 0.8, reduce the number of requests allocated to the instance; if the cumulative score is < 0.6, mark the instance as unavailable and stop allocating new requests.

[0039] This tiering strategy ensures that the system can promptly identify and isolate instances with degraded performance, while giving more workloads to instances that are performing well.

[0040] Step 107: Instance lifecycle management. The system continuously monitors the idle time of each instance. When the instance idle time exceeds a predetermined threshold, the instance release mechanism is triggered. The default idle time threshold is 5 minutes, but the system dynamically adjusts this threshold based on the cumulative health score of the instance: for instances with a cumulative score >= 0.9, the idle time threshold can be extended to 7 minutes; for instances with a cumulative score < 0.7, the idle time threshold is shortened to 3 minutes.

[0041] This dynamic adjustment mechanism ensures efficient resource utilization while retaining high-performance instances to reduce the impact of cold starts.

[0042] The innovation of this embodiment is that it introduces an accurate health management mechanism based on instance ID, and realizes efficient management of short-lifecycle instances through real-time, lightweight health assessment and dynamic request allocation strategy. Compared with traditional periodic health checks, this method can identify and handle problem instances more quickly, significantly improving the service quality and reliability of the Serverless platform.

[0043] It should be noted that the specific parameter values ​​in this embodiment (such as scoring threshold, idle time threshold, etc.) can be adjusted according to the actual application scenario and performance requirements. In addition, this method can also be used in combination with other Serverless optimization technologies (such as preheating strategy, resource reservation, etc.) to further improve platform performance.

[0044] Embodiment 2: Lightweight health indicator set and health score calculation method. Figure 2 ,This embodiment details the selection of lightweight health indicators and the ,calculation method of health scores, which are the key to achieving accurate ,instance health management.

[0045] Step 201: Definition of lightweight health indicator set. In order to achieve fast and accurate evaluation of short-lifecycle instances, this method carefully selects the following lightweight health indicators: (1) Startup Time: The time from when the instance creation request is issued to when the instance reaches the Ready state, measured in milliseconds (ms).

[0046] (2) Memory Usage: The percentage of memory currently used by the instance to the allocated memory.

[0047] (3) CPU Usage: Current CPU usage of the instance.

[0048] (4) Request processing time (ProcessingTime): The time from receiving a request to returning a response, in milliseconds (ms).

[0049] (5) Request success rate (SuccessRate): The ratio of successfully processed requests to the total number of requests.

[0050] The selection of these indicators is based on the following considerations: real-time data collection: all indicators can be obtained immediately after a single request is completed; minimizing performance impact: indicator collection will not have a significant impact on the normal operation of the instance; comprehensiveness: covering multiple key aspects of instance performance.

[0051] Step 202: Health indicator data collection. The system collects the above health indicator data immediately after each request is processed. In order to ensure the accuracy and consistency of the data, the following method is used: (1) Start time: calculated by recording the timestamps of when instance creation starts and ends.

[0052] (2) Memory usage: Use lightweight memory tools, such as process.memoryUsage() in the Node.js environment.

[0053] (3) CPU usage: Calculate the average CPU usage through periodic sampling (such as every 100ms).

[0054] (4) Request processing time: The timestamp calculation of the start and end of the request is recorded.

[0055] (5) Request success rate: Maintain a sliding window (such as the last 100 requests) to calculate the success rate.

[0056] Step 203: Calculate the health score. Based on the collected indicator data, use the following improved formula to calculate the health score of the instance: HealthScore = w1 * f(StartupTime) +w2 * f(MemoryUsage) +w3 * f(CPUUsage) +w4 * f(ProcessingTime) +w5 * SuccessRate Where f(x) is the normalization function, defined as: f(x) = max(0, 1 - x / Threshold(x)) Threshold(x) is the threshold of each indicator, which can be adjusted according to specific application scenarios and performance requirements. For example: Threshold(StartupTime) = 1000 ms Threshold(MemoryUsage) = 90% Threshold(CPUUsage) = 80% Threshold(ProcessingTime) = function_specific_threshold (set according to function complexity) The weights (w1 to w5) are assigned as follows: w1 = 0.1, w2 = 0.2, w3 = 0.2, w4 = 0.3, w5 = 0.2 This weight distribution reflects the different degrees of impact of each indicator on the health status of the instance, among which request processing time is given the highest weight because it directly affects the user experience.

[0057] Step 204: Dynamic threshold adjustment. In order to adapt to the characteristics of different types of functions and changes in the operating environment, the system will adjust the indicator threshold regularly (such as every hour). The adjustment method is as follows: (1) Collect performance data for all instances of the same type of function in the past hour.

[0058] (2) Calculate the 95th percentile value of each indicator.

[0059] (3) Set the new threshold to: New_Threshold = 0.8 * Old_Threshold + 0.2 * 95th_percentile_value This dynamic adjustment mechanism ensures that the health score reflects the current operating environment and load conditions.

[0060] Step 205: Health score interpretation. The health score ranges from 0 to 1 and has the following meanings: 0.9 - 1.0: Excellent, instance performance is at its best 0.7 - 0.9: Good, instance performance is normal 0.5 - 0.7: Average, may need attention < 0.5: Poor, needs immediate attention The system will determine the instance processing strategy based on this score range, such as request allocation and resource adjustment.

[0061] The innovation of this embodiment lies in: introducing a set of lightweight health indicators designed specifically for short life cycle instances to ensure fast and accurate health assessment; adopting a normalized and weighted health score calculation method so that different indicators can be compared and integrated on a unified scale; and implementing a dynamic threshold adjustment mechanism so that health assessment can adapt to different function characteristics and operating environments.

[0062] This health assessment method can not only quickly identify problem instances, but also provide a reliable basis for instance lifecycle management and resource optimization, thereby significantly improving the overall performance and reliability of the Serverless platform.

[0063] It should be noted that the specific weight allocation and threshold setting may need to be fine-tuned according to the actual application scenario. In addition, this method can also be combined with machine learning technology to optimize the weight allocation and threshold setting by analyzing historical data to further improve the accuracy of health assessment.

[0064] Example 3: Cumulative health score update and request allocation decision mechanism. Figure 3 ,This embodiment details the update algorithm of the cumulative health score and the ,request allocation decision mechanism based on the score, which is the core of realizing ,dynamic instance management.

[0065] Step 301: Initialize the cumulative health score. When a new instance is created, the system initializes its cumulative health score to 0.8. This initial value is neither too optimistic nor too optimistic, and gives the new instance a relatively fair starting point. The initial score calculation formula is: InitialCumulativeScore = 0.8 Step 302: Cumulative health score update. After each request is processed, the system uses the exponential moving average (EMA) algorithm to update the cumulative health score of the instance. This method can smoothly reflect the changing trend of instance performance and is more sensitive to recent performance changes. The update formula is as follows: NewCumulativeScore = α * CurrentScore + (1 - α) * OldCumulativeScore Among them, α is the smoothing factor, which is set to 0.2. This means that the new health score accounts for 20% of the weight and the historical cumulative score accounts for 80% of the weight, achieving a balance between responsiveness and stability.

[0066] Step 303: Anomaly detection and quick response mechanism. To quickly respond to sudden performance degradation, the system introduces an anomaly detection mechanism. When the health score of a single request is less than 50% of the cumulative health score, a quick response is triggered: if CurrentScore < 0.5 * OldCumulativeScore: NewCumulativeScore =(CurrentScore + OldCumulativeScore) / 2 This mechanism can quickly adjust the cumulative score when severe performance degradation occurs, improving the system's responsiveness.

[0067] Step 304: Request allocation decision. Based on the cumulative health score, the system uses a continuous decision-making mechanism to manage request allocation. As the cumulative health score decreases, the system will gradually reduce the number of requests allocated to the instance and adjust the priority of its processing tasks. When the score reaches a critical value (such as 0.5), the system will stop allocating new requests to the instance and start the instance recycling process.

[0068] Step 305: Dynamic concurrency limit adjustment. The system dynamically adjusts the maximum number of concurrent requests allowed based on the instance's cumulative health score. The adjustment formula is as follows: MaxConcurrency = BaseConcurrency * (CumulativeScore / 0.7)^2 BaseConcurrency is the base concurrency, which is pre-set based on the complexity of the function and resource requirements. This formula ensures that instances with good performance can handle more requests, while instances with reduced performance are limited.

[0069] Step 306: Instance marking and isolation. When the cumulative health score of an instance drops below 0.5, the system marks it as "unhealthy". The system immediately stops allocating new requests to the instance, waits for the current request to complete (with a 30-second timeout), and then moves the instance to the isolation pool for further diagnosis and analysis.

[0070] Step 307: Instance recovery mechanism. The system introduces an instance recovery mechanism to increase resilience. After the isolated instance enters a 60-second cooldown period, the system attempts to reinitialize. If successful, the instance is given an initial cumulative health score of 0.6 and rejoins the available pool. Instances that fail to initialize three times in a row will be permanently removed.

[0071] The innovation of this embodiment is: (1) The EMA algorithm is used to update the cumulative health score, which not only reflects the performance trend but also responds quickly to sudden changes; (2) Introducing a continuous request allocation decision mechanism to achieve fine-grained instance load management; (3) Dynamic concurrency limit adjustment ensures efficient use of resources; (4) Instance marking, isolation, and recovery mechanisms improve the reliability and self-healing capabilities of the system.

[0072] This approach can precisely control the load of each instance, maximizing resource utilization while ensuring service quality. By quickly identifying and isolating problem instances and optimizing instances with good performance, the stability and efficiency of the entire system are significantly improved.

[0073] It should be noted that the specific parameter settings may need to be fine-tuned according to the actual application scenario and load characteristics. In addition, this method can be combined with the automatic expansion and contraction mechanism to achieve smarter resource allocation based on instance-level health management.

[0074] Example 4: Dynamic instance management and resource optimization. Figure 4 ,This embodiment details the dynamic instance management and resource optimization mechanism based on ,health scoring, which is the key to improving the overall ,performance and resource utilization of the Serverless platform.

[0075] Step 401: Dynamically adjust the instance lifecycle. The system dynamically adjusts the instance lifecycle based on the instance's accumulated health score. The specific implementation is as follows: LifetimeMultiplier = 0.5 + CumulativeScore / 2 AdjustedLifetime =BaseLifetime * LifetimeMultiplier BaseLifetime is the preset basic lifecycle duration, usually 5 minutes. This adjustment ensures that instances with good performance can survive longer, reducing the number of cold starts, and also allows instances with poor performance to be recycled in a timely manner.

[0076] Step 402: Intelligent preheating strategy. The system introduces an intelligent preheating strategy to predict future resource requirements based on historical load patterns and current health scores. The preheating probability is calculated as follows: PrewarmProbability = (HistoricalLoadFactor * 0.7 + CumulativeScore *0.3) * TimeFactor Among them, HistoricalLoadFactor reflects the historical load situation in a specific time period, and TimeFactor takes into account the proximity of the current time to the peak time. This strategy can prepare resources in advance before the load increases, and give priority to preheating instance configurations with better performance.

[0077] Step 403: Dynamic resource allocation. The system dynamically adjusts the computing resources allocated to the instance based on its health score. The resource adjustment formula is as follows: AdjustedMemory = BaseMemory * (0.8 + CumulativeScore * 0.4)AdjustedCPU = BaseCPU * (0.8 + CumulativeScore * 0.4) This adjustment ensures that instances with good performance can obtain more resources to improve their processing power, while avoiding wasting too many resources on instances with poor performance.

[0078] Step 404: Adaptive batch processing. The system introduces an adaptive batch processing mechanism to dynamically adjust the batch size based on the health status of the instance. The batch size is calculated as follows: BatchSize = BaseBatchSize * CumulativeScore^2 This approach allows better-performing instances to process larger batches, increasing overall throughput while relieving the burden on poorer-performing instances.

[0079] Step 405: Instance affinity scheduling. The system implements instance affinity scheduling based on health scores. For functions with state or cache dependencies, the system tends to route requests to existing instances with higher health scores rather than creating new instances. The affinity score is calculated as follows: AffinityScore = CumulativeScore * (1 + CacheHitRatio) Among them, CacheHitRatio reflects the cache hit rate of the instance. This strategy can improve cache utilization, reduce cold starts, and ensure service quality.

[0080] Step 406: Failover and load balancing. The system implements an intelligent failover and load balancing mechanism based on health scores. When the performance of an instance is detected to be degraded, the system will gradually transfer the load to other healthy instances. The load distribution weight is calculated as follows: LoadWeight = CumulativeScore^3 This mechanism ensures smooth load transfer while maintaining system stability and avoiding sudden performance fluctuations.

[0081] Step 407: Resource utilization optimization. The system continuously monitors and optimizes overall resource utilization. By analyzing the distribution of health scores and resource usage of instances, the system can identify resource bottlenecks and optimization opportunities. For example, if most instances have low memory usage but high CPU usage, the system will adjust the resource allocation strategy to reduce memory allocation and increase CPU allocation.

[0082] The innovation of this embodiment is: (1) Dynamic lifecycle management based on health scores was introduced to improve resource utilization efficiency; (2) Implemented an intelligent preheating strategy to reduce the performance impact caused by cold start; (3) More sophisticated load management is achieved through dynamic resource allocation and adaptive batch processing; (4) The introduction of instance affinity scheduling and intelligent failover improves the stability and performance of the system; (5) Continuous optimization of global resource utilization is achieved, ensuring efficient use of system resources.

[0083] This dynamic instance management and resource optimization approach not only improves the performance of a single instance, but also significantly improves the efficiency and reliability of the entire Serverless platform. By closely integrating health scores with various resource management strategies, the system can allocate resources more intelligently, respond to load changes, and quickly recover from failures.

[0084] It should be noted that the specific parameters of these optimization strategies may need to be adjusted according to the actual application scenario and workload characteristics. In addition, this method can also be combined with machine learning technology to continuously optimize the decision model by analyzing historical data to achieve smarter and more accurate resource management.

[0085] Example 5: Cross-instance data analysis and function-level health assessment. Figure 5 This embodiment details the cross-instance data analysis method and the function-level health assessment mechanism based on it, which is the key to providing global performance insights and optimizing the overall performance of the Serverless platform.

[0086] Step 501: Instance performance data collection. The system continuously collects performance data for each instance, including cumulative health score, request processing time, memory usage, CPU usage, error rate, cold start frequency, etc. These data are stored in the form of time series, and each data point is accompanied by an instance ID and a timestamp.

[0087] Step 502: Data aggregation and standardization. The system aggregates and standardizes the collected data periodically (e.g., every 5 minutes). First, all instance data is grouped by function name, and then the mean, median, 90th percentile, and 99th percentile of each performance indicator are calculated. Then, standardization is performed using the formula: StandardizedValue = (RawValue - Mean) / StandardDeviation This standardization process allows indicators of different dimensions to be directly compared.

[0088] Step 503: Calculate the function-level health score. Based on the aggregated and standardized data, the system calculates the function-level health score. The calculation formula is as follows: FunctionHealthScore = w1 * AvgInstanceScore + w2 * (1 - ErrorRate) +w3 * (1 - P90ProcessingTime / Threshold) + w4 * (1 - ColdStartRate) + w5 *ResourceEfficiency Among them, w1 to w5 are weight coefficients, which can be adjusted according to specific needs. This multi-dimensional scoring method can fully reflect the health of the function.

[0089] Step 504: Abnormal pattern detection. The system uses time series analysis technology to detect abnormal patterns in function performance. The specific steps include: (1) Applying exponentially weighted moving average (EWMA): EWMA_t = α * Value_t + (1 - α) * EWMA_{t-1} (2) Calculate the moving standard deviation.

[0090] (3) Calculate Z-score: Z = (CurrentValue - EWMA) / MovingStdDev (4) If |Z| > 3, mark it as a potential outlier.

[0091] (5) Use the DBSCAN clustering algorithm to identify persistent abnormal patterns.

[0092] This approach can quickly detect sudden changes and sustained degradations in function performance.

[0093] Step 505: Resource utilization analysis. The system analyzes resource utilization at the function level and identifies resource waste or insufficiency. Calculate the average resource utilization: AvgUtilization = AvgUsage / Allocation If AvgUtilization < 0.5 and P90Utilization < 0.8, it is marked as potential resource waste. If P90Utilization > 0.9, it is marked as potential resource shortage. Based on these analyses, the system gives resource configuration optimization suggestions.

[0094] Step 506: Identify performance bottlenecks. By calculating the Pearson correlation coefficient matrix between the indicators, the system identifies highly correlated indicator pairs (correlation coefficient > 0.8). For example, if processing time is highly correlated with memory usage, there may be a memory bottleneck. This analysis provides a clear direction for performance optimization.

[0095] Step 507: Generate function health report. The system regularly generates comprehensive function health reports, including function health scores and trends, abnormal pattern analysis, resource utilization analysis results, performance bottleneck analysis, and performance comparison of similar functions. These reports provide valuable performance insights for developers and operation and maintenance personnel.

[0096] The innovation of this embodiment is that it realizes the aggregation and analysis of performance data from the instance level to the function level, providing a more comprehensive performance view. By introducing standardized processing and advanced statistical methods, the performance of different functions can be directly compared. The use of time series analysis and machine learning technology for anomaly detection improves the accuracy and timeliness of problem identification. Resource utilization analysis and performance bottleneck identification provide data support for resource optimization. The automatically generated comprehensive function health report greatly reduces the labor cost of performance analysis.

[0097] This cross-instance data analysis and function-level health assessment method not only provides deeper performance insights, but also provides strong support for the overall optimization of the Serverless platform. By identifying common problems and optimization opportunities, the platform can achieve smarter resource allocation and load balancing, thereby significantly improving overall performance and user experience.

[0098] It should be noted that the specific analysis parameters and thresholds may need to be adjusted according to the actual application scenario and performance requirements. In addition, this method can also be integrated with the continuous integration / continuous deployment (CI / CD) process to achieve automated performance monitoring and optimization.

[0099] Example 6: Instance configuration optimization and adaptive resource allocation. Figure 6 This embodiment describes in detail the method of instance configuration optimization and adaptive resource allocation based on function-level health assessment results. This is a key mechanism to improve the resource utilization efficiency and performance of the Serverless platform.

[0100] Step 601: Instance configuration performance analysis. The system first performs performance analysis on instances with different configurations. For each function, we consider multiple instance configurations (such as memory size, number of CPU cores, etc.). Performance indicators include average execution time, cold start time, cost-effectiveness ratio, etc. The performance score is calculated as follows: PerformanceScore = w1 * (1 - AvgExecutionTime / MaxExecutionTime) +w2 * (1 - ColdStartTime / MaxColdStartTime) + w3 * (Throughput / MaxThroughput) + w4 * (CostEfficiency / MaxCostEfficiency) Among them, w1 to w4 are weight coefficients, which can be adjusted according to specific needs.

[0101] Step 602: Generate a configuration efficiency curve. Based on the performance analysis results, the system generates a configuration efficiency curve for each function. This curve reflects the relationship between resource configuration and performance. We use polynomial regression to fit this curve: PerformanceScore = a0 + a1 x + a2 x^2 + ... + an*x^n Where x represents resource configuration (such as memory size), and n is usually 2 or 3.

[0102] Step 603: Optimal configuration recommendation. The system analyzes the configuration efficiency curve to find the balance point between performance gain and cost increase as the optimal configuration recommendation. The specific method is to calculate the derivative of the curve and find the point where the derivative is close to zero but still positive: 0 < d(PerformanceScore) / dx <= ε where ε is a small positive number representing an acceptable marginal performance gain.

[0103] Step 604: Adaptive resource allocation. Based on the function-level health assessment results and load prediction, the system implements adaptive resource allocation. The resource allocation algorithm is as follows: AllocatedResource = BaseResource * (1 + α * (HealthScore - 0.5) + β *LoadFactor) in: BaseResource is the basic resource configuration α and β are regulatory factors HealthScore is the function health score LoadFactor is the load prediction factor, ranging from [0,1] Step 605: Dynamic expansion and contraction strategy. The system implements a dynamic expansion and contraction strategy based on health score and load. Expansion trigger conditions: if (AvgCPUUtilization > 70% OR AvgMemoryUtilization > 80%) ANDHealthScore > 0.7: InstanceCount = CurrentInstanceCount * (1 + ScaleFactor) Trigger conditions for scaling down: if (AvgCPUUtilization < 30% AND AvgMemoryUtilization < 40%) ORHealthScore < 0.5: InstanceCount = max(MinInstanceCount, CurrentInstanceCount* (1 - ScaleFactor)) The ScaleFactor is an adjustable scaling ratio, usually set between 0.1 and 0.3.

[0104] Step 606: Load balancing optimization. The system dynamically adjusts the load balancing weight according to the health score of the instance. The weight calculation formula is as follows: LoadBalanceWeight = BaseWeight * (HealthScore^2) This ensures that instances with better performance can handle more requests, while also avoiding over-reliance on a single instance.

[0105] Step 607: Optimize resource utilization. The system continuously monitors and optimizes overall resource utilization. When resource utilization imbalance is detected, resource reallocation is triggered: if StdDev(CPUUtilization) > ThresholdCPU OR StdDev(MemoryUtilization) > ThresholdMemory: TriggerResourceReallocation() The resource reallocation process takes into account the health score and historical load of each instance to achieve a more balanced resource distribution.

[0106] The innovation of this embodiment is: (1) An instance configuration scoring mechanism based on multi-dimensional performance indicators is introduced to comprehensively evaluate the performance of different configurations; (2) Through the generation and analysis of configuration efficiency curves, intelligent recommendation of optimal configuration is achieved, avoiding over- or under-configuration of resources; (3) An adaptive resource allocation algorithm that takes health scores and load prediction into consideration is designed to dynamically adjust resources based on the actual operating status of the function; (4) Implemented dynamic expansion and contraction and load balancing strategies based on health scores, improving the elasticity and performance of the system; (5) A resource utilization optimization mechanism was introduced to ensure efficient utilization of overall system resources.

[0107] This instance configuration optimization and adaptive resource allocation method can not only significantly improve the resource utilization efficiency of the Serverless platform, but also quickly adjust according to the actual operation status and load changes of the function, thereby providing more stable and efficient services. It should be noted that the specific parameter settings and thresholds may need to be fine-tuned according to the actual application scenario and performance requirements. In addition, this method can also be combined with machine learning technology to continuously optimize the decision model by analyzing historical data to achieve smarter and more accurate resource management.

[0108] Example 7: Abnormal detection and automatic recovery mechanism. Figure 7 This example describes in detail the anomaly detection and automatic recovery mechanism in the Serverless platform. This mechanism is designed to improve the reliability and self-healing capabilities of the system and reduce the need for manual intervention.

[0109] Step 701: Multi-dimensional anomaly detection. The system implements multi-dimensional anomaly detection and monitors multiple performance indicators such as response time, error rate, CPU utilization, memory usage, and network I / O. For each indicator, the system uses an improved Z-score method to perform anomaly detection: Z = (x - μ) / σ Among them, x is the current observation, μ is the moving average, and σ is the moving standard deviation. In order to adapt to the characteristics of time series data, we use exponentially weighted moving average (EWMA) to calculate μ and σ: μ t = α * x_t + (1 - α) * μ {t-1} σ t = sqrt(β * (x_t - μ t)^2 + (1 - β)* σ_{t-1}^2) where α and β are smoothing factors, usually set between 0.1 and 0.3.

[0110] Step 702: Abnormal pattern recognition. The system uses the Isolation Forest algorithm to recognize complex abnormal patterns. The abnormal score is calculated as follows: AnomalyScore = 2^(-E(h(x)) / c(n)) where E(h(x)) is the average path length of sample x, and c(n) is the average path length of a complete binary tree with n samples.

[0111] Step 703: Root cause analysis. When an anomaly is detected, the system uses the Bayesian network model to perform root cause analysis: P(Root Cause | Symptoms) ∝ P(Symptoms | Root Cause) * P(Root Cause) The system maintains a prior probability distribution P(Root Cause) and learns the conditional probability P(Symptoms | Root Cause) through historical data.

[0112] Step 704: Automatic recovery strategy. Based on the results of anomaly detection and root cause analysis, the system implements an automatic recovery strategy. Recovery operations include restarting instances, migrating to different underlying hardware, stopping allocating new requests, creating new instances, isolating abnormal instances, etc. The execution probability model of automatic recovery operations is as follows: ExecutionProbability = BaseProb * (1 - exp(-λ * AnomalyScore)) Where BaseProb is the base execution probability and λ is the adjustment factor.

[0113] Step 705: Adaptive threshold adjustment. The system implements an adaptive threshold adjustment mechanism using a PID (proportional-integral-derivative) controller: Threshold_t = Threshold_{t-1} + Kp e(t) + Ki ∫e(t)dt + Kd*de(t) / dt Where e(t) is the error between the target false alarm rate and the actual false alarm rate, and Kp, Ki, and Kd are the parameters of the PID controller.

[0114] Step 706: Recovery effect evaluation. After each automatic recovery operation is performed, the system evaluates the recovery effect. The evaluation indicators include the recovery time (MTTR), the degree of service availability recovery, and the degree of performance recovery. The recovery effect score is calculated as follows: RecoveryScore = w1 * (1 - MTTR / MaxMTTR) + w2 * (AvailabilityAfter / AvailabilityBefore) + w3 * (PerformanceAfter / PerformanceBefore) Where w1, w2 and w3 are weight coefficients.

[0115] Step 707: Continuous learning and optimization. The system uses the Q-learning algorithm to continuously optimize the anomaly detection and recovery strategy: Q(s,a) ← Q(s,a) + α * [r + γ * max_a' Q(s',a') - Q(s,a)] Where s is the current state, a is the action taken, r is the immediate reward, s' is the new state, α is the learning rate, and γ is the discount factor.

[0116] The innovation of this embodiment is that it adopts multi-dimensional anomaly detection and machine learning models to improve the accuracy and comprehensiveness of anomaly identification; introduces Bayesian network for root cause analysis to provide more precise guidance for automatic recovery; implements automatic recovery strategy based on the degree of anomaly to improve the self-healing ability of the system; uses an adaptive threshold adjustment mechanism to enable the system to adapt to different workloads and environmental changes; and through continuous learning and optimization, the system can continuously improve its anomaly handling capabilities.

[0117] This anomaly detection and automatic recovery mechanism significantly improves the reliability and stability of the Serverless platform. By quickly identifying and handling anomalies, the system can minimize service interruptions and provide a higher quality user experience. It should be noted that specific parameter settings and thresholds may need to be adjusted according to actual application scenarios and performance requirements. In addition, this approach can also be integrated with other monitoring and log analysis tools to provide more comprehensive system health management.

[0118] Example 8: System architecture and module interaction. Figure 8 This embodiment describes in detail the system architecture for implementing the above method, including the functions of each key module and the interaction between them. This system architecture is designed to provide a comprehensive and efficient Serverless platform instance health management solution.

[0119] Step 801: System overall architecture. The system consists of the following core modules: instance identification module, health scoring module, request allocation module, instance management module, data analysis module, configuration optimization module, and anomaly detection and recovery module. These modules communicate in an event-driven manner, using message queues to ensure high throughput and low latency.

[0120] Step 802: Instance identification module. This module is responsible for assigning a universally unique identifier (UUID) to each created instance. It generates metadata containing the instance ID, creation time, function name, and instance configuration, and stores it in the system's metadata storage. This ensures the traceability and uniqueness of each instance.

[0121] Step 803: Health scoring module. The health scoring module continuously monitors instance performance and calculates health scores. It collects various performance indicators, such as response time, CPU usage, memory usage, etc., and applies a weighted algorithm to calculate a comprehensive health score. The module periodically updates the cumulative health score of each instance and publishes the results to the event bus for use by other modules.

[0122] Step 804: Request allocation module. The request allocation module decides how to allocate requests based on health scores and load conditions. It maintains a pool of available instances and sorts the instances based on their health scores and current load. When a new request is received, it selects the most suitable instance to handle the request. If there is no suitable instance, it triggers the process of creating a new instance.

[0123] Step 805: Instance management module. The instance management module is responsible for instance lifecycle management, including creating, recycling, and adjusting resources. It monitors the idle time and health of instances and decides when to recycle instances or isolate instances with poor performance. When an instance is recycled or isolated, the module is responsible for creating a replacement instance to ensure the overall performance and availability of the system.

[0124] Step 806: Data analysis module. The data analysis module processes performance data from all instances and performs cross-instance analysis. It calculates function-level health, detects abnormal patterns, and analyzes resource utilization efficiency. The output of this module provides key decision support for other modules, such as configuration optimization and anomaly detection.

[0125] Step 807: Configuration optimization module. The configuration optimization module provides instance configuration suggestions based on data analysis results. It analyzes historical performance data, fits the configuration-performance curve, and finds the optimal configuration point. This module runs regularly to ensure that the instance configuration is always in the optimal state, thereby improving resource utilization efficiency and performance.

[0126] Step 808: Anomaly Detection and Recovery Module. This module is responsible for detecting anomalies and performing automatic recovery operations. It uses advanced algorithms to identify anomaly patterns, analyze root causes, generate recovery plans and execute them. After the recovery operation, it also evaluates the recovery effect and continuously optimizes the recovery strategy. This module is the core of the system's self-healing ability, ensuring that the system can quickly respond and recover from abnormal conditions.

[0127] Step 809: Inter-module communication. Each module communicates in an event-driven manner. The system uses a publish-subscribe model. Key events include instance health updates, request allocation decisions, instance lifecycle changes, anomaly detection, and configuration change recommendations. These events are propagated through high-performance message queues (such as Apache Kafka) to ensure the scalability and reliability of the system.

[0128] The innovation of this embodiment lies in the modular design, where each module focuses on a specific function, improving the maintainability and scalability of the system; using an event-driven architecture to achieve loose coupling between modules, improving the responsiveness and flexibility of the system; decomposing complex health management logic into manageable components, each of which can be optimized and upgraded independently; achieving automatic tuning of system performance through continuous data analysis and configuration optimization; integrating anomaly detection and automatic recovery mechanisms to improve the reliability and self-healing ability of the system.

[0129] This system architecture can not only effectively manage short-lifecycle instances in the Serverless platform, but also provide a scalable and efficient framework to implement complex health management strategies. Through the collaborative work of various modules, the system can quickly respond to changes, optimize performance, detect and recover from abnormal conditions, thereby significantly improving the overall performance and reliability of the Serverless platform.

[0130] It should be noted that the specific implementation details and parameter settings may need to be adjusted according to the actual deployment environment and performance requirements. In addition, this architecture also provides a good foundation for integrating more advanced features (such as machine learning-driven predictive maintenance) in the future.

Claims

1. A short-lifecycle instance health management method for a Serverless FaaS platform, characterized in that: The following steps are involved: a) assign a unique identifier to each instance; b) After each request is processed, the health score of the instance is calculated based on a set of predefined lightweight health indicators; c) Update the cumulative health score of the instance; d) Decide whether to continue allocating new requests to the instance based on the accumulated health score; e) When the instance idle time exceeds a preset threshold, the instance is released.

2. The method according to claim 1, characterized in that: The lightweight health indicator set includes startup time, memory usage, single request processing time and request success rate.

3. The method according to claim 1, characterized in that: The cumulative health score is calculated as follows: CumulativeScore = (PreviousScore * RequestCount + CurrentScore) / (RequestCount + 1) Among them, PreviousScore is the previous cumulative score, RequestCount is the number of processed requests, and CurrentScore is the health score of the current request.

4. The method according to claim 1, characterized in that: The following steps are also included: When the cumulative health score of an instance falls below a predetermined threshold, the instance is marked as unavailable and no new requests are allocated to it.

5. The method according to claim 1, characterized in that: The following steps are also included: Extend the amount of time that instances with cumulative health scores above a certain threshold are allowed to remain idle.

6. The method according to claim 1, characterized in that The following steps are also included: Dynamically adjust the number of concurrent requests allowed for a single instance based on the cumulative health score of the instance.

7. The method according to claim 1, characterized in that The following steps are also included: Collect and analyze data from all instances of the same function to assess the overall health of the function.

8. The method according to claim 1, characterized in that: The following steps are also included: Compare the performance of different configuration instances and generate optimal configuration recommendations.

9. The method according to claim 1, characterized in that: The following steps are also included: Use statistical methods to detect outliers and quickly identify instances that behave unusually.

10. A Serverless FaaS platform instance health management system for implementing the method described in any one of claims 1 to 9, characterized in that: include: An instance identification module, used to assign a unique identifier to each instance; The health score module is used to calculate the health score and cumulative health score of the instance; A request allocation module, used to determine the request allocation of instances based on the accumulated health scores; The instance management module is used to manage the life cycle of instances, including releasing idle instances; A data analysis module that performs cross-instance data analysis and anomaly detection.

Images