Resource configuration method and device, storage medium and electronic equipment

Abstract

The invention discloses a resource configuration method and device, a storage medium and electronic equipment, and relates to the technical field of cloud computing, and the method comprises the steps: firstly obtaining a micro-service topology of a business system deployed on a cloud platform; matching the micro-service topology with the resource demand of each micro-service component in the service system, and determining the static reservation amount of cloud platform resources corresponding to the service system in each reservation time period; based on the resource dynamic feature model corresponding to the service system, predicting the cloud platform resource demand of the service system in a future preset time period; and if the demand quantity of the cloud platform resources exceeds the static reservation quantity in the corresponding reservation time period, redistributing the cloud platform resources corresponding to the service system according to the service priority. Compared with the prior art, the resource demand prediction is carried out by adopting the resource monitoring and analysis of the micro-service component granularity and combining the dynamic feature model, so that the resource utilization rate and the service continuity guarantee capability of the cloud platform in a complex environment are effectively improved.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, specifically to a resource allocation method, apparatus, storage medium, and electronic device. Background Technology

[0002] With the widespread application of microservice architecture on cloud platforms, business traffic load and access patterns in cloud environments exhibit significant dynamism and unpredictability, often resulting in "hot spots" of dense access to local services and drastic short-term traffic fluctuations.

[0003] Currently, most related technologies adopt a static reservation model for fixed resources, allocating a fixed amount of computing, storage, or network resources to specific businesses or services over a long period to ensure their performance requirements during peak periods. However, this approach is difficult to adapt to the dynamic changes in business load in cloud environments, often resulting in low resource utilization. Summary of the Invention

[0004] In view of this, this application provides a resource allocation method, apparatus, storage medium and electronic device, the main purpose of which is to improve the technical problem that the current model is difficult to adapt to the dynamic changes in business load in the cloud environment, which often leads to low resource utilization.

[0005] Firstly, this application provides a resource allocation method, including:

[0006] Obtain the microservice topology of the business system deployed on the cloud platform;

[0007] The microservice topology is matched with the resource requirements of each microservice component in the business system to determine the static reserved amount of cloud platform resources corresponding to the business system in each reserved time period.

[0008] Based on the resource dynamic characteristic model corresponding to the business system, predict the cloud platform resource demand of the business system in a future preset time period.

[0009] If the cloud platform resource demand exceeds the static reserved amount within the corresponding reserved time period, the cloud platform resources corresponding to the business system will be reallocated according to the business priority.

[0010] Secondly, this application provides a resource allocation device, comprising:

[0011] The acquisition module is configured to acquire the microservice topology of business systems deployed on the cloud platform;

[0012] The matching module is configured to match the microservice topology with the resource requirements of each microservice component in the business system, and determine the static reserved amount of cloud platform resources corresponding to the business system in each reserved time period.

[0013] The prediction module is configured to predict the cloud platform resource demand of the business system within a preset time period in the future, based on the resource dynamic feature model corresponding to the business system.

[0014] The configuration module is configured to reallocate the cloud platform resources corresponding to the business system according to the business priority if the cloud platform resource demand exceeds the static reservation amount within the corresponding reserved time period.

[0015] Thirdly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in the first aspect.

[0016] Fourthly, this application provides an electronic device including a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein the processor executes the computer program to implement the method described in the first aspect.

[0017] Fifthly, this application provides a computer program product having a computer program stored thereon, which, when executed by a processor, implements the method described in the first aspect.

[0018] Using the above technical solution, this application provides a resource allocation method, apparatus, storage medium, and electronic device. First, it obtains the microservice topology of a business system deployed on a cloud platform. Then, it matches the microservice topology with the resource requirements of each microservice component in the business system to determine the static reserved amount of cloud platform resources corresponding to the business system within each reserved time period. Next, based on the dynamic characteristic model of the resources corresponding to the business system, it predicts the cloud platform resource demand of the business system within a future preset time period. If the cloud platform resource demand exceeds the static reserved amount within the corresponding reserved time period, the cloud platform resources corresponding to the business system are reallocated according to business priority. Compared with existing technologies, this application achieves precise initial resource reservation based on business architecture characteristics by constructing a fine-grained mapping relationship between microservice topology and resource requirements. This effectively avoids resource waste or insufficiency caused by traditional coarse-grained allocation. Furthermore, by combining a dynamic resource feature model based on historical data and machine learning algorithms, it predicts future resource requirements, significantly improving the accuracy and timeliness of prediction. Moreover, when the prediction result exceeds the static reservation amount, a dynamic reallocation mechanism based on business priority is introduced, balancing service quality and resource utilization efficiency. This forms a complete technical closed loop from topology awareness, static reservation, dynamic prediction to intelligent reallocation, which is suitable for complex and ever-changing cloud environments. It can effectively cope with business load fluctuations and improve the overall resource utilization and business continuity assurance capabilities of the cloud platform.

[0019] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, specific embodiments of this application are given below. Attached Figure Description

[0020] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0021] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 A flowchart illustrating a resource allocation method provided in an embodiment of this application is shown;

[0023] Figure 2 A flowchart illustrating another resource configuration method provided in an embodiment of this application is shown;

[0024] Figure 3 A flowchart illustrating an example provided in an embodiment of this application is shown;

[0025] Figure 4 A flowchart illustrating an example provided in an embodiment of this application is shown;

[0026] Figure 5 A flowchart illustrating an example provided in an embodiment of this application is shown;

[0027] Figure 6 A flowchart illustrating an example provided in an embodiment of this application is shown;

[0028] Figure 7 A schematic diagram of the structure of a resource allocation device provided in an embodiment of this application is shown. Detailed Implementation

[0029] The embodiments of this application will now be described in more detail with reference to the accompanying drawings. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0030] In cloud platform environments, there is an inherent contradiction between the resource demands of mission-critical applications and the platform's resource management. On the one hand, mission-critical applications require stable and reliable resource guarantees, necessitating middleware support for static resource reservation; on the other hand, cloud platforms pursue maximum resource utilization, requiring middleware to dynamically adjust resource allocation. This necessitates middleware finding a balance between static reservation and dynamic adjustment. Further complicating matters, mission-critical applications on different cloud platforms have varying resource performance and requirements. This requires middleware to identify cloud platform types and reserve corresponding dedicated resources accordingly. Simultaneously, business loads and access patterns frequently experience hotspots and fluctuations, requiring middleware to dynamically adjust resource configuration and allocation based on cloud platform characteristics to cope with sudden demand. This multi-dimensional resource management requirement presents a significant challenge to middleware. Therefore, designing a resource management mechanism that meets both the stability requirements of mission-critical applications and the flexibility of cloud environments has become a pressing technical challenge.

[0031] To address the technical problem of low resource utilization caused by the current model's inability to adapt to the dynamic changes in business load in cloud environments, this embodiment provides a resource configuration method applicable to the server side of a cloud computing environment, such as... Figure 1 As shown, the method includes:

[0032] Step 101: Obtain the microservice topology of the business system deployed on the cloud platform.

[0033] For example, the server-side application in a cloud computing environment may include the control node or resource management center of the cloud platform, which is used to perform fine-grained resource allocation and dynamic optimization of business systems deployed on the cloud platform. It is suitable for resource collaborative management in large-scale distributed systems, microservice architecture applications and hybrid cloud scenarios that need to ensure service quality and improve resource utilization.

[0034] In some examples, configuration information and network topology of each microservice instance deployed on the cloud platform can be obtained by calling the application programming interface (API) provided by the cloud platform. Combined with the service list and call chain data maintained in the service registration and discovery components (such as Eureka, Consul or Nacos), the call paths and dependencies between services can be collected using a distributed tracing system (such as Jaeger or SkyWalking). Finally, the topology analysis engine is used to model the association between instances, services, gateways and call chains to generate a microservice topology map that reflects the communication structure and dependencies between microservices.

[0035] Step 102: Match the microservice topology with the resource requirements of each microservice component in the business system to determine the static reserved amount of cloud platform resources corresponding to the business system in each reserved time period.

[0036] In some examples, based on the deployment topology of the microservice components of the business system, the corresponding virtual machine performance specifications, storage input / output operations per second (IOPS) and throughput, and network bandwidth quality of service (QoS) guarantee resource requirements parameters can be extracted from the preset business model library. Combined with business priority and elastic scaling capabilities, the initial static reservation amount and reservation time period of virtual machines, storage and network resources can be calculated.

[0037] Step 103: Based on the dynamic resource feature model corresponding to the business system, predict the cloud platform resource demand of the business system within a preset time period in the future.

[0038] For example, long short-term memory neural network algorithms can be used to predict the demand for virtual machines, storage, and network resources in the future based on dynamic feature models of business resource usage.

[0039] Step 104: If the cloud platform resource demand exceeds the static reserved amount within the corresponding reserved time period, the cloud platform resources corresponding to the business system will be reallocated according to the business priority.

[0040] For example, if the predicted resource demand exceeds the initial static reservation amount, the reservation resource scheduling strategy is triggered. Specifically, the cloud platform virtual machine, storage and network resources can be re-allocated according to the business priority classification criteria. The resources required by high-priority business systems are allocated first from the high-performance dedicated resource pool. For ordinary business systems, the reserved resource scale is dynamically adjusted from the shared resource pool according to their resource usage intensity.

[0041] For example, a consistent hashing load balancing algorithm can be used to prioritize high-priority business requests to be executed on reserved dedicated high-performance resources, while ordinary business requests are assigned to a shared resource pool for processing. During the reservation of dedicated resources, the service response time and request error rate of the business system and key service level agreement indicators are continuously monitored. If an anomaly is detected, the reserved anomaly response plan is activated in a timely manner, and the scale of dedicated resources is flexibly adjusted.

[0042] In some examples, when the reserved dedicated resources expire, it is determined whether to renew them based on business continuity requirements. If renewal is required, a resource reservation application is submitted in advance according to the dedicated resource application process, and the dedicated resource delivery time commitment is followed. If renewal is not required, the dedicated resources are released into the shared resource pool.

[0043] In some examples, when a sudden surge in business traffic is detected and the existing reserved resources cannot meet the elastic expansion requirements, an emergency resource expansion mechanism is activated. The required cloud host and cloud disk resources are quickly applied for from the reserved elastic resource pool. In accordance with the usage permission control and billing preferential policies of elastic resources, after the business peak ends, the excess resources are automatically released in accordance with the reserved resource reclamation mechanism.

[0044] In some examples, when the emergency resource expansion mechanism is activated, if the existing cloud platform cannot meet the demand, the differences between the current business system's cloud platform and the cloud platform to be migrated are assessed, and the migration path is determined before the business is migrated to the cloud platform to be migrated.

[0045] In some examples, the capacity of the elastic resource pool can be dynamically planned and optimized based on historical peak business data and future business growth expectations. Elastic resource hierarchical operation and maintenance service level agreements can be formulated to clarify resource delivery time commitments under different business scenarios, so as to meet business elasticity needs to the greatest extent. At the same time, the capacity ratio of dedicated resources and shared resources can be continuously optimized.

[0046] Compared with existing technologies, by applying the technical solution of this embodiment, the microservice topology of the business system deployed on the cloud platform is first obtained; then, the microservice topology is matched with the resource requirements of each microservice component in the business system to determine the static reserved amount of cloud platform resources corresponding to the business system in each reserved time period; then, based on the dynamic feature model of the resources corresponding to the business system, the cloud platform resource demand of the business system in the future preset time period is predicted; if the cloud platform resource demand exceeds the static reserved amount in the corresponding reserved time period, the cloud platform resources corresponding to the business system are reallocated according to the business priority. By constructing a fine-grained mapping relationship between microservice topology and resource requirements, accurate initial resource reservation based on business architecture characteristics is achieved, effectively avoiding resource waste or insufficiency caused by traditional coarse-grained allocation. Furthermore, by combining a dynamic resource feature model based on historical data and machine learning algorithms, future resource requirements are predicted, significantly improving the accuracy and timeliness of prediction. In addition, when the prediction results exceed the static reservation amount, a dynamic reallocation mechanism based on business priority is introduced, taking into account both service quality and resource utilization efficiency. This forms a complete technical closed loop from topology awareness, static reservation, dynamic prediction to intelligent reallocation, which is suitable for complex and ever-changing cloud environments, can effectively cope with business load fluctuations, and improve the overall resource utilization and business continuity assurance capabilities of the cloud platform.

[0047] To further illustrate the specific implementation process of the method in this embodiment, this embodiment provides the following: Figure 2 The specific method shown includes:

[0048] Step 201: Obtain the microservice topology of the business system deployed on the cloud platform.

[0049] For example, by calling the application programming interface (API) provided by the cloud platform, combined with service registration and discovery mechanisms (such as Nacos and Consul) and telemetry data from the service mesh (such as Istio), the deployment information, network configuration, and inter-service call relationships of each microservice instance in the business system can be collected. Through data aggregation and topology analysis, a microservice topology structure reflecting the dependencies and communication paths between microservice components can be generated.

[0050] Step 202: Based on the preset business model library, match the corresponding resource requirement parameters according to the microservice topology of the business system.

[0051] In some examples, the microservice component deployment topology of the business system can be matched based on the microservice component performance parameters and resource requirement parameters stored in the preset business model library to obtain the virtual machine performance specification parameters, storage device IOPS and throughput parameters, and network bandwidth QoS guarantee parameters corresponding to the microservice component.

[0052] Step 203: Based on the linear programming method, and combining the performance parameters, resource requirement parameters, business priorities, and elastic scaling capabilities of each microservice component, calculate the initial resource reservation amount corresponding to the business system.

[0053] In some examples, a linear programming-based resource reservation calculation tool can be used to calculate the initial resource reservation amount for virtual machines, storage, and network resources by combining the obtained microservice component resource requirement parameters, business priority indicators, and elastic scaling capability indicators.

[0054] Step 204: Use a multi-objective optimization algorithm to optimize and solve the initial resource reservation amount for each time period, and determine the static reservation amount of cloud platform resources corresponding to the business system in each reservation time period.

[0055] For example, historical business load data is analyzed using the ARIMA time series processing tool to identify the time distribution characteristics of business peak and off-peak periods, thereby determining the static reservation time periods for various resources. Based on this, with the time distribution characteristics as constraints, a genetic algorithm is used to optimize the initial reservation scheme in multiple objectives. Under the premise of meeting business performance requirements, resource utilization and service quality are balanced to generate the optimal static reservation strategy for resource allocation in each time period, thereby determining the static reservation amount of cloud platform resources corresponding to the business system in each reservation time period.

[0056] Optionally, step 204 may further include: processing historical business load data using time series analysis methods to identify the time distribution characteristics of resource requirements of the business system; and using a genetic algorithm to perform multi-objective optimization on the initial resource reservation amount based on the time distribution characteristics of resource requirements of the business system, thereby obtaining the static reservation amount of cloud platform resources corresponding to the business system in each reservation time period.

[0057] For example, a pre-defined business model library stores performance parameters for microservice components. For instance, a web server component requires 2 CPU cores, 4GB of memory, and 50GB of storage; a database component requires 4 CPU cores, 8GB of memory, and 100GB of storage; and a cache component requires 2 CPU cores, 4GB of memory, and 20GB of storage. Based on the deployment topology of the microservice components in the business system, the corresponding resource requirements are matched. For example, for a microservice system containing 3 web servers, 2 databases, and 1 cache, the calculated total requirements are 14 CPU cores, 28GB of memory, and 370GB of storage. Using a linear programming-based resource reservation calculation tool, with a business priority weight of 0.6 and an elastic scaling capability weight of 0.4, the initial static virtual machine resource reservation is calculated to be 16 CPU cores, 32GB of memory, 400GB of storage, and 100Mbps of network bandwidth. Using ARIMA time series processing tools, historical business load data from the past 30 days was processed, revealing peak business periods as 10:00-12:00 and 14:00-16:00 daily, and off-peak periods as 00:00-06:00 daily. Based on this, static reservation time periods for various resources were determined. A genetic algorithm was employed for multi-objective optimization, with a population size of 100, 1000 iterations, a crossover probability of 0.8, and a mutation probability of 0.1. Using the time distribution characteristics as constraints, the resource reservation scheme was optimized while meeting business performance requirements. The final result is as follows... Figure 3 As shown, the optimal resource reservation strategy that balances resource utilization and business performance is obtained. For example, during peak periods, 20 CPU cores, 40GB memory, 500GB storage space and 150Mbps bandwidth are reserved; during off-peak periods, 10 CPU cores, 20GB memory, 300GB storage space and 80Mbps bandwidth are reserved; and the reservation amount is dynamically adjusted according to the load during other time periods.

[0058] Step 205: Based on the resource dynamic characteristic model corresponding to the business system, predict the cloud platform resource demand of the business system in the future within a preset time period.

[0059] For example, based on the resource dynamic characteristic model corresponding to the business system, by analyzing the periodicity, trend and load pattern characteristics in historical resource usage data, and combining machine learning or time series prediction algorithms, the cloud platform resource demand of the business system in the future preset time period can be predicted, providing a basis for decision-making for dynamic resource scheduling and elastic scaling.

[0060] Optionally, step 205 may further include: constructing a historical resource time-series dataset corresponding to the business system based on the resource dynamic feature model; inputting the historical resource time-series dataset into a long short-term memory neural network to predict the cloud resource demand of the business system within a preset time period in the future, and generating a sequence of resource demand prediction results for the business system.

[0061] For example, a historical resource time-series dataset may include one or more of the following: historical CPU usage, historical memory usage, historical memory I / O operation count, historical memory throughput, and historical network bandwidth data.

[0062] In some examples, the input dataset for a Long Short-Term Memory (LSTM) neural network can be constructed based on a dynamic feature model of business resource usage. This dataset includes historical data on virtual machine CPU utilization, memory utilization, storage IOPS, storage throughput, and network bandwidth. The data is preprocessed using Z-score normalization. The LSM algorithm is then used to determine the optimal network structure through grid search. The mean squared error (MSE) loss function and the Adam optimizer are used to update parameters, predicting the virtual machine, storage, and network resource requirements for the next 24 hours and generating a prediction sequence. The prediction results are compared with the initial static reservation, calculating the resource demand difference at each time point. A dynamic threshold is set based on historical resource usage fluctuations. If the difference exceeds this threshold, the corresponding time point is marked as a resource shortage point, and the specific resource gap is recorded. Based on the number and distribution characteristics of resource shortage points and the resource gap, a reserved resource scheduling instruction is generated, containing scheduling time, resource type, and scheduling amount. The instruction is in JSON format, including timestamp, resource type, and fields for increasing or decreasing resource amount. This instruction is then sent to the resource scheduling execution module to trigger subsequent resource reallocation operations.

[0063] In some embodiments, historical data from the past 30 days can be extracted from a dynamic feature model of business resource usage, including virtual machine CPU utilization (range 0-100%), memory utilization (range 0-100%), storage IOPS (range 0-10000), storage throughput (range 0-1000MB / s), and network bandwidth (range 0-1000Mbps), collected every 5 minutes. Z-score standardization is applied to this data, making the mean of each feature 0 and the standard deviation 1. For example, if the mean CPU utilization is 60% and the standard deviation is 15%, then the standardized 70% CPU utilization is converted to 0.67. A grid search method is used to optimize the Long Short-Term Memory (LSTM) neural network, ultimately determining a 3-layer network structure with 64 neurons per layer, a dropout rate of 0.2, and 100 training epochs. Using the Adam optimizer with a learning rate of 0.001, resource requirements are predicted for 288 5-minute time points over the next 24 hours. The predicted results are compared with the initial static reserves, such as CPU 80%, memory 70%, storage IOPS 5000, storage throughput 500MB / s, and network bandwidth 500Mbps, and the difference is calculated. A dynamic threshold is set to 20% of the static reserves, i.e., 16% for CPU, 14% for memory, etc. If the predicted value at a certain time point exceeds the sum of the reserves and the threshold, such as a CPU predicted value of 98%, exceeding 96% (80% + 16%), it is marked as a resource deficiency point, and a 2% shortfall is recorded. Based on the identified resource deficiency points, a JSON-formatted scheduling instruction is generated, such as {"timestamp":"2024-07-1710:00:00","resource_type":"CPU","action":"increase","amo unt":"2%"}, and sent to the resource scheduling execution module for processing.

[0064] Optionally, the method in this embodiment may further include: obtaining resource usage time-series data of the business system at the microservice component granularity; performing normalization and smoothing processing on the resource time-series data; and performing cluster analysis on the processed resource time-series data through a data analysis engine to generate a resource dynamic feature model corresponding to the business system.

[0065] For example, resource usage time-series data may include one or more of the following: CPU utilization, memory utilization, number of storage I / O operations, storage throughput, and network bandwidth.

[0066] In some examples, a resource monitoring module can be used to collect metrics such as virtual machine CPU and memory usage, storage IOPS, storage throughput, and network bandwidth at the microservice component level of the business system in real time. The collected resource usage data can then be clustered and analyzed by a data analysis engine to identify peak and trough periods of resource usage and generate a dynamic feature model of business resource usage.

[0067] For example, resource usage metrics such as CPU utilization, memory utilization, storage IOPS, storage throughput, and network bandwidth are collected in real time from the virtual machines of microservice components in the business system to form a time-series dataset. The collected data is preprocessed, including data standardization using the min-max normalization method, outlier detection and removal based on the 3-standard deviation method, and smoothing using the moving average method to obtain a standardized resource usage time-series dataset. Subsequently, the K-means clustering algorithm is applied to perform cluster analysis on the processed data, setting the number of clusters to 3 and the maximum number of iterations to 100, classifying similar resource usage patterns into three categories: high load, medium load, and low load, and identifying resource usage characteristics in different time periods. Based on the clustering results, a dynamic feature model of resource usage is constructed, calculating the mean and variance of resource usage in each type of time period, extracting periodic features using fast Fourier transform, and analyzing trend changes using exponential smoothing, ultimately forming a dynamic feature description of business resource usage that includes multi-dimensional features such as mean, variance, periodicity, and trend.

[0068] For example, in a business system, the resource monitoring module can collect performance metrics from the virtual machines of microservice components every 5 minutes, including CPU utilization, memory utilization, storage IOPS, storage throughput, and network bandwidth.

[0069] For example, a web service component collects 288 data points over 24 hours. Its CPU utilization ranges from 20% to 80%, memory utilization from 30% to 70%, storage IOPS from 100 to 500, storage throughput from 10 to 50 MB / s, and network bandwidth from 5 to 20 Mbps. The collected data is preprocessed by using a minimum-maximum normalization method to linearly map each indicator to the 0-1 range; for example, converting the CPU utilization of 20%-80% to a 0-1 range. Outliers are detected using the 3-standard-deviation method, identifying and marking data points exceeding the mean ± 3 standard deviations as anomalies. The sequence is smoothed using a 5-point moving average method to reduce short-term fluctuation noise. The processed data is then input into a K-means clustering algorithm with 3 clusters and a maximum of 100 iterations. The algorithm categorizes resource usage patterns into three types: high load (e.g., CPU > 70%), medium load (e.g., CPU > 70%), and low load (e.g., CPU > 70%). The system analyzes resource usage in two phases: high load (40%-70%) and low load (CPU < 40%). Based on clustering results, a dynamic characteristic model of resource usage is constructed, calculating the mean and variance for each category. For example, the mean CPU utilization during high load periods is 75%, and the variance is 5%. Combined with Fast Fourier Transform analysis, periodicity is identified, identifying the weekday period from 9:00 to 18:00 as a regular high load cycle. Exponential smoothing (smoothing coefficient 0.2) is used to analyze trend changes and predict resource usage trends for the next 24 hours. Finally, a dynamic characteristic description containing multiple dimensions such as mean, variance, periodicity, and trend is formed, providing data support for subsequent resource prediction, reservation optimization, and dynamic scheduling.

[0070] Step 206: If the cloud platform resource demand exceeds the static reserved amount within the corresponding reserved time period, the cloud platform resources corresponding to the business system will be reallocated according to the business priority.

[0071] In some examples, when the predicted cloud platform resource demand exceeds the static reservation amount within the corresponding reserved time period, the system will trigger a resource reallocation mechanism to dynamically adjust resources according to preset business priorities, prioritizing the resource supply for high-priority business systems. By allocating the required resources from the shared resource pool or dedicated resource pool according to priority weights, the system achieves differentiated scheduling and efficient utilization of resources, ensuring the service quality of critical businesses while improving overall resource utilization.

[0072] For example, the overall process of this embodiment is as follows: Figure 4 As shown, the system first extracts virtual machine performance specifications, storage, and network resource requirements parameters, then calculates static reservation quantities and reservation time periods; after collecting resource usage data in real time, it generates a dynamic feature model and predicts future resource demands based on this model; based on the prediction results, it triggers a reserved resource scheduling strategy to perform secondary resource allocation; finally, it implements load balancing and anomaly response plans to ensure stable system operation.

[0073] Optionally, step 206 may further include: dividing the business requests of the business system into first-priority business requests and second-priority business requests based on business priorities, with the first-priority business requests having a higher business priority than the second-priority business requests; and using a consistent hash load balancing algorithm, prioritizing the allocation of first-priority business requests to the dedicated resource pool of the cloud platform for processing, while allocating second-priority business requests to the shared resource pool of the cloud platform for processing.

[0074] In some examples, considering factors such as business criticality, Service Level Agreement (SLA) metrics, and expected revenue, business systems in the cloud platform can be classified into high-priority and ordinary business systems according to a preset business priority classification standard. The Analytic Hierarchy Process (AHP) is then used to calculate the priority weight of each business system. A list of available virtual machines, storage, and network resources is obtained from the high-performance dedicated resource pool. The total amount of resources required by high-priority business systems is calculated. If the pool has sufficient resources, the required resources are allocated in full. If resources are insufficient, they are allocated proportionally according to the priority weight, and the unmet resource gap is recorded.

[0075] In some examples, for ordinary business systems, a multi-dimensional weighted average algorithm is used to calculate their resource usage intensity index. This index integrates the weighted values ​​of CPU utilization, memory utilization, storage IOPS, and network bandwidth to reflect their overall resource consumption level. Based on this index and combined with the resource status of the shared resource pool, a linear proportional adjustment method is used to dynamically adjust the scale of reserved resources: for business systems with resource usage intensity higher than the system average, the reserved resources are increased by up to 50% proportionally to ensure performance; for those below the average, the reserved resources are reduced by up to 30% proportionally to improve resource utilization, thereby achieving refined and differentiated dynamic scheduling of resources.

[0076] In some embodiments, the cloud platform may use the analytic hierarchy process (AHP) to calculate the priority weight of a business system based on factors such as business criticality weight (0.1), service level agreement weight (0.3), and expected revenue weight (0.2).

[0077] For example, a core trading system has a business priority weight of 0.8, while an internal office system has a weight of 0.3. The high-performance dedicated resource pool currently has 100 virtual CPU cores, 200GB of memory, and 10TB of storage space available. The core trading system requires 80 virtual CPU cores, 160GB of memory, and 8TB of storage space, which is lower than the available resources in the pool; therefore, it is allocated the required resources in full. For ordinary business systems, a multi-dimensional weighted average algorithm is used to calculate resource usage intensity indicators. For example, a system has a CPU utilization of 70% (weight 0.3), a memory utilization of 60% (weight 0.3), and storage IOPS of... With a network bandwidth utilization rate of 50% (weight 0.2) and a resource utilization intensity index of 0.62, calculated to be higher than the average of 0.5 for all ordinary business systems, a 24% increase in reserved resources is determined based on the linear proportional adjustment method. If the original reserved resources of the system were 4 virtual CPU cores and 8GB of memory, they will be dynamically adjusted to 5 virtual CPU cores and 10GB of memory to achieve fine-grained resource reallocation based on actual load.

[0078] In some examples, a consistent hashing algorithm can be used to construct a virtual node ring. The MD5 hash function maps the IP addresses of server nodes in dedicated high-performance resources and shared resource pools to a hash ring ranging from 0 to 2^32-1. The hash value is calculated based on the user ID or request URL of the business request, and high-priority business requests are routed to the nearest dedicated high-performance resource node in a clockwise direction, while ordinary business requests are routed to the nearest shared resource pool node. A distributed monitoring collector is deployed to acquire key Service Level Agreement (SLA) metrics such as service response time and request error rate of the business system in real time. The collected data is stored in a time-series database and threshold triggers are configured. A sliding window mechanism is used to calculate the recent average response time and error rate. The system's operating status is judged based on preset SLA thresholds. When the metrics exceed the limits within the sliding window, a reserved anomaly response plan is triggered. The resource elastic scaling controller dynamically adjusts the scale of dedicated resources. When performance anomalies are detected, virtual machine instances are added, and the load balancer weight is adjusted synchronously. Simultaneously, the node mapping relationship of the consistent hashing ring is updated, generating virtual nodes for the newly added nodes and inserting them into the ring, achieving smooth service scaling and traffic redistribution.

[0079] In some embodiments, a consistent hashing algorithm can be used, employing the MD5 hash function to map the IP addresses of 10 dedicated high-performance servers and 50 shared resource servers onto a hash ring ranging from 0 to 2^32-1. Each physical server creates 100 virtual nodes, generating a total of 6000 virtual nodes evenly distributed across the hash ring. When a high-priority service request with user ID "user123456" is received, the hash value 3754387562 is calculated using MD5, and the request is routed to the nearest dedicated high-performance resource node in a clockwise direction on the hash ring. The system collects operational data every 10 seconds through a distributed monitoring collector. For example, the average response time of a high-priority service across 300 sampling points in the last 5 minutes is 180 milliseconds, with an error rate of 0.08%. Based on a preset Service Level Agreement (SLA) threshold (e.g., average response time ≤ 200 milliseconds, error rate ≤ 0.1%), sliding window analysis reveals that the average response time has continuously increased from 160 milliseconds to 220 milliseconds in the last 10 minutes, exceeding the 200 millisecond threshold, triggering a reserved anomaly response plan.

[0080] For example, after the resource elastic scaling controller detects a performance anomaly, the number of dedicated high-performance servers is increased from 10 to 11, an increase of 10%, supporting incremental increases of 10% per instance, up to a maximum of twice the original number. Simultaneously, the load balancer weight is adjusted, setting the initial weight of the new server instance to 50% of the existing instances (e.g., if the new server's weight is 5, it becomes 10), and increasing by 1 every minute for 5 minutes, gradually reaching 10, achieving smooth traffic import. Furthermore, 100 virtual nodes are generated for the new server and inserted into a consistent hash ring, increasing the total number of virtual nodes on the ring to 6100. This only affects request mapping between adjacent nodes, minimizing data migration overhead, effectively redistributing requests, alleviating system pressure, and ensuring the service quality of high-priority services.

[0081] In some examples, the reserved expiration time of dedicated resources can be monitored through the resource manager, and a renewal assessment process can be triggered 7 days before the reservation period expires. Business continuity requirement metrics, including the maximum allowable service interruption time and recovery point objective (RPO), are obtained from the business system configuration database. Simultaneously, resource usage data for the past 30 days, covering key metrics such as CPU utilization, memory utilization, storage I / O, and network bandwidth, is extracted from the resource monitoring system. A C4.5 decision tree algorithm (with a maximum depth of 5 and a minimum number of sample splits of 20) is used to analyze factors such as business continuity requirements, resource utilization, and peak business period distribution to determine whether the dedicated resource needs to be renewed. The decision results are output in JSON format, including the renewal decision and its basis.

[0082] In some examples, if the decision is to renew, a resource reservation request is automatically generated, detailing the required resource types, quantities, and reservation duration. A resource approval process is created using a workflow tool based on the BPMN 2.0 standard, and the request is submitted to the resource approval module. Based on the preset dedicated resource delivery time commitment, the latest resource delivery time is calculated, and corresponding reminders and alarms are set up in the workflow to ensure timely resource delivery. If the decision is not to renew, a resource release process is automatically triggered when the dedicated resource reservation expires: first, the resource status in the resource management database is updated to pending release; then, a resource cleanup script is executed to delete business-related configurations and data; finally, the dedicated resource configuration information is added to the available resource list of the shared resource pool, and the resource scheduling algorithm interface is called to update the node information in the load balancer, enabling the newly released resources to be efficiently utilized by other business systems. This process not only ensures effective resource recovery and reallocation but also guarantees the continuity of business systems and service quality. The entire process improves resource management efficiency through automation, reduces human intervention, and optimizes resource utilization and service response speed.

[0083] In some embodiments, if the resource manager detects that the dedicated resource reservation for a core business system will expire in 7 days, a renewal assessment process is triggered. The system retrieves its business continuity requirements from the business system configuration database, including the maximum allowable service interruption time of 5 minutes and the recovery point objective (RPO) of 1 hour; such as Figure 5As shown, resource usage data for the past 30 days was extracted from the resource monitoring system, revealing an average CPU utilization of 75%, memory utilization of 80%, storage IOPS of 5000, and network bandwidth utilization of 60%, indicating high resource load. Based on this data, the C4.5 decision tree algorithm, with a maximum depth of 5, analyzed the data, comprehensively evaluating resource usage intensity and business continuity requirements. The final decision determined that dedicated resources needed to be renewed, and the decision result was output in JSON format: {"renewal":true,"reason":"high_resource_utilization_and_strict_continuity_requirement s"}. The system automatically generated a resource reservation application form, requesting the renewal of dedicated resources (4 CPU cores, 16GB memory, and 1TB storage) for 6 months. An approval process was created using a workflow engine based on the BPMN 2.0 standard, and the application was submitted to the resource approval module. Based on the commitment to deliver dedicated resources within 3 business days, the system calculates the latest delivery time as the current time plus 10 calendar days (including weekend buffer) and sends alerts in stages 24 hours, 12 hours, and 6 hours before the delivery deadline to ensure timely resource availability. If the decision is not to renew, the resource release process is automatically executed when the reservation expires: first, the resource status is updated to "pending release," then a cleanup script is run to clear related configurations and data, then the resource information of 4-core CPU, 16GB memory, and 1TB storage is injected into the shared resource pool and the available resource list is updated. At the same time, the resource scheduling module is notified via API to refresh the load balancer node information, so that the released resources can be called by other business systems in real time, thereby achieving efficient resource recycling and reuse. The overall resource utilization rate has increased from 75% to 85%, significantly improving the resource scheduling efficiency and operational benefits of the cloud platform.

[0084] Optionally, the method in this embodiment may further include: when the traffic data of the business system is detected to be higher than the preset dynamic traffic threshold and the cloud platform cannot meet the conditions for elastic resource expansion, obtaining the corresponding cloud host and cloud disk resources from the pre-configured elastic resource pool according to the resource demand of the cloud platform; configuring resource expansion based on the cloud host and cloud disk resources and according to the resource usage permissions of the business system; and automatically releasing the newly added resources used for resource expansion configuration according to the reserved resource reclamation mechanism after the traffic data of the business system is detected to be lower than or equal to the preset dynamic traffic threshold.

[0085] In some examples, Prometheus real-time monitoring tools can continuously collect traffic data such as requests per second, average response time, and CPU utilization from the business system. An exponential moving average algorithm is used to calculate the average of these metrics over the past hour as a benchmark. When the current value exceeds this benchmark by 150% and persists for more than 5 minutes, it is considered a traffic surge, triggering an emergency resource expansion mechanism. Based on a pre-defined elastic scaling strategy, a linear regression algorithm is used to predict resource demand within the next 30 minutes, calculating the required number of cloud hosts and cloud disks for expansion. Resources are quickly requested from the reserved elastic resource pool, and access permissions are configured according to the business system's security policy. After the resource request is completed, a new resource ID, IP address, and configuration information are generated. The system retrieves the resource list, calls Terraform's resource orchestration tool to read the list, connects the new resources to the load balancer and sets their initial weight to 50% of the existing nodes, achieving smooth traffic import. Simultaneously, based on the elastic resource's access control policy and billing discount policy, it updates the resource usage records in the billing system. After business traffic drops below the dynamic threshold of 120% for 30 minutes, a resource reclamation mechanism is triggered, releasing 10% of the additional resources every 5 minutes using a decreasing strategy. This gradually reduces the weight of the new node in the load balancer until it is completely removed, ultimately restoring the resource scale to the pre-expansion level. The corresponding record is then removed from the billing system, enabling accurate billing based on actual usage time, achieving elastic scaling and cost optimization of resources.

[0086] For example, the Prometheus monitoring tool can collect business system data every 15 seconds and store it in a time-series database. During a platform activity, the system detected a sudden increase in requests per second from a baseline of 1000 to 1800, an increase in average response time from 200 milliseconds to 350 milliseconds, and an increase in CPU utilization from 60% to 95%. These indicators exceeded the dynamic threshold (150% of the baseline) for 6 consecutive minutes, triggering an emergency resource expansion mechanism. A linear regression algorithm predicted that the request volume would reach 2500 requests per second within the next 30 minutes. Based on this, it was calculated that 5 new 8-core, 16GB cloud hosts and 500GB cloud disk resources were needed. The system then quickly completed the resource application from the elastic resource pool and configured security group rules to only allow the load balancer to access the new resources through ports 80 and 443. The Terraform tool read the resource list containing information on the 5 new hosts and automatically... The system was added to a load balancer with an initial weight of 50 (existing nodes have a weight of 100) to achieve smooth traffic import. The billing system simultaneously recorded the usage information of the 40 newly added CPU cores and started billing at a rate of 0.5 yuan / core / hour. After 3 hours, monitoring data showed that the request volume dropped to 1200 times / second and remained below 120% of the dynamic threshold for 35 minutes. The system then initiated a resource reclamation process, releasing one host every 5 minutes using a decreasing strategy, while gradually reducing its weight in the load balancer from 50 to 0 before removing it. All 5 hosts were reclaimed within 25 minutes, and the billing system calculated the total cost of 68.33 yuan based on the actual usage time of 3 hours and 25 minutes. Through this dynamic scaling up and down, the system maintained 85% CPU utilization during peak traffic periods, improving resource utilization efficiency by 15% compared to fixed resource configuration, achieving the synergistic goal of elastic scaling and cost optimization.

[0087] Optionally, the method in this embodiment may further include: using a multi-objective linear programming algorithm to dynamically plan the total capacity of the elastic resource pool based on the historical peak business data and future business growth forecast of the business system, and establishing a hierarchical operation and maintenance service level mechanism for elastic resources based on the capacity planning results of the elastic resource pool.

[0088] In some examples, the ARIMA model can be used to perform time-series analysis on peak business data from the past 12 months to identify cyclical fluctuations and long-term growth trends. The Delphi method can be combined to transform the business department's qualitative expectations for the next six months into quantitative data. An ensemble learning approach can then be used to fuse the outputs of both methods to construct a more accurate elastic resource demand forecasting model. Based on this model, a multi-objective linear programming algorithm is used to minimize total cost while satisfying 95% of peak demand and minimizing resource allocation. A genetic algorithm is then used to solve for the optimal elastic resource pool capacity configuration scheme, including CPU, memory, and storage. Resources such as network bandwidth are allocated to corresponding resource pools according to their type. Based on this, a tiered service level agreement (SLA) is established, dividing resource delivery time into three levels: 15 minutes, 1 hour, and 4 hours. Delivery thresholds are set according to the importance of business scenarios, and an automatic compensation mechanism for breach of contract is established. At the same time, a dynamic resource utilization balancing strategy is set. When the utilization rate of dedicated resources is lower than 60%, its idle resources are transferred to the shared pool. When the utilization rate of the shared pool exceeds 85%, resources are borrowed in the opposite direction. Cost factors are introduced in combination with the power and cooling costs of different time periods to optimize the overall resource scheduling strategy and achieve the optimal synergy between cost, performance, and availability.

[0089] In some embodiments, the ARIMA(2,1,2) model analyzes data from the past 12 months and finds that business peaks occur in November and June each year, with an annual growth rate of 15%. The Delphi method collects predictions from 10 business experts for the next 6 months, which are then converted into an expected growth rate of 18%. Ensemble learning combines ARIMA outputs and expert predictions to generate a final model predicting peak demand of 2 million concurrent users next year. A multi-objective linear programming algorithm, with the goal of minimizing cost and constraints set to meet 95% of the peak demand of 1.9 million concurrent users, yields the optimal solution: 12,000 CPU cores, 48TB of memory, 2PB of storage capacity, and 2Tbps of network bandwidth. A genetic algorithm, after 1000 generations of evolution with a population size of 100, a crossover rate of 0.8, and a mutation rate of 0.1, finds the optimal solution. The Service Level Agreement defines delivery within 15 minutes as emergency level, requiring 99.9% availability; within 1 hour as high priority, requiring 99.5% availability; and within 4 hours as normal level, requiring 99% availability. The penalty mechanism stipulates a compensation of 1000 yuan for each minute of delay. The reinforcement learning algorithm uses DeepQ-Network, with a state space containing current resource utilization and business load, and an action space for resource scheduling decisions. The reward function is designed as: R = 0.6 * resource utilization + 0.4 * business performance score - 0.2 * cost factor. After 100,000 iterations of training, the algorithm learns to release 25% of resources to the shared pool when the utilization rate of dedicated resources is below 60%, and to borrow 20% of resources from the dedicated pool when the utilization rate of shared resources exceeds 85%. Considering that electricity prices fluctuate between 0.3 and 0.8 yuan / kWh, the algorithm prioritizes resource scheduling during periods of low electricity prices, resulting in annual cost savings of up to 15%.

[0090] Optionally, the method in this embodiment may further include: if the cloud platform cannot meet the emergency expansion requirements of resources, obtaining the resource configuration information of the business system and the resource specifications and service options of candidate cloud platforms; based on the resource specifications and service options of the candidate cloud platforms, determining whether the candidate cloud platforms can meet the resource requirements of the business system, and identifying the cloud platforms that meet the resource requirements of the business system as the cloud platforms to be migrated; inputting the resource configuration information of the current business system into the migration adaptability scoring model, calculating the adaptability score of each cloud platform to be migrated, the migration adaptability scoring model being used to evaluate the differences in resource specifications and performance between the cloud platform where the business system is located and the cloud platform to be migrated; identifying the cloud platforms to be migrated with adaptability scores higher than a preset adaptability threshold as target cloud platforms, and migrating the business system to the target cloud platform based on the corresponding target migration path.

[0091] For example, when the emergency resource expansion mechanism is activated, if the existing cloud platform cannot meet the demand, the differences between the current business system's cloud platform and the cloud platform to be migrated are assessed, and the migration path is determined before the business is migrated to the cloud platform to be migrated.

[0092] In some examples, such as Figure 6 As shown, based on the cloud platform where the current business system resides, relevant service interfaces and configuration files can be obtained to acquire the resource configuration information of the business system. Based on this information, resource monitoring tools are used to obtain the resource requirements of the business system, determining specific resource requirements parameters such as processor, memory, storage, and network bandwidth. Using these determined resource requirements parameters, the resource specifications and service options of the target cloud platform to be migrated are obtained to determine whether the target cloud platform can meet the resource requirements of the business system. Based on the acquired resource specifications and service options, comparative analysis tools are used to evaluate the performance, cost, and security differences between the current cloud platform and the target cloud platform, generating a difference assessment report. Using this report, the optimal migration path for the business system is determined, identifying the specific migration method, including cold migration, hot migration, or hybrid migration solutions. Based on the determined migration method, migration tools are used to acquire the current status and data integrity of the business system, determining key indicators for migration testing and generating a migration test plan. Using this test plan, the test environment and test data are acquired, and simulation migration tools are used to conduct migration tests on the business system, assessing the performance and stability of the migrated system and obtaining the test results. Based on the test results, a switching tool was used to obtain the actual migration time window and switching process, and the business system was migrated and switched to confirm the stable operation of the business system on the target cloud platform.

[0093] For example, on the cloud platform where the current business system resides, the system's resource configuration information is first obtained through the cloud platform's API service interface. For instance, the `DescribeInstances` API is used in AWS, or the `ResourceGraphAPI` is used in Azure to obtain detailed configurations such as instance type, number of CPU cores, memory size, storage type and size, and network bandwidth. Next, resource monitoring tools such as Prometheus and Grafana are used to monitor resource usage in real time, and query statements are written using the PromQL query language (such as `avg(rate(node_cpu_seconds_total{mode="idle"}[1m]))`) to calculate specific parameters such as average and peak CPU utilization, average and peak memory utilization, disk I / O rate, and network throughput.

[0094] For example, based on these resource requirement parameters, query the resource specifications and service options of the target cloud platform (such as Google Cloud Platform, GCP) to be migrated. Use GCP's query API to obtain the specifications of different instance types; for example, n1-standard-4 provides 4 vCPUs, 15GB of memory, and corresponding network bandwidth and storage options. Compare and analyze these specifications with the resource requirements of the current business system to determine whether the target cloud platform meets the requirements. If monitoring shows that the current cloud platform's peak CPU utilization is 80% and memory utilization is 14GB, then the GCP n1-standard-4 instance is a suitable cloud platform.

[0095] In some examples, comparative analysis tools such as CloudHealth or RightScale can be used to conduct a detailed evaluation of the performance, cost, and security of the current cloud platform and the target cloud platform. For instance, cost calculations might reveal that AWS's m.large instance costs $10 per hour, while GCP's n1-standard-4 costs $11 per hour. Regarding security, a difference assessment report can be generated by comparing the encryption standards, access control policies, and compliance authentication of the two. Based on this report, the optimal path and method for migrating the business system can be determined. It is assumed that the assessment recommends a cold migration approach because the business system allows for a short downtime window. When implementing a cold migration, migration tools such as AWS Snowball or Azure DataBox can be used to ensure that data is not lost or corrupted during transmission and to obtain the current state and data integrity of the business system.

[0096] In some examples, detailed migration test plans can be developed to identify key metrics such as system response time, data consistency, and service availability. In the test environment, multiple migration tests are conducted using simulation migration tools such as CloudEndure or Veeam to simulate all possible failure scenarios, statistically analyzing whether the variation in system response time remains within acceptable limits, ensuring that the performance and stability of the migrated system meet expectations. Based on the test results, the actual migration time window and switchover process are then determined. Switching tools such as DNS switching services are used to redirect traffic from the old cloud platform to the new cloud platform, ensuring the continuity and stability of the business system during the switchover process. Throughout the migration process, real-time monitoring tools are used to continuously check the health status of various system metrics, ensuring that the migrated system runs stably on the target cloud platform and reaches the expected service level. This not only achieves effective resource migration but also guarantees business continuity and user experience.

[0097] Compared to existing technologies, this embodiment first conducts a precise demand assessment of virtual machines, storage, and network resources to ensure the rationality of the initial static reservation. Combined with real-time monitoring of resource usage data, it accurately identifies peak and off-peak usage, providing data support for dynamic adjustments. Then, based on a dynamic resource characteristic model, it predicts future demand, promptly identifies resource gaps, and triggers a dynamic reallocation mechanism based on business priorities. This prioritizes the supply of resources for high-priority businesses while dynamically adjusting resources for ordinary businesses based on actual load, improving overall resource utilization efficiency and cost-effectiveness. Furthermore, during the dedicated resource reservation period, it continuously monitors SLA indicators such as service response time and request error rate, promptly triggering contingency plans to elastically expand or shrink the scale of dedicated resources and properly handle renewal assessments and resource release processes after reservation expiration. An emergency expansion mechanism is introduced to address sudden traffic surges, utilizing a pre-set elastic resource pool for rapid expansion and automatic recovery after peak periods. This achieves on-demand resource scaling and cost optimization, enabling intelligent and refined configuration of cloud platform resources based on different business characteristics and dynamic changes. It effectively balances service quality and resource efficiency, meeting the needs of modern enterprises' complex and ever-changing business systems for elastic, stable, and efficient resource management.

[0098] Furthermore, as Figure 1 and Figure 2 To provide a specific implementation of the method shown, this embodiment offers a resource allocation device, such as... Figure 7 As shown, the device includes: an acquisition module 31, a matching module 32, a prediction module 33, and a configuration module 34.

[0099] Module 31 is configured to obtain the microservice topology of the business system deployed on the cloud platform.

[0100] The matching module 32 is configured to match the microservice topology with the resource requirements of each microservice component in the business system, and determine the static reserved amount of cloud platform resources corresponding to the business system in each reserved time period.

[0101] Prediction module 33 is configured to predict the cloud platform resource demand of the business system within a future preset time period based on the resource dynamic feature model corresponding to the business system and using a long short-term memory neural network.

[0102] Configuration module 34 is configured to reallocate cloud platform resources corresponding to the business system according to business priority if the cloud platform resource demand exceeds the static reserved amount within the corresponding reserved time period.

[0103] In some examples of this embodiment, the matching module 32 is further configured to match the corresponding resource requirement parameters based on the microservice topology of the business system according to a preset business model library; calculate the initial resource reservation amount corresponding to the business system based on the linear programming method, combined with the performance parameters, resource requirement parameters, business priority and elastic scaling capability of each microservice component; and optimize the initial resource reservation amount for each time period using a multi-objective optimization algorithm to determine the static reservation amount of the cloud platform resources corresponding to the business system in each reservation time period.

[0104] In some examples of this embodiment, the matching module 32 is further configured to process historical business load data using time series analysis methods to identify the time distribution characteristics of the resource demand of the business system; based on the time distribution characteristics of the resource demand of the business system, to perform multi-objective optimization of the initial resource reservation amount using a genetic algorithm to obtain the static reservation amount of the cloud platform resources corresponding to the business system in each reservation time period.

[0105] In some examples of this embodiment, the prediction module 33 is further configured to construct a historical resource time-series dataset corresponding to the business system based on the resource dynamic feature model. The historical resource time-series dataset includes one or more of the following: historical CPU utilization, historical memory utilization, historical storage input / output operation count, historical storage throughput, and historical network bandwidth data. The historical resource time-series dataset is then input into a long short-term memory neural network to predict the cloud resource demand of the business system within a preset time period in the future, generating a resource demand prediction result sequence for the business system.

[0106] In some examples of this embodiment, the prediction module 33 is further configured to obtain resource usage time-series data of the business system at the microservice component granularity. The resource usage time-series data includes one or more of the following: CPU utilization, memory utilization, number of storage input / output operations, storage throughput, and network bandwidth. The prediction module 33 is then normalized and smoothed. The processed resource time-series data is then clustered using a data analysis engine to generate a dynamic resource feature model corresponding to the business system.

[0107] In some examples of this embodiment, the configuration module 34 is further configured to divide the business requests of the business system into first priority business requests and second priority business requests based on business priority, wherein the business priority of the first priority business requests is higher than that of the second priority business requests; and to allocate the first priority business requests to the dedicated resource pool of the cloud platform for processing through a consistent hash load balancing algorithm, and allocate the second priority business requests to the shared resource pool of the cloud platform for processing.

[0108] In some examples of this embodiment, the configuration module 34 is further configured to: if the cloud platform cannot meet the emergency resource expansion requirements, obtain the resource configuration information of the business system and the resource specifications and service options of the candidate cloud platforms; based on the resource specifications and service options of the candidate cloud platforms, determine whether the candidate cloud platforms can meet the resource requirements of the business system, and identify the cloud platforms that meet the resource requirements of the business system as the cloud platforms to be migrated; input the resource configuration information of the current business system into the migration adaptability scoring model, calculate the adaptability score of each cloud platform to be migrated, the migration adaptability scoring model is used to evaluate the differences in resource specifications and performance between the cloud platform where the business system is located and the cloud platforms to be migrated; identify the cloud platforms to be migrated with adaptability scores higher than a preset adaptability threshold as target cloud platforms, and migrate the business system to the target cloud platform based on the corresponding target migration path.

[0109] In some examples of this embodiment, the configuration module 34 is further configured to, when the traffic data of the business system is detected to be higher than a preset dynamic traffic threshold and the cloud platform cannot meet the resource elastic expansion conditions, obtain corresponding cloud host and cloud disk resources from a pre-configured elastic resource pool according to the resource demand of the cloud platform; perform resource expansion configuration based on the cloud host and cloud disk resources and according to the resource usage permissions of the business system; and automatically release the newly added resources used for resource expansion configuration according to the reserved resource reclamation mechanism after the traffic data of the business system is detected to be lower than or equal to the preset dynamic traffic threshold.

[0110] In some examples of this embodiment, the configuration module 34 is further configured to dynamically plan the total capacity of the elastic resource pool using a multi-objective linear programming algorithm based on the historical business peak data and future business growth prediction of the business system, and to establish a hierarchical operation and maintenance service level mechanism for elastic resources based on the elastic resource pool capacity planning results.

[0111] It should be noted that for other corresponding descriptions of the functional units involved in the resource allocation device provided in this embodiment, please refer to... Figure 1 and Figure 2 The corresponding descriptions in [the document] will not be repeated here.

[0112] Based on the above, Figure 1 and Figure 2 Accordingly, this embodiment also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method. Figure 1 and Figure 2 The method shown.

[0113] Based on this understanding, the technical solution of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as CD-ROM, USB flash drive, mobile hard drive, etc.) and includes several instructions to cause a computer device (such as personal computer, server, or network device, etc.) to execute the methods of various implementation scenarios of this application.

[0114] Based on the above, Figure 1 and Figure 2 The method shown, and Figure 7 To achieve the above objectives, the present application also provides an electronic device, such as a personal computer, server, laptop computer, intelligent robot, or other intelligent terminal, as illustrated in the virtual device embodiment. This device includes a storage medium and a processor; the storage medium stores a computer program; the processor executes the computer program to implement the above-described virtual device. Figure 1 and Figure 2 The method shown.

[0115] Optionally, the aforementioned physical devices may also include a user interface, a network interface, a camera, radio frequency (RF) circuitry, sensors, audio circuitry, a Wi-Fi module, etc. The user interface may include a display screen, input units such as a keyboard, etc., and optional user interfaces may also include USB interfaces, card reader interfaces, etc. The network interface may optionally include standard wired interfaces, wireless interfaces (such as Wi-Fi interfaces), etc.

[0116] Those skilled in the art will understand that the physical device structure provided in this embodiment does not constitute a limitation on the physical device, and may include more or fewer components, or combine certain components, or have different component arrangements.

[0117] The storage medium may also include an operating system and a network communication module. The operating system is a program that manages the hardware and software resources of the aforementioned physical device, supporting the operation of information processing programs and other software and / or programs. The network communication module is used to enable communication between the various components within the storage medium, as well as communication with other hardware and software in the information processing physical device.

[0118] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented using software plus necessary general-purpose hardware platforms, or it can be implemented using hardware. Compared with existing technologies, this embodiment achieves more refined and intelligent dynamic management of cloud platform resources, significantly improving resource utilization and service quality. Firstly, resource monitoring and demand modeling are performed at the microservice component level, combined with neural networks for high-precision prediction of resource demands, overcoming the lag and coarse-grained problems of traditional static reservation or simple threshold triggering mechanisms. Furthermore, by introducing a consistent hashing algorithm to optimize load balancing and resource routing, stable service for high-priority businesses in dedicated resource pools is ensured. Simultaneously, elastic resource pools and hierarchical mechanisms enable rapid resource expansion and on-demand reclamation, enhancing the system's flexibility and responsiveness to sudden traffic surges. By constructing a closed-loop management system covering initial reservation, dynamic prediction, priority reallocation, anomaly handling, renewal upon expiration, and resource release, this approach possesses stronger systematicity and engineering feasibility compared to existing solutions that only focus on specific aspects. It has significant improvements in technological advancement, resource scheduling efficiency, business assurance capabilities, and cost control. It is particularly suitable for resource management needs in large-scale microservice architectures and hybrid cloud environments, and has good industrialization prospects and market competitiveness.

[0119] It should be noted that, in this document, relational terms such as "first" and "second" are used merely 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 apparatus 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 apparatus. 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 apparatus that includes said element.

[0120] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments described herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A resource configuration method, characterized by, The method comprises the following steps: acquiring a microservice topology of a business system deployed on a cloud platform; matching the microservice topology with resource requirements of each microservice component in the business system to determine static reservation amounts of cloud platform resources corresponding to the business system in each reserved time period; predicting, based on a resource dynamic characteristic model corresponding to the business system, an amount of cloud platform resources required by the business system in a future preset time period; if the amount of cloud platform resources required by the business system exceeds the static reservation amount in the corresponding reserved time period, re-allocating the cloud platform resources corresponding to the business system according to business priorities.

2. The method of claim 1, wherein, The matching of the microservice topology with the resource requirements of each microservice component in the business system to determine the static reservation amounts of the cloud platform resources corresponding to the business system in each reserved time period comprises the following steps: based on a preset business model library, matching the microservice topology of the business system to obtain corresponding resource requirement parameters; based on a linear programming method, combining performance parameters, resource requirement parameters, business priorities and elastic expansion capabilities of each microservice component to calculate an initial resource reservation amount corresponding to the business system; optimizing and solving the initial resource reservation amount of each time period by using a multi-objective optimization algorithm to determine the static reservation amounts of the cloud platform resources corresponding to the business system in each reserved time period.

3. The method of claim 2, wherein, The optimization and solving of the initial resource reservation amount of each time period by using a multi-objective optimization algorithm to determine the static reservation amounts of the cloud platform resources corresponding to the business system in each reserved time period comprises the following steps: processing historical business load data by using a time series analysis method to identify time distribution characteristics of resource requirements of the business system; based on the time distribution characteristics of resource requirements of the business system, performing multi-objective optimization on the initial resource reservation amount by using a genetic algorithm to obtain the static reservation amounts of the cloud platform resources corresponding to the business system in each reserved time period.

4. The method of claim 1, wherein, The prediction of the amount of cloud platform resources required by the business system in a future preset time period based on the resource dynamic characteristic model corresponding to the business system comprises the following steps: based on the resource dynamic characteristic model, constructing a historical resource time series data set corresponding to the business system, the historical resource time series data set comprising one or more of historical central processing unit usage rates, historical memory usage rates, historical storage input / output operation frequencies, historical storage throughputs and historical network bandwidth data; inputting the historical resource time series data set into a long short-term memory neural network to predict the amount of cloud resources required by the business system in the future preset time period and generate a resource requirement prediction result sequence of the business system.

5. The method of claim 1, wherein, The training process of the resource dynamic characteristic model comprises the following steps: acquiring resource usage time series data of the business system at a microservice component granularity, the resource usage time series data comprising one or more of central processing unit usage rates, memory usage rates, storage input / output operation frequencies, storage throughputs and network bandwidth data; performing normalization processing and smoothing processing on the resource time series data; The processed resource time series data is subjected to cluster analysis by a data analysis engine to generate a resource dynamic characteristic model corresponding to the business system.

6. The method of claim 1, wherein, The cloud platform resources corresponding to the business system are re-allocated according to the business priority, including: The business requests of the business system are divided into first-priority business requests and second-priority business requests based on the business priority, and the business priority of the first-priority business requests is higher than that of the second-priority business requests; The first-priority business requests are preferentially allocated to the exclusive resource pool of the cloud platform for processing by a consistent hash load balancing algorithm, and the second-priority business requests are allocated to the shared resource pool of the cloud platform for processing.

7. The method of claim 1, wherein, The method further includes: If the cloud platform cannot meet the resource emergency expansion demand, the resource configuration information of the business system and the resource specifications and service options of candidate cloud platforms are obtained; Based on the resource specifications and service options of the candidate cloud platforms, it is determined whether the candidate cloud platforms can meet the resource demand of the business system, and the cloud platform that meets the resource demand of the business system is determined as a to-be-migrated cloud platform; The resource configuration information of the current business system is input into a migration adaptation degree scoring model to calculate the adaptation degree scores of each to-be-migrated cloud platform, and the migration adaptation degree scoring model is used to evaluate the resource specification and performance difference between the cloud platform where the business system is located and the to-be-migrated cloud platform; The to-be-migrated cloud platform with an adaptation degree score higher than a preset adaptation degree threshold is determined as a target cloud platform, and the business system is migrated to the target cloud platform based on the corresponding target migration path.

8. The method of claim 1, wherein, The method further includes: In the case where the traffic data of the business system is monitored to be higher than a preset traffic dynamic threshold and the cloud platform cannot meet the resource elastic expansion condition, the corresponding cloud host and cloud disk resources are obtained from a pre-configured elastic resource pool according to the resource demand of the cloud platform; Based on the cloud host and cloud disk resources, resource expansion configuration is performed according to the resource use permission of the business system; After monitoring that the traffic data of the business system is lower than or equal to the preset traffic dynamic threshold, the newly added resources used for resource expansion configuration are automatically released according to a reserved resource recycling mechanism.

9. The method of claim 8, wherein, The method further includes: Based on the historical business peak data and future business growth prediction of the business system, a multi-objective linear programming algorithm is used to dynamically plan the total capacity of the elastic resource pool, and an elastic resource hierarchical operation and maintenance service level mechanism is established based on the elastic resource pool capacity planning result.

10. A resource configuration apparatus, characterized by comprising: It includes: An acquisition module configured to acquire a microservice topology of a business system deployed on a cloud platform; A matching module configured to match the microservice topology with resource demands of each microservice component in the business system to determine a static reservation amount of the cloud platform resources corresponding to the business system in each reserved time period; A prediction module configured to predict cloud platform resource demand of the business system in a future preset time period based on a resource dynamic characteristic model corresponding to the business system using a long short-term memory neural network; A configuration module is configured to reallocate the cloud platform resources corresponding to the business system according to the business priority if the cloud platform resource demand exceeds the static reservation amount within the corresponding reservation period.

11. A computer readable storage medium having stored thereon a computer program, characterized in that The computer program, when executed by a processor, implements the method of any one of claims 1 to 9.

12. An electronic device comprising a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, characterized in that, The processor implements the method of any one of claims 1 to 9 when executing the computer program.

13. A computer program product having stored thereon a computer program, the computer program comprising: computer readable program means for causing a computer to perform the steps of the method according to any one of claims 1 to 12. The computer program product, when executed by a processor, implements the method of any one of claims 1 to 9. The computer program product, when executed by a processor, implements the method of any one of claims 1 to 9.

Images