Elastic resource scheduling method and device of FaaS platform, electronic equipment and storage medium

Abstract

The embodiment of the invention provides a resource flexible scheduling method and device of a FaaS platform, electronic equipment and a storage medium, and relates to the technical field of cloud computing, the method comprises the following steps: obtaining a timed scaling strategy, the timed scaling strategy comprises a strategy scheduling expression and a strategy reserved instance number, then analyzing the scheduling expression to obtain the next execution time, and obtaining the next execution time; and recording corresponding historical execution time, extracting a target timing scaling strategy from the timing scaling strategies based on the current time and the historical execution time, reserving the number of examples according to a target strategy corresponding to the target timing scaling strategy, adjusting the number of actual operation examples of the function, and finally calculating a waiting time interval of next scheduling. And after waiting for the waiting time interval, re-executing the strategy determination process in the previous process, thereby realizing a built-in high-precision scheduling cycle independent of an external scheduling component, and intelligently and automatically selecting the most suitable strategy to take effect when a plurality of strategy triggering opportunities are overlapped.

Description

Technical Field

[0001] This invention relates to the field of cloud computing technology, and in particular to a resource elastic scheduling method for a FaaS platform, a resource elastic scheduling device for a FaaS platform, an electronic device, and a computer-readable storage medium. Background Technology

[0002] Serverless computing is a key form of cloud computing, where Function as a Service (FaaS) platforms allow developers to focus on business logic without managing the underlying infrastructure. FaaS platforms typically create and destroy function instances on demand to achieve efficient resource utilization. However, in high-concurrency scenarios, cold starts of function instances can lead to response delays, impacting user experience. To address the cold start problem, various technologies have been employed, but issues remain, including poor fault tolerance, a lack of multi-strategy conflict handling mechanisms, limited scheduling accuracy, and reliance on external scheduling components. Summary of the Invention

[0003] The present invention provides a resource elastic scheduling method, apparatus, electronic device, and computer-readable storage medium for a FaaS platform, in order to solve or partially solve the problems of insufficient fault tolerance, multi-policy conflicts, and limited scheduling accuracy and availability caused by dependence on external components in the resource scheduling process of the FaaS platform.

[0004] This invention discloses a resource elastic scheduling method for a FaaS platform, comprising: Step 1: Obtain at least one timed scaling policy, wherein the timed scaling policy includes at least a policy scheduling expression and a policy reserved instance number; Step 2: Parse the policy scheduling expression to obtain the next execution time corresponding to each of the timed scaling policies, and record the historical execution time of the last execution of the timed scaling policy; Step 3: Based on the current time and the historical execution time, extract the target timed scaling strategy that needs to be activated from the timed scaling strategy; Step 4: Adjust the actual number of running instances of the function in the FaaS platform according to the target strategy reserved instance number corresponding to the target timed scaling strategy; Step 5: Calculate the waiting time interval for the next scheduling based on the next execution time corresponding to all the timed scaling strategies, and wait until the waiting time interval is reached before jumping to step 2.

[0005] In some feasible implementations, the method further includes: Obtain the resource reservation configuration defined for the function, the resource reservation configuration including the default number of reserved instances; If the target timed scaling strategy that needs to be activated cannot be extracted from the timed scaling strategy based on the current time and the historical execution time, then the default reserved instance number will be used as the final target instance number. Adjust the actual number of running instances of functions in the FaaS platform according to the final target number of instances.

[0006] In some feasible implementations, the step of extracting the target timed scaling policy that needs to be activated from the timed scaling policy based on the current time and the historical execution time includes: Select timed scaling strategies that have historical execution times that are no later than the current time to form a candidate strategy set; The timed scaling strategy whose historical execution time is closest to the current time in the candidate strategy set is selected as the target timed scaling strategy.

[0007] In some feasible implementations, the step of extracting the target timed scaling strategy that needs to be activated from the timed scaling strategy based on the current time and the historical execution time further includes: If there are multiple timed scaling strategies with the same historical execution time in the candidate strategy set, then the timed scaling strategy with the largest number of strategy reserved instances is selected from the candidate strategy set as the target timed scaling strategy.

[0008] In some feasible implementations, after adjusting the actual number of running instances of functions in the FaaS platform according to the target strategy reserved instance number corresponding to the target timed scaling strategy, the method further includes: If the adjustment operation fails, after waiting for a backoff delay, the number of instances reserved according to the target strategy corresponding to the target timed scaling strategy will be adjusted to adjust the actual number of running instances of the function in the FaaS platform until the adjustment is successful or the maximum number of retries is reached.

[0009] In some feasible implementations, adjusting the actual number of running instances of functions in the FaaS platform includes: Obtain the function corresponding to the FaaS platform, and obtain at least one deployment version corresponding to the function and the traffic weight corresponding to each deployment version; The target number of instances corresponding to each deployment version is obtained by calculating the number of instances reserved by the target strategy and the traffic weight corresponding to each deployment version. Adjust the actual number of running instances for each of the aforementioned deployment versions to the target number of instances.

[0010] In some feasible implementations, the traffic weight is in percentage form. The calculation of the target number of instances for each deployment version using the target strategy's reserved instance count and the traffic weight corresponding to each deployment version includes: Multiply the number of instances reserved for the target strategy by the percentage corresponding to the deployment version, and round the result to the nearest integer to obtain the target number of instances corresponding to the deployment version.

[0011] In some feasible implementations, calculating the waiting time interval for the next scheduling based on the next execution time corresponding to all the timed scaling strategies includes: From the next execution intervals corresponding to all the timed scaling strategies, select the earliest execution time with the smallest value, and calculate the time difference between the earliest execution time and the current time; The waiting time interval for the next scheduling is calculated based on the time difference.

[0012] In some feasible implementations, calculating the waiting time interval for the next scheduling based on the time difference includes: If the time difference is greater than a preset threshold, the waiting time interval for the next scheduling is calculated using the preset threshold and the time difference. If the time difference is less than or equal to the preset threshold, then the time difference will be used as the waiting time interval for the next scheduling.

[0013] This invention also discloses a resource elastic scheduling device for a FaaS platform, comprising: The strategy acquisition module is used to acquire at least one timed scaling strategy, wherein the timed scaling strategy includes at least a strategy scheduling expression and a number of strategy reserved instances. The execution time calculation module is used to parse the strategy scheduling expression, obtain the next execution time corresponding to each of the timed scaling strategies, and record the historical execution time of the last execution of the timed scaling strategy. The strategy extraction module is used to extract the target timed scaling strategy that needs to be effective from the timed scaling strategy based on the current time and the historical execution time. The adjustment module is used to adjust the actual number of running instances of functions in the FaaS platform according to the number of instances reserved for the target strategy corresponding to the target timed scaling strategy. The interval calculation module is used to calculate the waiting time interval for the next scheduling based on the next execution time corresponding to all the timed scaling strategies, and after waiting for the waiting time interval, jump to the step of parsing the strategy scheduling expression, obtaining the next execution time corresponding to each of the timed scaling strategies, and recording the historical execution time of the last execution of the timed scaling strategy.

[0014] In some feasible implementations, the apparatus further includes: A configuration acquisition module is used to acquire the resource reservation configuration defined for the function, the resource reservation configuration including the default number of reserved instances; The configuration settings module is used to set the default reserved instance number as the final target instance number if the target timed scaling strategy that needs to be effective cannot be extracted from the timed scaling strategy based on the current time and the historical execution time. The configuration adjustment module is used to adjust the actual number of running instances of functions in the FaaS platform according to the final target number of instances.

[0015] In some feasible implementations, the strategy extraction module is specifically used for: Select timed scaling strategies that have historical execution times that are no later than the current time to form a candidate strategy set; The timed scaling strategy whose historical execution time is closest to the current time in the candidate strategy set is selected as the target timed scaling strategy.

[0016] In some feasible implementations, the strategy extraction module is further used for: If there are multiple timed scaling strategies with the same historical execution time in the candidate strategy set, then the timed scaling strategy with the largest number of strategy reserved instances is selected from the candidate strategy set as the target timed scaling strategy.

[0017] In some feasible implementations, the apparatus further includes: The retry module is used to adjust the actual number of running instances of the function in the FaaS platform according to the number of instances reserved according to the target strategy corresponding to the target timed scaling strategy after waiting for a backoff delay if the adjustment operation fails, until the adjustment is successful or the maximum number of retry attempts is reached.

[0018] In some feasible implementations, the adjustment module is specifically used for: Obtain the function corresponding to the FaaS platform, and obtain at least one deployment version corresponding to the function and the traffic weight corresponding to each deployment version; The target number of instances corresponding to each deployment version is obtained by calculating the number of instances reserved by the target strategy and the traffic weight corresponding to each deployment version. Adjust the actual number of running instances for each of the aforementioned deployment versions to the target number of instances.

[0019] In some feasible implementations, the traffic weight is in percentage form, and the adjustment module is specifically used for: Multiply the number of instances reserved for the target strategy by the percentage corresponding to the deployment version, and round the result to the nearest integer to obtain the target number of instances corresponding to the deployment version.

[0020] In some feasible implementations, the interval calculation module is specifically used for: From the next execution intervals corresponding to all the timed scaling strategies, select the earliest execution time with the smallest value, and calculate the time difference between the earliest execution time and the current time; The waiting time interval for the next scheduling is calculated based on the time difference.

[0021] In some feasible implementations, the interval calculation module is specifically used for: If the time difference is greater than a preset threshold, the waiting time interval for the next scheduling is calculated using the preset threshold and the time difference. If the time difference is less than or equal to the preset threshold, then the time difference will be used as the waiting time interval for the next scheduling.

[0022] This invention also discloses an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; The memory is used to store computer programs; When the processor executes a program stored in the memory, it implements the method described in the embodiments of the present invention.

[0023] This invention also discloses a computer-readable storage medium storing instructions that, when executed by one or more processors, cause the processors to perform the methods described in this invention.

[0024] The embodiments of the present invention have the following advantages: In this embodiment of the invention, during the elastic scheduling of resources on the FaaS platform, at least one timed scaling policy is obtained. Each timed scaling policy includes at least a policy scheduling expression and a number of policy reserved instances. The scheduling expression is then parsed to obtain the next execution time corresponding to each timed scaling policy, and the historical execution time of the previous execution of the timed scaling policy is recorded. Based on the current time and the historical execution time, the target timed scaling policy that needs to be activated is extracted from the timed scaling policies. Then, according to the target policy reserved instance number corresponding to the target timed scaling policy, the actual number of running instances of functions in the FaaS platform is adjusted. Finally, based on all timed scaling policies... The system calculates the waiting time interval for the next scheduling based on the corresponding next execution time, and waits until the waiting time interval is reached before re-executing the strategy determination process described above. This achieves a built-in high-precision scheduling loop that does not rely on external scheduling components, effectively eliminating the risk of single point of failure and improving system availability. At the same time, by combining historical execution time with the current time for strategy decision-making, the system can intelligently and automatically select the most appropriate strategy to take effect when multiple strategy triggering times overlap, solving the problem of multi-strategy conflicts and avoiding resource configuration chaos. This not only ensures service quality during peak business periods but also achieves refined and automated resource management, reducing operational complexity. Attached Figure Description

[0025] Figure 1 This is a flowchart illustrating the steps of a resource elastic scheduling method for a FaaS platform provided in this embodiment of the invention. Figure 2 This is a structural block diagram of a resource elastic scheduling device for a FaaS platform provided in an embodiment of the present invention. Detailed Implementation

[0026] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0027] As an example, in the relevant resource scheduling process, a timed scheduling component is used for resource scheduling. However, in this timed scheduling process, at least the following exists: 1. Insufficient fault tolerance: When the Kubernetes cluster is overloaded or an anomaly occurs, the scheduled task component may fail to trigger on time or may trigger with a delay, resulting in the inability to adjust the number of reserved instances in a timely manner, which affects service quality; 2. Lack of conflict handling mechanism: It cannot effectively handle scenarios where multiple scaling strategies are configured for the same function and are triggered simultaneously, increasing the complexity and management difficulty of scaling strategy configuration.

[0028] In this invention, during the elastic scheduling of resources on the FaaS platform, at least one timed scaling policy is obtained. Each timed scaling policy includes at least a policy scheduling expression and a number of policy reserved instances. The scheduling expression is then parsed to obtain the next execution time for each timed scaling policy, and the historical execution time of the previous execution of each policy is recorded. Based on the current time and the historical execution time, the target timed scaling policy that needs to be activated is extracted from the timed scaling policies. Then, according to the target policy reserved instance number corresponding to the target timed scaling policy, the actual number of running instances of functions in the FaaS platform is adjusted. Finally, based on all timed scaling policies... The system calculates the waiting time interval for the next scheduling based on the corresponding next execution time, and waits until the waiting time interval is reached before re-executing the strategy determination process described above. This achieves a built-in high-precision scheduling loop that does not rely on external scheduling components, effectively eliminating the risk of single point of failure and improving system availability. At the same time, by combining historical execution time with the current time for strategy decision-making, the system can intelligently and automatically select the most appropriate strategy to take effect when multiple strategy triggering times overlap, solving the problem of multi-strategy conflicts and avoiding resource configuration chaos. This not only ensures service quality during peak business periods but also achieves refined and automated resource management, reducing operational complexity.

[0029] To enable those skilled in the art to better understand the technical solutions in the embodiments of the present invention, some technical features involved in the embodiments of the present invention are explained and described below: FaaS platform: Refers to Function as a Service platform, which is a serverless computing implementation method.

[0030] Function: Refers to an executable unit on a function-as-a-service platform, including function code and runtime environment.

[0031] Function instance: A Pod that executes a function in a Kubernetes cluster using Function Compute.

[0032] Resource timed elastic scaling: refers to a technical solution that automatically adjusts the number of function instances according to preset time rules.

[0033] Kubernetes Controller: Refers to a complete technical solution based on the Kubernetes Operator controller pattern. The Operator controller is a custom controller that extends the Kubernetes API and can listen for and respond to changes in specific resources in the cluster, enabling automated operation and management.

[0034] Reference Figure 1The diagram illustrates a flowchart of a resource elastic scheduling method for a FaaS platform provided in an embodiment of the present invention, which may specifically include the following steps: Step 1: Obtain at least one timed scaling policy, wherein the timed scaling policy includes at least a policy scheduling expression and a policy reserved instance number; In this embodiment of the invention, the resource elastic scheduling process begins with the acquisition of the timed scaling policy. Specifically, the controller in the FaaS platform (such as the Reconciler based on KubernetesOperator) can obtain the elastic scaling configuration defined for the function by listening to a custom resource (CRD) named Qualifier.

[0035] Optionally, the Qualifier resource defines at least one scheduled scaling policy (ScheduledAction). Each scheduled scaling policy is essentially a structure containing at least two core fields: ScheduleExpression (policy scheduling expression) and Target (policy reserved instance count). The policy scheduling expression is a string used to precisely define the execution time, supporting standard cron format, such as "cron(09**1-5)" indicating execution at 9 AM on every weekday. The policy reserved instance count is an integer representing the total number of running instances expected to be reserved for the function when the policy takes effect.

[0036] Step 2: Parse the policy scheduling expression to obtain the next execution time corresponding to each of the timed scaling policies, and record the historical execution time of the last execution of the timed scaling policy; After obtaining the corresponding policy configuration, the system can parse the policy scheduling expression to determine the future execution plan. Specifically, the controller iterates through each ScheduledAction in the Qualifier, identifies strings in the ScheduleExpression field in the format "cron(...)", and extracts the cron expression within the parentheses. Then, it uses a built-in cron expression parsing library (such as the robfig / cron library in Go) to parse the expression. The parser can calculate the precise time when the scheduled scaling policy will be triggered next based on the current system time, convert it to a Unix timestamp format, and update the NextExecuteTime field of the policy.

[0037] Meanwhile, the system maintains the execution history of the timed scaling strategy. Each time a new NextExecuteTime is calculated, the old, expired NextExecuteTime is transferred and stored in the LastExecuteTime field as the historical execution time of the last execution of the strategy. Thus, based on the continuous tracking and updating of this pair of timestamps (LastExecuteTime and NextExecuteTime), a key time dimension can be provided for subsequent intelligent decision-making among multiple strategies.

[0038] Step 3: Based on the current time and the historical execution time, extract the target timed scaling strategy that needs to be activated from the timed scaling strategy; Once the next execution time for each timed scaling strategy is determined and the corresponding historical execution time is recorded, the system can extract the target timed scaling strategy that needs to take effect at the moment based on the current time and the historical execution time. In other words, it can select a timed scaling strategy that should take effect at the current moment so that resources can be elastically scheduled based on that timed scaling strategy.

[0039] In some feasible implementations, when selecting the target timed scaling strategy that should take effect at the current moment, a candidate strategy set can be formed by first selecting timed scaling strategies with historical execution times that are no later than the current time. Then, the timed scaling strategy with the historical execution time closest to the current time in the candidate strategy set is selected as the target timed scaling strategy. Thus, through the two-level judgment logic of "validity screening" and "time proximity comparison", the system can ensure that the strategy that has been triggered most recently is selected as the current effective strategy. This not only enables clear and reasonable decisions when the trigger times of multiple strategies overlap, effectively avoiding resource configuration conflicts and uncertainties, but also prevents the mis-execution of expired strategies, ensuring the timeliness of resource adjustments and the matching degree of business scenarios, and improving the accuracy and robustness of the overall scheduling decision.

[0040] In its implementation, the controller first filters out all "valid" strategies. The criteria for "valid" include: the strategy is within its defined effective time range, and its LastExecuteTime is not empty and its value is not greater than the current time. All strategies meeting these conditions are grouped into a candidate strategy set. Subsequently, the system iterates through this candidate strategy set, calculating the absolute difference between the LastExecuteTime of each timed scaling strategy in each candidate strategy combination and the current time. The system then selects the timed scaling strategy with the smallest difference—that is, the one whose historical execution time is closest to the current time—as the target timed scaling strategy to be activated. This mechanism effectively ensures that the system always tends to select strategies that are "most recently triggered," whose configured target instance count is most likely to match the current business situation.

[0041] Furthermore, if multiple timed scaling strategies with the same historical execution time exist in the candidate strategy set, the timed scaling strategy with the largest number of reserved instances will be selected as the target timed scaling strategy. Specifically, when multiple timed scaling strategies have the same LastExecuteTime (e.g., multiple strategies are configured to trigger at the same time), the system will enter a secondary decision-making process. In this case, the system will compare the fields corresponding to the number of reserved instances of these timed scaling strategies and select the timed scaling strategy with the largest value as the final winner. Based on this "choose the higher value" selection principle, the aim is to prioritize service performance and stability when business needs are unclear, and avoid service degradation due to insufficient instances during peak traffic or critical business periods.

[0042] Furthermore, the system can also obtain the resource reservation configuration defined for the function. The resource reservation configuration includes the default number of reserved instances. If the target timed scaling policy that needs to be effective cannot be extracted from the timed scaling policy based on the current time and the historical execution time, the default number of reserved instances is used as the final target number of instances. The actual number of running instances of the function in the FaaS platform can then be adjusted according to the final target number of instances, thereby constructing a complete resource guarantee mechanism. This provides a reliable security boundary for the elastic scheduling of the system. Through this mechanism, it can be ensured that at any point in time, even if no timed policy is in an effective state (such as whether it is because the time window of the policy configuration has not arrived or the system has not yet experienced a complete scheduling cycle after initialization), the function can obtain a baseline level of resource guarantee. This fundamentally avoids the instance count dropping to zero or resource gaps caused by the "window period" of the policy, ensuring the minimum bottom line of service availability, providing a stable resource foundation for the system, and significantly reducing the complexity of configuration management. This eliminates the need for operation and maintenance personnel to configure cumbersome policies to cover all time periods, thereby enhancing the system's self-healing capability and improving the overall operation and maintenance efficiency.

[0043] In its implementation, the system also defines a corresponding security fallback mechanism. Besides the scheduled policies, the Qualifier resource includes a DefaultTarget field, which represents the default number of reserved instances. If, during the policy selection process, no scheduled policy meets the activation conditions (e.g., the current time is not within the activation window of any policy, or all policies have not yet been triggered for the first time), the system can use the value of DefaultTarget as the final target number of instances. This ensures a minimum level of service availability, provides a stable resource base for the system, and significantly reduces the complexity of configuration management. It eliminates the need for operations personnel to configure cumbersome policies to cover all time periods, enhancing the system's self-healing capabilities and improving overall operational efficiency.

[0044] Step 4: Adjust the actual number of running instances of the function in the FaaS platform according to the target strategy reserved instance number corresponding to the target timed scaling strategy; Once the target timed scaling strategy is selected, the defined macro instance count can be converted into specific execution operations. That is, the actual number of running instances of functions in the FaaS platform is adjusted according to the target strategy reserved instance count corresponding to the target timed scaling strategy.

[0045] When adjusting the actual number of running instances of a function, the function corresponding to the FaaS platform can be obtained first, along with at least one deployment version of the function and the traffic weight of each deployment version. Then, the target number of instances is calculated using the target strategy's reserved instance count and the traffic weight of each deployment version. Finally, the actual number of running instances of each deployment version is adjusted to the target number of instances. This weight-based allocation mechanism perfectly supports multi-version parallel scenarios such as canary releases and A / B testing, ensuring that each version receives corresponding computing resources according to the preset traffic ratio. This guarantees resource supply during the new version's deployment process while maintaining the stability of the old version's service. Furthermore, by dynamically allocating the total resource quota to each version according to the weight, the system achieves overall elastic scaling while maintaining a relative balance of resources between versions. This provides underlying resource guarantees for complex release strategies and traffic management, significantly improving the adaptability and reliability of the FaaS platform in modern software delivery processes.

[0046] Specifically, when adjusting the actual number of running instances of a function, the system performs weighted multi-version resource quota allocation. The controller queries the RevisionConfigs list in the Qualifier resource, which defines multiple deployment versions belonging to the same function and their corresponding resource weights. The target policy reserved instance count (i.e., the total target instance count for this Qualifier) ​​obtained in the preceding process is used as a shared resource pool, and an independent resource quota is calculated for each version based on its RevisionWeight. For each deployment version, the formula for calculating the target instance count is: Qualifier target reserved instance count × (RevisionWeight / 100). After calculation, the system checks whether the current actual number of running instances for each version matches its calculated target instance count. If they do not match, the FaaS function instance resource controller is called to scale the instance count for that version to match the target value. This achieves precise, weighted resource quota management for multiple versions under a single function alias (Qualifier), ensuring that total resources are allocated proportionally across different versions, providing underlying support for multi-version function deployment and resource isolation.

[0047] In some examples, traffic weights can be expressed as percentages. In calculating the target number of instances, the system multiplies the target policy reserved instance count by the percentage corresponding to the deployment version and rounds the result to the nearest integer. Specifically, to ensure the instance count is an integer, rounding is performed during the calculation. After performing floating-point multiplication, the system applies rounding rules to the result. For example, with a total of 10 instances and a version weight of 25%, the calculated value is 2.5, which, after rounding, results in a target instance count of 3. Simultaneously, the system ensures that the sum of the target instance counts for all versions equals the total target instance count. If necessary, the number for the last version is fine-tuned to meet the sum constraint. This "rounding + sum check" mechanism ensures that the number of instances allocated to each version is closest to its theoretical weight, maintaining the fairness and accuracy of resource allocation. Furthermore, the final fine-tuning ensures strict conservation of total system resources, avoiding resource over- or under-allocation issues caused by rounding errors.

[0048] Furthermore, if the adjustment operation fails during the execution of the corresponding adjustment operation, after waiting for a backoff delay, the actual number of running instances of the function in the FaaS platform is adjusted according to the number of reserved instances corresponding to the target timed scaling strategy, until the adjustment is successful or the maximum number of retries is reached. By introducing a retry mechanism with exponential backoff characteristics, the fault tolerance and eventual consistency guarantee of the system in the face of transient, non-fatal failures are significantly improved. This ensures that the elastic scaling strategy can still have a very high execution success rate in the case of non-ideal network environment or temporary abnormality of the underlying platform, and enhances the robustness and reliability of the entire scheduling system.

[0049] In its implementation, after calling the FaaS platform's management interface to adjust the number of instances, the system synchronously checks the return result of the operation. When an operation fails due to temporary faults such as network fluctuations, a momentary shortage of FaaS platform resources, or interface rate limitations, the system does not immediately abandon the execution of the scaling strategy but initiates a retry mechanism. The system can maintain a retry counter, initially set to zero. Each time an adjustment operation fails, the counter increments. Before each retry, the system calculates a backoff delay based on the current number of failures. Optionally, in a preferred implementation, an exponential backoff algorithm can be used, with the backoff delay calculated as: Backoff Delay = Base Delay × (2^(Current Retry Count - 1)). For example, if the base delay is set to 2 seconds, the first retry waits 2 seconds, the second 4 seconds, the third 8 seconds, and so on. This incremental waiting time helps avoid request flooding when the FaaS platform is continuously congested, providing the system with a longer recovery time.

[0050] After waiting for the specified backoff delay, the system will re-initiate the instance reconfiguration request. This "execute-check-wait-retry" loop will continue until one of the following two conditions is met: Adjustment successful: The system received a successful operation response from the FaaS platform, indicating that the scaling strategy has been successfully applied. Subsequently, the retry counter was reset, and the process continued.

[0051] Maximum retry count reached: The system presets a maximum number of retries (e.g., 3 or 5). When the retry counter reaches this limit, the system will terminate the retry operation of this strategy and log an error message to avoid getting stuck in an infinite retry loop.

[0052] By introducing a retry mechanism with exponential backoff characteristics, the system's fault tolerance and eventual consistency guarantee in the face of transient, non-fatal failures are significantly improved. This ensures that the elastic scaling strategy can still have a very high execution success rate in the event of non-ideal network environments or brief anomalies of the underlying platform, thereby enhancing the robustness and reliability of the entire scheduling system.

[0053] Step 5: Calculate the waiting time interval for the next scheduling based on the next execution time corresponding to all the timed scaling strategies, and wait until the waiting time interval is reached before jumping to step 2.

[0054] After completing the current policy adjustment, in order to achieve continuous and self-driven scheduling, the system can also plan the time for the next policy adjustment. That is, the system can calculate the waiting time interval for the next scheduling based on the next execution time corresponding to all timed scaling policies, and wait until the waiting time interval is reached before jumping to the process of parsing the policy expression and re-selecting policies. This realizes a built-in high-precision scheduling loop that does not rely on external scheduling components, effectively eliminating the risk of single point of failure and improving system availability. At the same time, by combining historical execution time with the current time for policy decision-making, the system can intelligently and automatically select the most appropriate policy to take effect when multiple policy triggering times overlap, solving the problem of multi-policy conflicts and avoiding resource configuration chaos. This not only ensures service quality during peak business periods, but also achieves refined and automated resource management and reduces operational complexity.

[0055] In some feasible implementations, during the determination of the waiting time interval, the system can select the earliest execution time with the smallest value from all the next execution intervals corresponding to the timed scaling strategies, calculate the time difference between the earliest execution time and the current time, and then calculate the waiting time interval for the next scheduling based on the time difference. By globally scanning and accurately locating the earliest scheduling event that is about to occur, the system ensures that the scheduling loop can always respond to the next most urgent task in a timely manner, fundamentally avoiding scheduling delays that may be caused by fixed inspection cycles. This allows the system to be activated at precise time points without relying on high-frequency polling, which not only minimizes unnecessary consumption of computing resources and idle overhead, but also lays the core foundation for achieving high-precision timed scheduling and ensures the timeliness of resource adjustments.

[0056] Specifically, after calculating the time difference, if the time difference is greater than a preset threshold, the waiting time interval for the next scheduling is calculated using the preset threshold and the time difference; if the time difference is less than or equal to the preset threshold, the time difference is used as the waiting time interval for the next scheduling. Thus, when the time until the next execution is long, by introducing a preset threshold and using an asymptotic approximation algorithm (such as preset threshold + (time difference - preset threshold) / 2), the long-term sleep and resource occupation of the system while waiting for long-term tasks are effectively avoided. At the same time, through periodic mid-cycle wake-ups, the system is provided with a rapid response capability to new strategies or configuration changes, ensuring that even if a scheduling is missed for some reason, it can be quickly corrected in the next inspection cycle.

[0057] In some examples, the system can employ a dynamic, fault-tolerant algorithm to determine the waiting time interval. A preset threshold, such as 5 seconds, is set. If the time difference T1 is greater than 5 seconds, the waiting time interval is set to 5 + (T1 - 5) / 2 seconds. This "halving" approximation method avoids excessively frequent wake-up checks (wasting resources) when the next execution time is still far away, while ensuring that the check interval gradually shortens as the execution time approaches, improving the timeliness of triggering. More importantly, it guarantees that if the system misses an accurate trigger due to overload or other reasons, it can compensate for the missed trigger in the next calculation cycle. If the time difference T1 is less than or equal to 5 seconds, it indicates that execution is imminent, and the waiting time interval is set to T1 to ensure timely triggering. After calculating the effective waiting time interval, the controller (or its scheduling loop) enters a sleep state, waiting for that duration. Once the wait ends, the process jumps back to the process of parsing the policy expression in the aforementioned embodiment and starts a new round of parsing, decision-making, and execution loops, thereby realizing a fully automatic, highly available built-in scheduler.

[0058] It should be noted that the embodiments of the present invention include, but are not limited to, the examples described above. It is understood that those skilled in the art can make further settings according to actual needs under the guidance of the ideas in the embodiments of the present invention, and the present invention does not limit such settings.

[0059] In this embodiment of the invention, during the elastic scheduling of resources on the FaaS platform, at least one timed scaling policy is obtained. Each timed scaling policy includes at least a policy scheduling expression and a number of policy reserved instances. The scheduling expression is then parsed to obtain the next execution time corresponding to each timed scaling policy, and the historical execution time of the previous execution of the timed scaling policy is recorded. Based on the current time and the historical execution time, the target timed scaling policy that needs to be activated is extracted from the timed scaling policies. Then, according to the target policy reserved instance number corresponding to the target timed scaling policy, the actual number of running instances of functions in the FaaS platform is adjusted. Finally, based on all timed scaling policies... The system calculates the waiting time interval for the next scheduling based on the corresponding next execution time, and waits until the waiting time interval is reached before re-executing the strategy determination process described above. This achieves a built-in high-precision scheduling loop that does not rely on external scheduling components, effectively eliminating the risk of single point of failure and improving system availability. At the same time, by combining historical execution time with the current time for strategy decision-making, the system can intelligently and automatically select the most appropriate strategy to take effect when multiple strategy triggering times overlap, solving the problem of multi-strategy conflicts and avoiding resource configuration chaos. This not only ensures service quality during peak business periods but also achieves refined and automated resource management, reducing operational complexity.

[0060] To enable those skilled in the art to better understand the technical solutions in the embodiments of the present invention, the following examples are provided for illustrative purposes: As an example, by defining timing strategies and scheduling expressions, the number of function instances can be automatically and precisely adjusted. This mainly involves the following process: 1) Define function resource configuration, including the default number of reserved instances and the timed scaling strategy; 2) Parse the scheduling expression in the timed scaling strategy; 3) Calculate the next execution time and record the historical execution time; 4) Calculate the current timing policy that should take effect based on the current time; 5) Determine if the target reserved instance count of the effective timing strategy is equal to the current function instance count. If they are not equal, apply the target reserved instance count to the function instances. 6) Calculate and analyze the time required for the next operation, and re-enqueue the data until the specified time has elapsed before re-execution.

[0061] The above process can be implemented based on Kubernetes Custom Resources (CRDs) and the controller pattern, and mainly includes the following components: 1) Qualifier resource: Kubernetes custom resource (CRD), which defines the reserved instance configuration and timed scaling strategy for functions; 2) Reconciler controller: The k8sOperator controller is responsible for monitoring changes in Qualifier resources and executing timed scaling calculation logic; 3) Faas function instance resource controller: Receives the reserved instance configuration issued by the Reconciler controller and performs the actual instance scaling.

[0062] In addition, the Qualifier resource structure definition contains the following fields: - QualifyName: Alias ​​or version name; - DefaultTarget: The default number of reserved instances. This value is used when there is no scheduled scaling. - RevisionConfigs: The RevisionConfig (version mapping table) of the Qualifier function. A Qualifier can have multiple RevisionConfigs; - ScheduledActions: List of scheduling policies.

[0063] In addition, the ScheduledAction structure definition includes the following fields: - Name: Strategy name; - ScheduleExpression: Schedule expression, supports cron format; - QualifyName: Alias, version name; - Target: The target number of reserved instances; - StartTime: Policy activation start time (optional); - EndTime: Policy effective end time (optional); - LastExecuteTime: The last execution time (Unix timestamp, unit: seconds); - NextExecuteTime: The time of the next execution (Unix timestamp unit: seconds).

[0064] The RevisionConfig (hereinafter referred to as the version mapping table) structure definition contains the following fields: - Revision: The function Revision; - RevisionWeight: Revision weight. The sum of the weights of all RevisionConfigs for a Qualifier is 100.

[0065] Based on the above system architecture and data structures, the system can include the following process when implementing timed elastic scaling of resources: 4.1 When creating or updating the function Qualifier, or waiting for a specified time to re-execute, the system first traverses all ScheduledActions from the Qualifier, extracting the cron expression from the ScheduleExpression of each ScheduledAction. Specifically, the system recognizes strings in the format "cron(expression)" and extracts the expression within the parentheses. Then, the system uses a cron parser to parse the extracted expression, supporting precise timing control at the second, minute, hour, day, month, and day of the week, achieving second-level precision for scheduled tasks.

[0066] 4.2 The system calculates the next execution time of each scheduled action based on the parsed cron expression and converts it into a Unix timestamp format and stores it in the Qualifier.

[0067] The specific logic is as follows: 1) If the next execution time of the strategy is empty, or the newly calculated next execution time is earlier than the currently recorded next execution time, then update the next execution time and clear the previous execution time; 2) If the newly calculated next execution time is later than the next execution time of the current record, then the next execution time of the current record is transferred to the previous execution time field, and the next execution time is updated.

[0068] In this way, the system can accurately track the execution history of each strategy, providing a basis for handling multi-strategy conflicts.

[0069] 4.3 When multiple timing policies are in effect simultaneously, the system selects the optimal policy using the following rules: 1) First, the system will iterate through all valid (meaning the current time is within the effective time range) timing policies; 2) For each strategy, check if its last execution time is greater than zero and no later than the current time; 3) If multiple strategies meet the criteria, select the strategy whose last execution time is closest to the current time as the currently active timing strategy; 4) When multiple strategies have the same last execution time, the system will select the strategy with the larger number of target instances to ensure service quality.

[0070] 5) If no strategy meets the conditions, proceed to step 4.5. This mechanism ensures that the system can make consistent and reasonable decisions when multiple strategies are in effect at the same time, avoiding resource configuration conflicts; and it can also provide compensation when the Reconciler controller fails to trigger the timed scaling calculation logic on time.

[0071] 4.4. The calculated number of reserved instances is then configured and sent to the FaaS instance resource controller. The specific steps are as follows: 1. Query the RevisionConfig in the current Qualifier; 2. For each RevisionConfig, calculate the number of function instances that should be started based on its weight (hereinafter referred to as the target reserved number of instances). The formula is: Target reserved instance count = Target reserved instance count (Qualifier) ​​* RevisionWeight / 100 3. If the number of function instances currently running in each version is not equal to the target reserved number of instances, then call the Faas function instance resource controller to change the number of running function instances to match the target reserved number of instances.

[0072] In this way, the system can transform abstract scaling strategies into concrete resource configurations, enabling precise scaling control of function instances.

[0073] 4.5. Set the re-queueing time based on the earliest scheduled execution policy: 1. From all the timed scaling policies of the current Qualifier, find the earliest execution time for the next execution; 2. Calculate the time interval T1 from the current time to the next earliest execution time; 3. If the time interval T1 exceeds 5 seconds, the re-enqueue time will be set to 5 + (T1 - 5) / 2 seconds; 4. Otherwise, use the calculated time interval T1 as the requeuing time to ensure that the system can respond to configuration changes in a timely manner.

[0074] By dynamically adjusting the delay before queuing, the system can ensure that configuration changes take effect in a timely manner according to the expected effective time. If the next execution time T1 exceeds 5 seconds, it will be queued and recalculated with a delay of 5 + (T1 - 5) / 2 seconds. This ensures that each corn expression can be calculated at least twice to determine the next execution time. Without consuming excessive computing resources, it can also adjust the number of reserved instances in the next loop in time if the system is overloaded or abnormal and the expected time for adjusting the number of reserved instances is missed.

[0075] Furthermore, a specific application scenario will be used as an example. For instance, suppose the transaction function of the target financial service platform needs to perform precise resource scheduling based on the business characteristics of different time periods. This platform has the following business characteristics: 1. Normal trading hours are from 9:00 to 16:00 on weekdays, requiring a large number of instances; 2. The market will be closed for lunch from 12:00 to 13:00 daily; therefore, the number of cases needs to be reduced. 3. Fridays from 15:00 to 16:00 are the peak time for weekly settlement, requiring additional instances; 4. The peak period for monthly settlement is from 15:00 to 16:00 on the last working day of each month, during which the number of instances needs to be maximized.

[0076] These time periods overlap, and configuring multiple strategies directly can lead to conflicts. By using the method of this invention, the following timed scaling strategy can be set: ```yaml apiVersion: faas.example.com / v1 kind: Qualifier metadata: name: trading-service namespace: financial spec: qualifyName: prod defaultTarget: 2# Defaults to keeping 2 instances. revisionConfigs: - revision: trading-processor-00004 revisionWeight: 100 scheduledActions: - name: "normal-trading-start" scheduleExpression: "cron(0 9 * * 1-5)" # Trigger at 9 AM on weekdays target: 10# Increase to 10 instances startTime: 1609459200# 2021-01-01 00:00:00 endTime: 0# No end time - name: "normal-trading-end" scheduleExpression: "cron(0 16 * * 1-5)" # Trigger at 4 PM on weekdays target: 2# Restore to 2 instances startTime: 1609459200# 2021-01-01 00:00:00 endTime: 0# No end time - name: "lunch-break-start" scheduleExpression: "cron(0 12 * * 1-5)" # Trigger at 12:00 on weekdays target: 5# Reduce to 5 instances startTime: 1609459200# 2021-01-01 00:00:00 endTime: 0# No end time - name: "lunch-break-end" scheduleExpression: "cron(0 13 * * 1-5)" # Trigger at 1 PM on weekdays target: 10# Restore to 10 instances startTime: 1609459200# 2021-01-01 00:00:00 endTime: 0# No end time - name: "friday-peak-start" scheduleExpression: "cron(0 15 * * 5)" # Triggers every Friday at 3 PM target: 15# Increase to 15 instances startTime: 1609459200# 2021-01-01 00:00:00 endTime: 0# No end time - name: "friday-peak-end" scheduleExpression: "cron(0 16 * * 5)" # Triggers every Friday at 4 PM target: 2# Restore to 2 instances startTime: 1609459200# 2021-01-01 00:00:00 endTime: 0# No end time - name: "month-end-peak-start" scheduleExpression: "cron(0 15 L * *)" # Trigger at 3 PM on the last day of each month. target: 20# Increase to 20 instances startTime: 1609459200# 2021-01-01 00:00:00 endTime: 0# No end time - name: "month-end-peak-end" scheduleExpression: "cron(0 16 L * *)" # Triggers at 4 PM on the last day of each month. target: 2# Restore to 2 instances startTime: 1609459200# 2021-01-01 00:00:00 endTime: 0# No end time ``` The system will automatically handle conflict situations based on the current time and policy execution history: 1. Typical weekday scenario: - At 9:00, the "normal-trading-start" strategy is executed, increasing the number of instances to 10. - At 12:00, the "lunch-break-start" strategy is executed, reducing the number of instances to 5. - At 13:00, the "lunch-break-end" strategy was executed, restoring the number of instances to 10. - At 16:00, the "normal-trading-end" strategy was executed, reducing the number of instances to 2. 2. Friday scenario (strategy conflict): - At 9:00, the "normal-trading-start" strategy is executed, increasing the number of instances to 10. - At 12:00, the "lunch-break-start" strategy is executed, reducing the number of instances to 5. - At 13:00, the "lunch-break-end" strategy was executed, restoring the number of instances to 10. - At 15:00, the "friday-peak-start" strategy will be executed, increasing the number of instances to 15. - At 16:00, both the "normal-trading-end" and "friday-peak-end" strategies are triggered simultaneously. The system selects the optimal strategy based on the most recent execution time. If the execution times are the same, the strategy with the larger number of target instances is selected (in this case, the target values ​​for both are the same, which is 2).

[0077] 3. Last Friday of the month scenario (multiple strategy conflicts): - If the end of the month happens to be a Friday, the "friday-peak-start" and "month-end-peak-start" strategies will be triggered simultaneously at 15:00; - The system will select the optimal strategy based on the execution time. If the execution time is the same, the strategy with the larger target number of instances will be selected, namely "month-end-peak-start" (target value 20), which increases the number of instances to 20. - At 16:00, the "normal-trading-end", "friday-peak-end" and "month-end-peak-end" strategies are triggered simultaneously. The system selects the strategy that was executed most recently. Since the execution time of the three strategies is the same, the strategy with the larger number of target instances is selected (in this case, the target value of the three strategies is the same, which is 2).

[0078] The above-described specific application scenarios demonstrate the invention's coordination capabilities in handling multiple time-related policy conflicts. The system can automatically select the optimal policy based on the policy's execution history and the target number of instances, ensuring precise resource scheduling in complex business scenarios, thus meeting business needs while avoiding resource waste.

[0079] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0080] Reference Figure 2 This diagram illustrates a structural block diagram of a resource elastic scheduling device for a FaaS platform provided in an embodiment of the present invention, which may specifically include the following modules: The strategy acquisition module 201 is used to acquire at least one timed scaling strategy, wherein the timed scaling strategy includes at least a strategy scheduling expression and a strategy reserved instance number; The execution time calculation module 202 is used to parse the strategy scheduling expression, obtain the next execution time corresponding to each of the timed scaling strategies, and record the historical execution time of the last execution of the timed scaling strategy. The strategy extraction module 203 is used to extract the target timed scaling strategy that needs to be effective from the timed scaling strategy based on the current time and the historical execution time. Adjustment module 204 is used to adjust the actual number of running instances of functions in the FaaS platform according to the number of instances reserved for the target strategy corresponding to the target timed scaling strategy. The interval calculation module 205 is used to calculate the waiting time interval for the next scheduling based on the next execution time corresponding to all the timed scaling strategies, and after waiting for the waiting time interval, jump to the step of parsing the strategy scheduling expression, obtaining the next execution time corresponding to each of the timed scaling strategies, and recording the historical execution time of the last execution of the timed scaling strategy.

[0081] In some feasible implementations, the apparatus further includes: A configuration acquisition module is used to acquire the resource reservation configuration defined for the function, the resource reservation configuration including the default number of reserved instances; The configuration settings module is used to set the default reserved instance number as the final target instance number if the target timed scaling strategy that needs to be effective cannot be extracted from the timed scaling strategy based on the current time and the historical execution time. The configuration adjustment module is used to adjust the actual number of running instances of functions in the FaaS platform according to the final target number of instances.

[0082] In some feasible implementations, the strategy extraction module is specifically used for: Select timed scaling strategies that have historical execution times that are no later than the current time to form a candidate strategy set; The timed scaling strategy whose historical execution time is closest to the current time in the candidate strategy set is selected as the target timed scaling strategy.

[0083] In some feasible implementations, the strategy extraction module is further used for: If there are multiple timed scaling strategies with the same historical execution time in the candidate strategy set, then the timed scaling strategy with the largest number of strategy reserved instances is selected from the candidate strategy set as the target timed scaling strategy.

[0084] In some feasible implementations, the apparatus further includes: The retry module is used to adjust the actual number of running instances of the function in the FaaS platform according to the number of instances reserved according to the target strategy corresponding to the target timed scaling strategy after waiting for a backoff delay if the adjustment operation fails, until the adjustment is successful or the maximum number of retry attempts is reached.

[0085] In some feasible implementations, the adjustment module is specifically used for: Obtain the function corresponding to the FaaS platform, and obtain at least one deployment version corresponding to the function and the traffic weight corresponding to each deployment version; The target number of instances corresponding to each deployment version is obtained by calculating the number of instances reserved by the target strategy and the traffic weight corresponding to each deployment version. Adjust the actual number of running instances for each of the aforementioned deployment versions to the target number of instances.

[0086] In some feasible implementations, the traffic weight is in percentage form, and the adjustment module is specifically used for: Multiply the number of instances reserved for the target strategy by the percentage corresponding to the deployment version, and round the result to the nearest integer to obtain the target number of instances corresponding to the deployment version.

[0087] In some feasible implementations, the interval calculation module is specifically used for: From the next execution intervals corresponding to all the timed scaling strategies, select the earliest execution time with the smallest value, and calculate the time difference between the earliest execution time and the current time; The waiting time interval for the next scheduling is calculated based on the time difference.

[0088] In some feasible implementations, the interval calculation module is specifically used for: If the time difference is greater than a preset threshold, the waiting time interval for the next scheduling is calculated using the preset threshold and the time difference. If the time difference is less than or equal to the preset threshold, then the time difference will be used as the waiting time interval for the next scheduling.

[0089] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0090] In addition, this invention also provides an electronic device, including: a processor, a memory, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the various processes of the resource elastic scheduling method embodiment of the FaaS platform described above and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0091] This invention also provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the various processes of the resource elastic scheduling method embodiment of the FaaS platform described above, and achieves the same technical effect. To avoid repetition, it will not be described again here. The computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0092] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0093] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, apparatus, or computer program products. Therefore, embodiments of the present invention can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of the present invention can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, EEPROM, Flash, and eMMC, etc.) containing computer-usable program code.

[0094] Embodiments of the present invention are described with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0095] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0096] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0097] Although preferred embodiments of the present invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present invention.

[0098] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0099] The resource elastic scheduling method and resource elastic scheduling device for a FaaS platform provided by the present invention have been described in detail above. Specific examples have been used to illustrate the principle and implementation of the present invention. The description of the above embodiments is only for the purpose of helping to understand the method and core idea of ​​the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation and application scope based on the idea of ​​the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A resource elastic scheduling method for a FaaS platform, characterized in that, include: Step 1: Obtain at least one timed scaling policy, wherein the timed scaling policy includes at least a policy scheduling expression and a policy reserved instance number; Step 2: Parse the policy scheduling expression to obtain the next execution time corresponding to each of the timed scaling policies, and record the historical execution time of the last execution of the timed scaling policy; Step 3: Based on the current time and the historical execution time, extract the target timed scaling strategy that needs to be activated from the timed scaling strategy; Step 4: Adjust the actual number of running instances of the function in the FaaS platform according to the target strategy reserved instance number corresponding to the target timed scaling strategy; Step 5: Calculate the waiting time interval for the next scheduling based on the next execution time corresponding to all the timed scaling strategies, and wait until the waiting time interval is reached before jumping to step 2.

2. The method according to claim 1, characterized in that, The method further includes: Obtain the resource reservation configuration defined for the function, the resource reservation configuration including the default number of reserved instances; If the target timed scaling strategy that needs to be activated cannot be extracted from the timed scaling strategy based on the current time and the historical execution time, then the default reserved instance number will be used as the final target instance number. Adjust the actual number of running instances of functions in the FaaS platform according to the final target number of instances.

3. The method according to claim 1, characterized in that, The step of extracting the target timed scaling policy that needs to be activated from the timed scaling policy based on the current time and the historical execution time includes: Select timed scaling strategies that have historical execution times that are no later than the current time to form a candidate strategy set; The timed scaling strategy whose historical execution time is closest to the current time in the candidate strategy set is selected as the target timed scaling strategy.

4. The method according to claim 3, characterized in that, The step of extracting the target timed scaling policy that needs to be activated from the timed scaling policy based on the current time and the historical execution time also includes: If there are multiple timed scaling strategies with the same historical execution time in the candidate strategy set, then the timed scaling strategy with the largest number of strategy reserved instances is selected from the candidate strategy set as the target timed scaling strategy.

5. The method according to claim 4, characterized in that, After adjusting the actual number of running instances of functions in the FaaS platform according to the target strategy reserved instance number corresponding to the target timed scaling strategy, the method further includes: If the adjustment operation fails, after waiting for a backoff delay, the number of instances reserved according to the target strategy corresponding to the target timed scaling strategy will be adjusted to adjust the actual number of running instances of the function in the FaaS platform until the adjustment is successful or the maximum number of retries is reached.

6. The method according to claim 1, characterized in that, Adjusting the actual number of running instances of functions in the FaaS platform includes: Obtain the function corresponding to the FaaS platform, and obtain at least one deployment version corresponding to the function and the traffic weight corresponding to each deployment version; The target number of instances corresponding to each deployment version is obtained by calculating the number of instances reserved by the target strategy and the traffic weight corresponding to each deployment version. Adjust the actual number of running instances for each of the aforementioned deployment versions to the target number of instances.

7. The method according to claim 6, characterized in that, The traffic weight is in percentage form. The target number of instances for each deployment version is calculated by using the number of instances reserved according to the target strategy and the traffic weight corresponding to each deployment version, including: Multiply the number of instances reserved for the target strategy by the percentage corresponding to the deployment version, and round the result to the nearest integer to obtain the target number of instances corresponding to the deployment version.

8. The method according to claim 1, characterized in that, The step of calculating the waiting time interval for the next scheduling based on the next execution time corresponding to all the timed scaling strategies includes: From the next execution intervals corresponding to all the timed scaling strategies, select the earliest execution time with the smallest value, and calculate the time difference between the earliest execution time and the current time; The waiting time interval for the next scheduling is calculated based on the time difference.

9. The method according to claim 8, characterized in that, The step of calculating the waiting time interval for the next scheduling based on the time difference includes: If the time difference is greater than a preset threshold, the waiting time interval for the next scheduling is calculated using the preset threshold and the time difference. If the time difference is less than or equal to the preset threshold, then the time difference will be used as the waiting time interval for the next scheduling.

10. A resource elastic scheduling device for a FaaS platform, characterized in that, include: The strategy acquisition module is used to acquire at least one timed scaling strategy, wherein the timed scaling strategy includes at least a strategy scheduling expression and a number of strategy reserved instances. The execution time calculation module is used to parse the strategy scheduling expression, obtain the next execution time corresponding to each of the timed scaling strategies, and record the historical execution time of the last execution of the timed scaling strategy. The strategy extraction module is used to extract the target timed scaling strategy that needs to be effective from the timed scaling strategy based on the current time and the historical execution time. The adjustment module is used to adjust the actual number of running instances of functions in the FaaS platform according to the number of instances reserved for the target strategy corresponding to the target timed scaling strategy. The interval calculation module is used to calculate the waiting time interval for the next scheduling based on the next execution time corresponding to all the timed scaling strategies, and after waiting for the waiting time interval, jump to the step of parsing the strategy scheduling expression, obtaining the next execution time corresponding to each of the timed scaling strategies, and recording the historical execution time of the last execution of the timed scaling strategy.

11. The apparatus according to claim 1, characterized in that, The device further includes: A configuration acquisition module is used to acquire the resource reservation configuration defined for the function, the resource reservation configuration including the default number of reserved instances; The configuration settings module is used to set the default reserved instance number as the final target instance number if the target timed scaling strategy that needs to be effective cannot be extracted from the timed scaling strategy based on the current time and the historical execution time. The configuration adjustment module is used to adjust the actual number of running instances of functions in the FaaS platform according to the final target number of instances.

12. The apparatus according to claim 1, characterized in that, The strategy extraction module is specifically used for: Select timed scaling strategies that have historical execution times that are no later than the current time to form a candidate strategy set; The timed scaling strategy whose historical execution time is closest to the current time in the candidate strategy set is selected as the target timed scaling strategy.

13. The apparatus according to claim 1, characterized in that, The adjustment module is specifically used for: Obtain the function corresponding to the FaaS platform, and obtain at least one deployment version corresponding to the function and the traffic weight corresponding to each deployment version; The target number of instances corresponding to each deployment version is obtained by calculating the number of instances reserved by the target strategy and the traffic weight corresponding to each deployment version. Adjust the actual number of running instances for each of the aforementioned deployment versions to the target number of instances.

14. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; The memory is used to store computer programs; When the processor executes a program stored in the memory, it implements the method as described in any one of claims 1-9.

15. A computer-readable storage medium having instructions stored thereon that, when executed by one or more processors, cause the processors to perform the method as described in any one of claims 1-9.

Images