Service-oriented dynamic resource management method and system

Abstract

The invention discloses a service-oriented dynamic resource management method and system. According to the method, indexes such as a CPU and a memory on a physical node are directly collected, monitoring errors of a virtualization layer are avoided, it is ensured that resource data truly reflects the hardware occupancy condition, physical resource occupancy is attributed to specific services through service labels, abstract conversion from hardware resources to service requirements is achieved, and a foundation is laid for differentiated management; the threshold value of the resource utilization rate of each service is calculated hierarchically according to the type of the service, the core service is guaranteed preferentially, if the resource utilization rate exceeds the corresponding threshold value, manual intervention is not needed, a standardized control interface is automatically called to execute the resource expansion operation, and the accuracy, high efficiency and adaptability of resource allocation are achieved.

Description

Technical Field

[0001] This application relates to the field of resource management technology, specifically to a service-oriented dynamic resource management method and system. Background Technology

[0002] In today's era of deep integration of cloud computing, big data, and distributed systems technologies, service deployment and resource management have become critical technology areas. As business scale continues to expand and user needs become increasingly diversified, a large number of services need to operate efficiently on limited computing resources. These services cover diverse fields such as online transactions, data analysis, and real-time communication, and their resource requirements not only differ but also exhibit dynamic changes. To ensure service performance, availability, and cost-effectiveness, how to scientifically allocate computing resources and optimize service deployment has become a crucial issue that urgently needs to be addressed.

[0003] Traditional service resource allocation models often employ static resource allocation strategies. Under this model, fixed computing resources need to be allocated to each service in advance based on estimated business volume, such as specifying the number of CPU cores, memory capacity, and storage quotas. Taking web services as an example, a predetermined number of server resources are often allocated based on peak load expectations, and this configuration is maintained for a considerable period. At the resource monitoring level, the monitoring frequency is relatively low, making it difficult to track dynamic changes in resource usage in real time; the resource scheduling mechanism is also relatively crude, typically requiring manual intervention to reallocate resources only when there is a severe shortage of resources or equipment failure. Furthermore, traditional methods rely heavily on rules of thumb or simple statistical analysis based on historical data when predicting service resource demand, making it difficult to accurately predict the evolution trend of resource demand in complex business scenarios.

[0004] Therefore, how to accurately adapt service deployment and resource allocation to complex business scenarios is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] In view of the above-mentioned defects or deficiencies in the existing technology, it is desirable to provide a service-oriented dynamic resource management method and system that can realize fine-grained allocation and dynamic scheduling of resources and achieve differentiated management.

[0006] In a first aspect, embodiments of this application provide a service-oriented dynamic resource management method, including:

[0007] Collect the resource status of each physical node, and calculate the resource utilization rate of each service based on the resource status and the corresponding service tag;

[0008] Based on the type of service, the threshold for resource utilization of each service is calculated in a hierarchical manner;

[0009] If there are resources whose utilization rate exceeds the corresponding threshold, the control interface is invoked to perform a resource expansion operation.

[0010] In one embodiment, the step of calculating the threshold for resource utilization of each service in a hierarchical manner according to the type of service includes:

[0011] Identify the priority level of the service;

[0012] If the service is of high priority, calculate the threshold of resource utilization corresponding to the service based on the real-time task queue length;

[0013] If the service is of low priority, a fixed threshold strategy is applied to each resource corresponding to the service.

[0014] In one embodiment, calculating resource utilization based on the resource status includes:

[0015] The resource status is smoothed using an exponentially weighted moving average algorithm with a sliding time window.

[0016] In one embodiment, if there are resources whose resource utilization exceeds the corresponding threshold, the method further includes:

[0017] Obtain service operation data;

[0018] Anomaly analysis is performed based on the service operation data.

[0019] In one embodiment, the service-oriented dynamic resource management method further includes:

[0020] Based on historical resource status and corresponding service and business information, a pre-trained prediction model is invoked to predict the future resource requirements of each service and generate prediction results.

[0021] Based on the difference between the predicted result and the current resource allocation, the control interface is invoked to perform resource expansion or contraction operations.

[0022] In one embodiment, the method for performing the shrinkage operation includes:

[0023] Classify the instances in the service to be adjusted into idle instances and task running instances;

[0024] The idle instances will be released first.

[0025] In one embodiment, the priority release of the idle instance includes:

[0026] Release the idle instances in stages according to a proportional ratio, and monitor the resource utilization rate after release;

[0027] If the resource utilization rate still reaches the scaling-down standard after release, continue to release the idle instances in the next stage.

[0028] In one embodiment, the call control interface performs a resource expansion operation, including:

[0029] Determine whether the service to be adjusted is a stateless service;

[0030] If it is a stateless service, add a new instance to the service to be adjusted;

[0031] If it is a stateful service, the virtualization platform is invoked to hot-migrate traffic to the new resource.

[0032] In one embodiment, after the call control interface performs the resource expansion operation, the method further includes:

[0033] Collect performance metrics and call a multi-objective evaluation model to calculate a comprehensive score of scheduling effectiveness based on the performance metrics;

[0034] If the overall score is lower than the historical average, a reinforcement learning model is invoked to optimize the policy.

[0035] Secondly, embodiments of this application provide a service-oriented dynamic resource management system, including:

[0036] The resource monitoring module is used to collect the resource status of each physical node, calculate the resource utilization rate of each service based on the resource status and the corresponding service tag; calculate the threshold of resource utilization rate of each service in a hierarchical manner according to the service type; if there are resources whose resource utilization rate exceeds the corresponding threshold, submit a scheduling request to the resource scheduling module.

[0037] The resource scheduling module is used to receive the scheduling request and then call the control interface to perform a resource expansion operation.

[0038] The service-oriented dynamic resource management method provided in this application directly collects metrics such as CPU and memory from physical nodes, avoiding monitoring errors at the virtualization layer and ensuring that resource data accurately reflects hardware occupancy. Then, it uses service tags to assign physical resource occupancy to specific services, achieving an abstract transformation from hardware resources to service requirements, laying the foundation for differentiated management. Based on service type, it calculates thresholds for resource utilization at different levels, prioritizing core business operations. If resource utilization exceeds the corresponding threshold, it automatically calls standardized control interfaces to perform resource expansion operations without manual intervention, achieving precision, efficiency, and adaptability in resource allocation. This method is particularly suitable for cloud computing scenarios where core business is prioritized and loads dynamically change.

[0039] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0040] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0041] Figure 1 A flowchart illustrating a service-oriented dynamic resource management method provided in an embodiment of this application is shown.

[0042] Figure 2 An exemplary structural block diagram of a service-oriented dynamic resource management system provided in an embodiment of this application is shown. Detailed Implementation

[0043] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0044] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. The present application will now be described in detail with reference to the accompanying drawings and embodiments. Although the embodiments of this application provide method operation instruction steps as shown in the following embodiments or drawings, more or fewer operation instruction steps may be included in the method based on conventional or non-inventive effort. In steps where there is no logically necessary causal relationship, the execution order of these steps is not limited to the execution order provided in the embodiments of this application. In actual processing or when the device executes, the method may be executed sequentially or in parallel according to the method shown in the embodiments or drawings.

[0045] Example 1:

[0046] This embodiment proposes a service-oriented dynamic resource management method. Please refer to [link / reference]. Figure 1 , Figure 1 A flowchart illustrating the service-oriented dynamic resource management method provided in this embodiment is shown. Figure 1 As shown, the method includes:

[0047] S101. Collect the resource status of each physical node, and calculate the resource utilization rate of each service based on the resource status and the corresponding service tag.

[0048] Physical nodes (such as servers and hosts) provide underlying computing resources such as CPU, memory, and storage. Services (such as web services and database services) are deployed on physical nodes through virtualization technologies (such as containers and virtual machines), consuming their resources. A single service can be deployed on multiple physical nodes, and a single physical node can also support multiple services.

[0049] Collect key resource metrics such as CPU utilization, memory usage, storage I / O throughput, and network bandwidth utilization for each physical node. Collecting the resource status of physical nodes avoids monitoring errors from virtualization layers (such as Docker), ensures data accuracy, and facilitates global resource scheduling. Specifically, an agent program can be deployed on the physical nodes to collect resource status data at a rate of one second.

[0050] After collecting underlying resource metrics such as CPU utilization and memory usage on physical nodes, these metrics are aggregated by service dimension based on service tags (metadata identifying service attributes, such as service=payment). Resource usage is then attributed to specific services based on these service tags. For example, if a physical node runs a payment service (tag service=payment) and a logging service (tag service=logging), the monitoring module calculates the CPU usage for each service separately based on their tags. Ultimately, the actual resource utilization of each service is obtained.

[0051] This embodiment does not limit the specific algorithm for calculating resource utilization. One calculation method is as follows: Service CPU utilization = Physical CPU core time occupied by all instances of the service / Total CPU core time of physical nodes × 100%. By aggregating the resource usage of service instances distributed across different physical nodes through service tags, the global service-level utilization can be obtained. This step transforms the underlying physical resource data into service-level monitoring metrics, providing a basis for setting thresholds by service type in the future.

[0052] In one embodiment, resource utilization is calculated based on resource status by smoothing the resource status using an exponentially weighted moving average (EWMA) algorithm with a sliding time window (default 30 seconds). By implementing the EWMA algorithm (α = 0.2) with a sliding time window (default 30 seconds) in the physical node agent program, the CPU / memory and other resource indicators collected at the second-level are smoothed, avoiding frequent scheduling due to short-term fluctuations and generating stable utilization data for threshold comparison. This calculation method ensures the stability of resource utilization trends, making scheduling decisions more reliable. It should be noted that this embodiment only uses the above calculation method; other calculation methods can be referred to the description in this embodiment and will not be elaborated further here.

[0053] S102. Calculate the threshold for resource utilization of each service according to its type and level.

[0054] Different services have different resource requirements. For example, core transaction services need to prioritize CPU resources, while log services can tolerate insufficient memory. In response, this embodiment proposes to set different resource utilization thresholds for services of different importance or types, thereby achieving differentiated resource management and protection, avoiding one-size-fits-all monitoring, ensuring the stability of critical business and improving overall resource utilization efficiency.

[0055] The service type can be set according to the service priority, service status (stateful / stateless service), and service business type (financial service, log storage service, etc.) based on the actual application scenario and different resource management needs. This embodiment does not impose any limitations on this. For example, the service type can be set according to priority, divided into high-priority services and low-priority services. A lower service threshold can be set for high-priority services, making it easier to trigger expansion, obtaining more flexible expansion strategies, avoiding service lag due to insufficient resources, and ensuring the rapid response capability of computing resources. Low-priority services have a higher threshold and will not occupy resources when resources are slightly strained, avoiding frequent scheduling, thereby achieving balanced management of overall resources.

[0056] S103. If there are resources whose resource utilization exceeds the corresponding threshold, call the control interface to perform resource expansion operation.

[0057] Different thresholds are configured for different service types. If the resource utilization (such as CPU and memory) of a certain service exceeds the preset threshold, the control interface of the virtualization platform (such as Kubernetes API) is called to mark the current node as a resource-scarce state, triggering a resource scheduling request. The virtualization control interface, such as Kubernetes API or OpenStackNova, is then called to adjust the resources of the target service to quickly meet the service's resource requirements.

[0058] After detecting that the resource utilization rate of a certain resource exceeds the corresponding threshold, in order to further ensure the stability of system operation and upgrade from passively responding to resource overruns to proactively preventing resource shortages, when a resource shortage event occurs, service operation data can be obtained, such as the event trigger time, resource usage details and trend data, etc. Short-term historical data can be retained for anomaly analysis. For example, it can be used to determine whether the abnormal pattern of resource utilization is related to business events. This can not only trace the root cause of the current problem, but also provide experience support for future scheduling, ultimately improving the stability, resource utilization and automation level of the system, and improving the accuracy of scheduling strategies. Of course, anomaly analysis can also be omitted, and this embodiment does not limit this.

[0059] Based on the above introduction, the service-oriented dynamic resource management method provided in this embodiment directly collects indicators such as CPU and memory on physical nodes (e.g., Prometheus collects data at the second level), avoiding monitoring errors at the virtualization layer and ensuring that resource data accurately reflects hardware occupancy. Then, service tags are used to assign physical resource occupancy to specific services, achieving an abstract transformation from hardware resources to service requirements, laying the foundation for differentiated management. According to the service type, thresholds for resource utilization are calculated hierarchically for each service, prioritizing core business operations. If resource utilization exceeds the corresponding threshold, resource expansion is automatically executed by calling a standardized control interface without manual intervention. This method, through the process of data collection → intelligent threshold calculation → automated resource scheduling, achieves accuracy, efficiency, and adaptability in resource allocation, making it particularly suitable for cloud computing scenarios where core business is prioritized and loads dynamically change. Compared to traditional static allocation models, it has significant advantages in resource utilization, service stability, and cost control.

[0060] Example 2:

[0061] The above embodiments do not limit the classification of service types and the corresponding threshold calculation methods. In order to ensure that important services obtain resources first, this embodiment proposes a hierarchical threshold calculation method. Specifically, step S102, which calculates the threshold of resource utilization for each service according to its type, can be implemented according to the following steps:

[0062] Step S21: Identify the priority level of the service;

[0063] Step S22: If the service is of high priority, calculate the threshold of resource utilization corresponding to the service based on the real-time task queue length;

[0064] Step S23: If the service is of low priority, a fixed threshold strategy is adopted for each resource corresponding to the service.

[0065] When setting thresholds, a hierarchical strategy is adopted, using different triggering mechanisms for services with different priorities to ensure the reasonable allocation of computing resources.

[0066] In high-priority service scenarios, the CPU utilization threshold needs to be dynamically adjusted based on the task queue backlog to trigger capacity expansion in advance when the task volume increases, preventing service performance degradation. Dynamic threshold calculation can employ a linear adjustment strategy; one calculation formula is as follows:

[0067]

[0068] in, This represents the currently calculated CPU utilization threshold for high-priority services. Let Q be the number of waiting tasks in the current queue, and β be the coefficient representing the influence of the task queue on the threshold. The purpose of this formula is to determine how much the threshold increases as Q increases. The threshold is lowered accordingly, allowing the system to scale up earlier under high load, avoiding increased response time due to task backlog. When Q drops to a lower level, the threshold returns to a higher level, reducing unnecessary resource expansion and improving the utilization of computing resources. For high-concurrency task scenarios, the trigger threshold is dynamically lowered as the task queue grows, making scaling decisions more agile, while the threshold is appropriately raised under low load to avoid resource waste.

[0069] For low-priority services, a fixed threshold strategy is adopted, meaning resource scheduling is only triggered when CPU utilization exceeds a set upper limit. This fixed threshold strategy is suitable for tasks with low latency requirements, such as log storage and batch data analysis. Even if these tasks experience resource constraints for a short period, they will not affect core business processes, therefore dynamic adjustment is unnecessary. One example of a fixed threshold setting is as follows:

[0070]

[0071] in, The CPU utilization trigger threshold represents a low-priority service. This is a fixed value. Scaling up of low-priority tasks will only be performed if resource utilization consistently exceeds this threshold, ensuring that computing resources primarily serve high-priority tasks, and low-priority tasks are only scheduled when resources are abundant.

[0072] In the hierarchical threshold setting method provided in this embodiment, high-priority tasks can obtain more flexible expansion strategies to ensure the rapid response capability of computing resources, while low-priority tasks avoid frequent scheduling through a fixed threshold mechanism, thereby achieving balanced management of overall resources. In the specific implementation process, the system maintains historical utilization data of services with different priorities in the global resource status database to assist in optimizing threshold settings, so that the resource scheduling strategy can adapt to the changing trend of business load.

[0073] Example 3:

[0074] To improve the foresight and accuracy of resource management, this embodiment proposes a proactive resource planning and management method. Specifically, in addition to the steps mentioned above, the following steps can be further performed:

[0075] Step S104: Based on the historical resource status and the corresponding service and business information, call the pre-trained prediction model to predict the future resource demand of each service and generate prediction results;

[0076] Historical load data is used to invoke a predictive model to estimate the resource requirements of various services in the near future. The predictive input data includes historical resource status and corresponding service and business information, such as time-series features (historical CPU, memory, and network traffic usage), business event tags (promotional activities, version updates, etc.), and service priority tags (high, medium, low). The predictive model can predict the resource requirements of each service and their confidence intervals within a short period (e.g., within five minutes).

[0077] Step S105: Based on the difference between the prediction result and the current resource allocation, call the control interface to perform resource expansion or contraction operations.

[0078] The predicted resource demand is compared with the current allocation, the resource difference is calculated, and the resource allocation is dynamically adjusted based on the difference to ensure efficient use of computing resources.

[0079] This embodiment does not limit the range within which resource discrepancies trigger scaling up or down. The goal is to ensure effective resource allocation while avoiding redundant operations. One implementation method is as follows: If the predicted demand exceeds 120% of the current allocation, the system will trigger scaling up to ensure service quality does not degrade due to resource shortages. Conversely, if the predicted demand is less than 60% of the current allocation for 10 minutes, a scaling down command will be triggered to release redundant resources.

[0080] For example, if the current CPU allocation for a web service instance is 100 cores, and the intelligent prediction module outputs a demand forecast of 130 cores for the next 5 minutes, exceeding 120% of the current allocation (100 × 1.2 = 120), the system will trigger a scaling-up command to add additional computing resources to the service. If the predicted demand is 55 cores and remains below 60 cores (100 × 0.6 = 60) for 10 minutes, the system will trigger a scaling-down command to reduce computing resource allocation and lower operating costs. Through this prediction and elastic planning mechanism, the system can optimize computing resource utilization to the maximum extent while ensuring service performance.

[0081] It should be noted that this embodiment does not limit the specific model structure of the prediction model. To achieve accurate prediction, a hybrid prediction model combining ARIMA and LSTM neural networks can be used. The Autoregressive Integral Moving Average (ARIMA) model is used to capture long-term trends and seasonal variations, and a Long Short-Term Memory (LSTM) neural network is combined to handle complex nonlinear time-series features, thereby improving prediction accuracy.

[0082] Of course, besides the hybrid prediction model combining ARIMA and LSTM neural networks, other types of models can also be used, such as the Support Vector Machine Regression (SVR) model. SVR has advantages in handling small sample sizes and nonlinear problems, and can predict future resource demands by learning from historical load data. This embodiment only uses the above model structure as an example; other model structures can be described with reference to this embodiment and will not be elaborated further.

[0083] The resource demand forecasting method provided in this embodiment achieves forward-looking and accurate resource management through an intelligent closed loop of forecasting-decision-execution. It can not only cope with traffic peaks in advance, but also avoid resource idleness. Compared with the traditional threshold-triggered passive scheduling, it has significant advantages in service stability, resource utilization and operation and maintenance efficiency, and is especially suitable for cloud computing scenarios with dynamically changing business loads.

[0084] Example 4:

[0085] This embodiment provides a detailed description of the expansion operation mentioned in the above embodiments. One implementation method for the expansion operation is as follows:

[0086] 1. Determine whether the service to be adjusted is a stateless service;

[0087] 2. If it is a stateless service, add a new instance to the service to be adjusted;

[0088] For stateless services (such as web servers), a horizontal scaling strategy is adopted, which means increasing service processing capacity by adding new instances. Specifically, one implementation process is as follows:

[0089] The system first selects suitable compute nodes from the resource pool and pulls pre-configured container images to ensure that the environment of the new instance is consistent with that of existing instances. Then, based on the current load and compute resource distribution, it determines the deployment strategy for the new instance. The system uses a dynamic instance scheduling algorithm to calculate the optimal node allocation scheme, aiming to balance the resource utilization of each node while reducing cross-host communication overhead.

[0090] After a new instance starts up, it needs to be integrated into the existing service network to ensure proper traffic distribution. Kubernetes assigns an IP address to the new instance via CNI (Container Network Interface) and updates DNS records, enabling the new instance to immediately provide services. The system updates the load balancer's traffic distribution policy, redirecting some traffic to the new instance to alleviate pressure on existing instances.

[0091] 3. If it is a stateful service, call the virtualization platform to hot-migrate traffic to the new resource.

[0092] For stateful services (such as databases and caching systems), the core objective is to dynamically adjust computing resources (vCPUs or memory quotas) to meet sudden increases in workload without interrupting existing business operations. Since stateful services typically involve persistent data and long-running session connections, they cannot be directly replicated through simple horizontal scaling. Instead, computing resources need to be enhanced on top of the original instance. Vertical scaling involves adjusting virtual machine resources, requiring the use of a virtualization platform (such as OpenStackNova) to hot-migrate traffic to the new resources, achieving uninterrupted resource changes.

[0093] Furthermore, to further improve the response speed of capacity expansion, adding new instances to services requiring adjustments can prioritize retrieving pre-started virtual machine instances from the hot resource pool and adding them to the services. A tiered scheduling mechanism using hot and cold resource pools is employed. The hot resource pool contains pre-started virtual machine instances in a low-power standby state, already configured with network, storage mounts, and basic environment. Upon receiving an expansion command, these instances can be activated and take over traffic within 5 seconds. The cold resource pool stores complete container images and virtual machine templates. When resources are scarce, new instances are started from the cold resource pool and deployment and environment initialization are completed within 60 seconds.

[0094] In addition, for horizontal scaling up and down of stateless services, besides launching pre-configured container image instances from the resource pool, a Function as a Service (FaaS) architecture can also be used to automatically and elastically expand and shrink function instances based on requests, achieving finer-grained resource scheduling. This embodiment uses the above-described scaling steps as an example for description; other implementation methods and steps can refer to the description in this embodiment, and will not be repeated here.

[0095] Based on the above introduction, the resource expansion method provided in this embodiment adopts differentiated expansion strategies for stateless and stateful services, ensuring both efficiency and service stability. Specifically, for stateless services, suitable computing nodes are selected from the resource pool, pre-configured container images are pulled, and a dynamic instance scheduling algorithm is used to balance resource allocation. Simultaneously, Kubernetes is used to update network configurations and load balancing strategies to quickly improve service processing capacity. For stateful services, a virtualization platform is invoked for hot traffic migration, dynamically adjusting computing resources to meet load demands without interrupting business operations. Furthermore, the tiered scheduling mechanism of hot and cold resource pools further improves expansion response speed. Virtual machine instances pre-started in the hot resource pool can be activated and take over traffic within 5 seconds, while container images and virtual machine templates in the cold resource pool can complete the deployment and initialization of new instances within 60 seconds. This ensures both the timeliness of emergency expansion and continuous expansion support during resource shortages, optimizing resource utilization efficiency.

[0096] Example 5:

[0097] Resource release is a crucial step in elastic resource allocation. Its goal is to reclaim redundant resources while meeting current service demands, thereby improving overall resource utilization and reducing computing costs. This embodiment describes a specific implementation of a scaling-down operation. It should be noted that the scaling-down method described in this embodiment is particularly applicable to the scenario in Embodiment 3 where scaling down is performed based on prediction results. Of course, it can also be applied to other scenarios, and is not limited here.

[0098] Specifically, one way to implement the shrinking operation is as follows:

[0099] 1. Classify the instances in the service to be adjusted into task execution categories to obtain idle instances and task running instances;

[0100] 2. Prioritize releasing idle instances.

[0101] First, the current instances are categorized into idle instances and instances still running long-running tasks. Idle instances are those where the utilization rate of critical resources such as CPU and memory is below a set threshold and no important computing tasks have been assigned to them. These instances are prioritized for release. For instances still executing long-running tasks, release can be delayed, ensuring that they are reclaimed only after the task is completed. This scaling-down method prioritizes releasing idle instances, protecting the stability of long-running task execution.

[0102] In addition to the above strategy of prioritizing the release of idle instances, a gradual scaling-down strategy can be further configured, or a separate gradual scaling-down strategy can be configured, to ensure that resource release does not affect the stability and quality of service of the system.

[0103] Specifically, taking the configuration of a progressive scaling-down strategy in the priority release of idle instances as an example, the process of priority release of idle instances can be executed according to the following steps: release idle instances in stages according to proportion and monitor the resource utilization rate after release; if the resource utilization rate after release still reaches the scaling-down standard, continue to release the next stage of idle instances.

[0104] The core objective of a gradual scaling-down protection mechanism is to avoid releasing too many resources at once, which could lead to system load fluctuations or sudden resource shortages. Therefore, during the initial scaling-down, only a certain percentage (e.g., 50%) of redundant resources can be released. Resource utilization is then continuously monitored over the following period (e.g., 30 minutes). If CPU utilization remains below a safe level (e.g., 50%) after the release, a second phase of scaling-down is triggered, releasing the remaining redundant resources. Of course, three-stage and four-stage scaling-down strategies can also be configured, as described above, and will not be elaborated upon further here.

[0105] To improve resource reuse, instances to be scaled down can be further tagged with "delayed destruction," retaining their data volumes for 10 minutes. If a new resource shortage event occurs within this time window, the system will prioritize reusing these instances instead of creating new ones, thus reducing instance startup time and cold start costs. For example, if the system is currently running 20 instances under high load, and 6 of these instances have an average CPU utilization of less than 30% in the past 10 minutes, they are marked as redundant resources. According to the progressive scaling-down protection mechanism, the system initially releases only 3 instances, and the remaining 3 instances will be released after 30 minutes based on CPU utilization. Meanwhile, the disk storage of the released instances is retained for 10 minutes. If the system load suddenly increases during this period, the system can directly restore the scaled-down instances without needing to fetch the image and redeploy the environment, ensuring rapid service response and efficient resource utilization.

[0106] The resource scaling-down method provided in this embodiment classifies service instances by task execution, prioritizing the release of idle instances whose CPU and memory utilization are below a set threshold and which are not assigned important tasks. This avoids releasing instances executing long tasks to ensure task stability and allows for timely reclamation of redundant resources. Simultaneously, a gradual scaling-down strategy is configured, releasing idle instances in stages according to a proportional ratio and monitoring resource utilization in real time. This avoids releasing too many resources at once, which could lead to system load fluctuations or resource shortages, thus improving the security of the scaling-down process. Furthermore, adding a delayed destruction tag to instances to be scaled down and retaining data volumes for 10 minutes allows for priority reuse of these instances in the event of new resource shortages, reducing instance startup time and cold start costs, improving resource reuse rates, and ensuring rapid service response.

[0107] Example 6:

[0108] To improve overall system performance, reduce resource consumption, and ensure high service availability, after calling the control interface to perform resource expansion operations, further optimization of the strategy can be performed based on the scheduling effect. Specifically, after calling the control interface to perform resource expansion operations in step S103, the following steps can be further executed:

[0109] Step S106: Collect performance indicators and call the multi-objective evaluation model to calculate the comprehensive score of scheduling effect based on the performance indicators;

[0110] After each resource scheduling execution, performance metrics such as resource utilization, service response time, and cost are collected, and a comprehensive score for scheduling effectiveness is calculated based on a multi-objective evaluation model. This comprehensive score can be used to measure the effectiveness of the current strategy and guide subsequent optimization decisions.

[0111] This embodiment does not limit the specific model structure of the multi-objective evaluation model. In one embodiment, the multi-objective evaluation model can be constructed using the Analytic Hierarchy Process (AHP). By constructing a judgment matrix, weights are assigned to different evaluation indicators, and the final scheduling score is calculated. Of course, other model structures can also be used, all of which can be referred to the description in this embodiment, and will not be elaborated further here.

[0112] Step S107: If the overall score is lower than the historical average, call the reinforcement learning model to optimize the policy.

[0113] When the calculated overall score is lower than the historical average, the system will trigger a strategy optimization process. Strategy optimization methods include, but are not limited to: adjusting the weights of the prediction model, modifying the elastic scaling threshold, and optimizing resource scheduling rules. Specifically, the elastic scaling threshold adjustment is dynamically optimized based on historical data. When the current scheduling score is lower than the historical average, the system can appropriately lower the scaling threshold to trigger scaling faster, thereby improving performance; conversely, the scaling threshold will be raised to reduce unnecessary resource allocation and improve resource utilization.

[0114] Furthermore, to achieve even greater adaptive optimization, reinforcement learning models can be introduced. These models train scheduling strategies using deep Q-networks (DQNs). In reinforcement learning models, agents can select different scaling-up and scaling-down strategies based on the current system state (including historical load, resource utilization, response time, etc.) and update the strategy library using Q-values, enabling resource allocation strategies to continuously optimize in response to changing business needs.

[0115] Based on the above introduction, the strategy feedback optimization method provided in this embodiment collects performance indicators and uses a multi-objective evaluation model to calculate a comprehensive score of scheduling effectiveness. This allows for the quantitative measurement of the effectiveness of resource scheduling strategies, providing data support for subsequent optimization. When the comprehensive score is lower than the historical average, a reinforcement learning model is triggered to optimize the strategy. This dynamically adjusts the prediction model weights, elastic scaling thresholds, and resource scheduling rules, enabling the resource allocation strategy to continuously optimize in response to changing business needs. Furthermore, the method proposes introducing an agent in the reinforcement learning model to select a strategy based on the system state and update the strategy library, achieving adaptive optimization. This further improves the accuracy and efficiency of resource scheduling, thereby increasing resource utilization and reducing cost while ensuring service performance.

[0116] Example 7:

[0117] Further reference Figure 2The diagram illustrates an exemplary structural block diagram of a service-oriented dynamic resource management system according to an embodiment of the present application, which mainly includes a resource monitoring module and a resource scheduling module. The service-oriented dynamic resource management system adopts a modular design and realizes fine-grained allocation and dynamic scheduling of resources through two core units, thereby achieving differentiated management.

[0118] The resource monitoring module is used to collect the resource status of each physical node, calculate the resource utilization rate of each service based on the resource status and the corresponding service tag, calculate the threshold of resource utilization rate of each service according to the service type, and submit a scheduling request to the resource scheduling module if there are resources whose resource utilization rate exceeds the corresponding threshold.

[0119] Specifically, the resource monitoring module can collect CPU utilization, memory usage, storage I / O throughput and network bandwidth utilization at a frequency of seconds through an agent program deployed on physical nodes, and upload the data to the global resource status database. When any resource indicator exceeds a preset threshold (e.g., CPU utilization ≥ 80% for 30 seconds), a resource scheduling request is triggered and marked as a resource shortage event.

[0120] The resource monitoring module uses a hierarchical threshold setting: for high-priority services (such as payment gateways), dynamic thresholds are set (e.g., CPU utilization threshold = 75% - number of tasks waiting in the current queue × 2%); for low-priority services (such as log processing), fixed thresholds are set (e.g., CPU utilization ≥ 90%).

[0121] The resource scheduling module is used to receive scheduling requests and then call the control interface to perform resource expansion operations.

[0122] Specifically, after receiving the scaling up / scaling down command, the resource scheduling module calls the virtualization control interface (such as the Kubernetes API) to perform the following operations:

[0123] Horizontal scaling: For stateless services (such as web servers), start pre-configured container image instances from the resource pool and distribute traffic to new instances through a load balancer;

[0124] Vertical scaling: For stateful services (such as databases), dynamically adjust the number of virtual machine vCPUs or memory quotas, and use hot migration technology to avoid service interruptions; Horizontal scaling operations further include hierarchical scheduling of hot and cold resource pools. Hot resource pool: pre-starts instances and maintains a low-power standby state, taking over traffic within 5 seconds when responding to scaling commands; Cold resource pool: stores container images and virtual machine templates, and completes instance startup and configuration injection within 60 seconds when responding to scaling commands.

[0125] Resource Release: For scaling down commands, idle instances are released first. If there are instances running long tasks, release is delayed until the tasks are completed. The resource release operation includes a progressive scaling down protection mechanism: the first scaling down releases only 50% of redundant resources. If the resource utilization does not recover to a safe level (e.g., CPU < 50%) within 30 minutes after release, the remaining redundant resources are released. A "delayed destruction" tag is added to the scaling down instance, and its data volume is retained for 10 minutes. If a resource shortage event occurs during this period, the instance is reused first.

[0126] In addition to the two core modules mentioned above, an intelligent prediction module can be further configured. Based on historical load data (including time series features and business event labels) and service priority labels, the intelligent prediction module trains a hybrid prediction model (ARIMA+LSTM neural network) and outputs the predicted resource demand values ​​and confidence intervals for each service within the next 5 minutes.

[0127] The intelligent forecasting module can be further configured with an elastic planning unit. The elastic planning unit is used to calculate the resource gap based on the forecast value. If the forecast demand exceeds 120% of the current allocation, an expansion instruction is generated; if the forecast demand is lower than 60% of the current allocation for 10 minutes, a reduction instruction is generated.

[0128] In addition, the service-oriented dynamic resource management system can also be configured with a strategy optimization module to collect indicators such as resource utilization, service response time (e.g., average API latency), and cost consumption (e.g., cloud resource billing per second) after scheduling. These indicators are then input into a multi-objective evaluation model (built based on the Analytic Hierarchy Process, AHP) to calculate the comprehensive score of this scheduling. If the comprehensive score is lower than the historical average, the strategy parameters are adjusted (e.g., the prediction model weights and elastic expansion thresholds are modified), and the scheduling rule base is updated through a reinforcement learning model.

[0129] It should be noted that the service-oriented dynamic resource management system provided in this embodiment and the aforementioned service-oriented dynamic resource management method can be referred to each other, and will not be repeated here.

[0130] The service-oriented dynamic resource management system provided in this embodiment forms a service-centric dynamic resource management closed loop through precise data collection and intelligent threshold decision-making by the resource monitoring module, combined with efficient execution and multi-dimensional adaptation by the resource scheduling module. The resource monitoring module provides precise perception and improves monitoring granularity; its hierarchical threshold strategy ensures differentiated service protection; and its automatic threshold triggering mechanism reduces manual intervention costs. The resource scheduling module performs efficient resource scheduling execution, and its standardized interface calls ensure cross-platform compatibility. This system achieves automation, accuracy, and scalability in resource management through inter-module collaboration, providing a systematic solution for balancing business stability and resource utilization efficiency.

[0131] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operational instructions of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two connected blocks may actually be executed substantially in parallel, or they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified functions or operational instructions, or using a combination of dedicated hardware and computer instructions.

[0132] The units or modules described in the embodiments of this application can be implemented in software or hardware. The described units or modules can also be located in a processor. The names of these units or modules do not, in certain circumstances, constitute a limitation on the unit or module itself.

[0133] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the foregoing disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. A service-oriented dynamic resource management method, characterized in that, include: Collect the resource status of each physical node, and calculate the resource utilization rate of each service based on the resource status and the corresponding service tag; Based on the type of service, the threshold for resource utilization of each service is calculated in a hierarchical manner; If there are resources whose utilization rate exceeds the corresponding threshold, the control interface is invoked to perform a resource expansion operation.

2. The method as described in claim 1, characterized in that, The step of calculating the threshold for resource utilization of each service at different levels based on service type includes: Identify the priority level of the service; If the service is of high priority, calculate the threshold of resource utilization corresponding to the service based on the real-time task queue length; If the service is of low priority, a fixed threshold strategy is applied to each resource corresponding to the service.

3. The method as described in claim 1, characterized in that, Calculating resource utilization rate based on the resource status includes: The resource status is smoothed using an exponentially weighted moving average algorithm with a sliding time window.

4. The method as described in claim 1, characterized in that, If there are resources whose utilization rate exceeds the corresponding threshold, the following is also included: Obtain service operation data; Anomaly analysis is performed based on the service operation data.

5. The method as described in claim 1, characterized in that, Also includes: Based on historical resource status and corresponding service and business information, a pre-trained prediction model is invoked to predict the future resource requirements of each service and generate prediction results. Based on the difference between the predicted result and the current resource allocation, the control interface is invoked to perform resource expansion or contraction operations.

6. The method as described in claim 5, characterized in that, The method for performing the shrinkage operation includes: Classify the instances in the service to be adjusted into idle instances and task running instances; The idle instances will be released first.

7. The method as described in claim 6, characterized in that, The priority release of the idle instance includes: Release the idle instances in stages according to a proportional ratio, and monitor the resource utilization rate after release; If the resource utilization rate still reaches the scaling-down standard after release, continue to release the idle instances in the next stage.

8. The method as described in claim 1, characterized in that, The process of calling the control interface to perform resource expansion operations includes: Determine whether the service to be adjusted is a stateless service; If it is a stateless service, add a new instance to the service to be adjusted; If it is a stateful service, the virtualization platform is invoked to hot-migrate traffic to the new resource.

9. The method as described in claim 1, characterized in that, After the resource expansion operation is performed via the call control interface, the following is also included: Collect performance metrics and call a multi-objective evaluation model to calculate a comprehensive score of scheduling effectiveness based on the performance metrics; If the overall score is lower than the historical average, a reinforcement learning model is invoked to optimize the policy.

10. A service-oriented dynamic resource management system, characterized in that, include: The resource monitoring module is used to collect the resource status of each physical node and calculate the resource utilization rate of each service based on the resource status and the corresponding service tag. Based on the type of service, the threshold for resource utilization of each service is calculated hierarchically; if there are resources whose resource utilization exceeds the corresponding threshold, a scheduling request is submitted to the resource scheduling module. The resource scheduling module is used to receive the scheduling request and then call the control interface to perform a resource expansion operation.

Images