Heterogeneous terminal adaptive virtualization cloud platform based on intelligent load balancing

Abstract

The present application relates to the technical field of virtual cloud platform scheduling, in particular to a heterogeneous terminal adaptive virtual cloud platform based on intelligent load balancing, which comprises a terminal evaluation module, a resource matching module, a fragmentation optimization module, a scheduling execution module and a model updating module. The terminal evaluation module forms a terminal capability distribution table through a preset model, the resource matching module matches candidate terminals according to virtual instance labels and generates an initial allocation scheme, the fragmentation optimization module completes fragmentation merging by exchanging virtual instance attribution, thereby reducing the average resource fragmentation rate, the scheduling execution module issues virtual machine creation instructions and collects real-time performance data, and the model updating module dynamically adjusts the computing power weight coefficient according to the monitoring data to update the terminal capability distribution table. The platform can integrate terminal discrete resources, reduce resource fragmentation, make terminal capability evaluation conform to the actual running state, and improve the adaptability of heterogeneous terminal cluster virtual resource scheduling.

Description

Technical Field

[0001] This invention relates to the field of virtualization cloud platform scheduling technology, and in particular to a heterogeneous terminal adaptive virtualization cloud platform based on intelligent load balancing. Background Technology

[0002] Existing heterogeneous terminal virtualization cloud platforms often match resource allocation based on terminal load rates, deploying virtual instances to terminals with lower loads. Resource fragmentation is often handled by migrating individual instances to fill local gaps, without systematically quantifying the impact of fragmentation on resource utilization. Terminal capability assessment relies heavily on static configuration parameters or periodic offline testing, with fixed model weights that fail to reflect the dynamic performance of terminals in real business scenarios. This results in significant discrepancies between the capability distribution table and actual capabilities, affecting the accuracy of resource matching.

[0003] Existing technical solutions have shortcomings: fragmentation only focuses on local adjustments, lacks a quantitative indicator of fragmentation rate, and lacks a global optimization mechanism for cross-terminal virtual instance ownership exchange, making it difficult to effectively reduce overall resource fragmentation; the terminal capability assessment model is static and cannot dynamically adjust assessment parameters based on real-time performance data during virtual instance runtime, leading to inaccurate candidate terminal set selection and insufficient rationality of the initial resource allocation scheme. This invention aims to address the problems of existing fragmentation processing failing to quantify fragmentation rate and lacking exchange optimization, as well as the inaccurate matching caused by the static terminal assessment model, by improving resource allocation efficiency and platform adaptability through targeted technologies. Summary of the Invention

[0004] The purpose of this invention is to address the shortcomings of existing technologies by proposing a heterogeneous terminal adaptive virtualization cloud platform based on intelligent load balancing.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: a heterogeneous terminal adaptive virtualization cloud platform based on intelligent load balancing, comprising:

[0006] The terminal assessment module generates a terminal capability distribution table using a pre-set terminal capability assessment model.

[0007] The resource matching module matches a set of candidate terminals that meet resource constraints in the terminal capability distribution table based on the type tags of the virtual instances to be deployed in the business request queue, and generates an initial resource allocation scheme based on the current load rate.

[0008] The fragmentation optimization module binds each virtual instance in the initial resource allocation scheme to the corresponding candidate terminal. During the binding process, a resource fragmentation rate is calculated for the binding relationship between each group of virtual instances and candidate terminals to obtain a resource allocation result set containing several binding relationships and their resource fragmentation rates. The fragmentation merging operation is performed on the resource allocation result set. The fragmentation merging operation reduces the average resource fragmentation rate of the resource allocation result set by swapping the ownership of virtual instances on different terminals, and generates an optimized resource allocation result set.

[0009] The scheduling and execution module transforms the optimized resource allocation result set into virtual machine creation instructions for each terminal device, executes the virtual machine creation instructions in the heterogeneous terminal cluster, starts the corresponding virtual instances, and collects real-time performance monitoring data of each virtual instance during operation.

[0010] The model update module dynamically adjusts the computing power weight coefficient in the terminal capability assessment model based on real-time performance monitoring data to update the terminal capability distribution table.

[0011] As a further aspect of the present invention, the step of forming a terminal capability distribution table through a pre-set terminal capability assessment model includes:

[0012] Obtain hardware resource snapshots of each terminal device in the heterogeneous terminal cluster. The hardware resource snapshots include processor computing power margin, available memory space, storage read / write speed, and network bandwidth utilization.

[0013] Multi-dimensional resource feature extraction is performed on the hardware resource snapshot. The extracted multi-dimensional resource features are input into a pre-set terminal capability evaluation model to obtain the upper limit of the number of virtual instances that each terminal device can support, thereby forming a terminal capability distribution table, specifically including:

[0014] Normalize the processor computing power margin, available memory space, storage read and write speed and network bandwidth utilization in the hardware resource snapshot to eliminate numerical differences between different units.

[0015] The normalized resource indicators are mapped to the feature vector dimensions in the terminal capability assessment model, where the processor computing power margin corresponds to the computing density feature, the available memory space corresponds to the concurrency support feature, the storage read and write rate corresponds to the data throughput feature, and the network bandwidth utilization rate corresponds to the communication latency feature.

[0016] The feature vector is input into the terminal capability assessment model, which is trained using historical operating data, and is used to output the upper limit of the number of virtual instances that each terminal device can stably support in the current state.

[0017] By summarizing the device identifiers of all terminal devices, the calculated upper limit of the number of virtual instances that can be supported, and the corresponding feature vectors, a terminal capability distribution table is generated.

[0018] As a further aspect of the present invention, the step of matching a set of candidate terminals that meet resource constraints in the terminal capability distribution table based on the type tags of the virtual instances to be deployed in the service request queue, and generating an initial resource allocation scheme based on the current load rate, includes:

[0019] The type tag of each virtual instance to be deployed in the business request queue is parsed. The type tag defines the minimum processor computing power, minimum memory capacity and minimum storage bandwidth required by the virtual instance.

[0020] Traverse the terminal capability distribution table, filter out terminal devices that meet the resource requirements of the virtual instance to be deployed, and form a candidate terminal set;

[0021] Calculate the current load rate of each terminal device in the candidate terminal set, where the current load rate is the ratio of allocated resources to the upper limit of bearable resources;

[0022] The candidate terminal set is sorted in ascending order of current load rate, and the virtual instances to be deployed are allocated to the terminal devices ranked first in the sorting, until all virtual instances to be deployed have been allocated, thus forming the initial resource allocation scheme.

[0023] As a further aspect of the present invention, the step of binding each virtual instance in the initial resource allocation scheme with its corresponding candidate terminal involves calculating a resource fragmentation rate for each group of virtual instances and candidate terminals during the binding process, thereby obtaining a resource allocation result set containing several binding relationships and their resource fragmentation rates, including:

[0024] For each group of virtual instances and candidate terminals in the initial resource allocation scheme, extract a snapshot of the remaining hardware resources of the candidate terminals after binding.

[0025] Based on the processor computing power margin, available memory space, storage read / write speed, and network bandwidth utilization rate in the remaining hardware resource snapshot, the dispersion of the remaining resources is calculated as the resource fragmentation rate of the binding relationship.

[0026] The unique identifier of the virtual instance, the identifier of the bound terminal, and the corresponding resource fragmentation rate are associated and stored to form a resource allocation result set.

[0027] As a further aspect of the present invention, the fragmentation merging operation on the resource allocation result set, wherein the fragmentation merging operation reduces the average resource fragmentation rate of the resource allocation result set by exchanging the virtual instance affiliation on different terminals, and generates an optimized resource allocation result set, includes:

[0028] Calculate the average resource fragmentation rate across all binding relationships in the resource allocation result set;

[0029] Iterate through any two binding relationships in the resource allocation result set, attempt to swap the terminal affiliation of the virtual instances in these two binding relationships, and generate a new temporary resource allocation result set;

[0030] Calculate the average resource fragmentation rate of the new temporary resource allocation result set. If the new average resource fragmentation rate is lower than the original average resource fragmentation rate, accept the exchange and update the resource allocation result set.

[0031] Repeat the swapping and comparison process until multiple consecutive swaps fail to further reduce the average resource fragmentation rate, and output the optimized resource allocation result set.

[0032] As a further aspect of the present invention, the step of converting the optimized resource allocation result set into virtual machine creation instructions for each terminal device includes:

[0033] The virtual machine creation instruction includes the resource configuration parameters and scheduling priority of the virtual instance;

[0034] Parse each binding relationship in the optimized resource allocation result set to obtain the type tag of the virtual instance and the terminal identifier it is bound to;

[0035] Based on the type label of the virtual instance, determine the number of virtual processor cores, virtual memory size, and virtual disk space required by the virtual instance as resource configuration parameters;

[0036] Based on the current load rate of the terminal devices described in the terminal capability distribution table, set the scheduling priority of the virtual instance. The lower the load rate, the higher the scheduling priority.

[0037] Resource configuration parameters and scheduling priorities are encapsulated into virtual machine creation instructions and archived according to terminal identifiers.

[0038] As a further aspect of the present invention, the step of executing virtual machine creation instructions in a heterogeneous terminal cluster, starting corresponding virtual instances, and collecting real-time performance monitoring data of each virtual instance during operation includes:

[0039] Based on the terminal identifier in the virtual machine creation instruction, the corresponding virtual machine creation instruction is sent to the specified terminal device;

[0040] On the terminal device side, a virtual machine instance is created according to the virtual machine creation instructions, the operating system image and application dependencies are loaded, and the virtual instance is started.

[0041] The agent program installed inside the virtual instance periodically collects the virtual instance's CPU usage, memory usage, disk I / O latency, and network packet round-trip time as real-time performance monitoring data.

[0042] The collected real-time performance monitoring data is transmitted back to the monitoring center of the cloud platform for unified storage.

[0043] As a further aspect of the present invention, the step of dynamically adjusting the computing power weight coefficient in the terminal capability assessment model based on real-time performance monitoring data to update the terminal capability distribution table includes:

[0044] Perform statistical analysis on real-time performance monitoring data to calculate the average value of processor computing power, memory capacity and storage bandwidth actually used by each virtual instance during operation;

[0045] The calculated average actual resource usage is compared with the theoretical resource requirements preset in the terminal capability assessment model to obtain the deviation value of each resource dimension.

[0046] Based on the magnitude of the deviation, the weight coefficients corresponding to processor computing power margin, available memory space, storage read and write speed and network bandwidth utilization in the terminal capability assessment model are adjusted proportionally, and the weights of resource dimensions with large deviations are increased.

[0047] The terminal capability assessment model is rerun using the adjusted weighting coefficients to reassess all terminal devices in the heterogeneous terminal cluster, generating an updated terminal capability distribution table.

[0048] As a further aspect of the present invention, the platform also includes:

[0049] The fault self-healing module sets a keep-alive detection timer for the binding relationship between each group of virtual instances and candidate terminals in the initial resource allocation scheme;

[0050] During the keep-alive detection timer period, a heartbeat probe message is sent to the virtual instance, and the virtual instance is waited for a response.

[0051] If no response is received from the virtual instance within the preset timeout period, the virtual instance is determined to be in a disconnected state, and the virtual instance is returned to the head of the business request queue.

[0052] Trigger a new resource allocation process to reallocate terminal devices to the disconnected virtual instance, enabling rapid migration and recovery of the abnormal instance;

[0053] The platform also includes:

[0054] The source-oriented scheduling module divides the terminals in the updated terminal capability distribution table into high-capacity terminal groups and low-capacity terminal groups according to the maximum number of virtual instances they can support.

[0055] For virtual instances in the business request queue that are computationally intensive and not sensitive to communication latency, priority should be given to allocating them in the high-capacity terminal group;

[0056] For virtual instances in the business request queue that are communication-intensive and have low computing resource requirements, priority should be given to allocating them in low-capacity terminal groups.

[0057] This group-oriented allocation strategy reduces resource competition between different types of virtual instances, forming a resource scheduling mechanism that adapts to different categories.

[0058] As a further aspect of the present invention, the construction of the terminal capability assessment model includes:

[0059] Collect performance monitoring datasets of various terminal devices in a heterogeneous terminal cluster when running multiple virtual instances within a historical period. The performance monitoring datasets include terminal hardware resource utilization, actual resource consumption of virtual instances, and virtual instance running stability indicators.

[0060] Data cleaning and feature engineering are performed on the performance monitoring dataset to extract a multi-dimensional feature set related to the virtual instance carrying capacity. The multi-dimensional feature set includes processor computing power dynamic margin, memory space fragmentation rate, storage input / output concurrent load and network bandwidth fluctuation rate.

[0061] A neural network model structure containing an input layer, multiple hidden layers, and an output layer is constructed. The multidimensional feature set is used as the input features of the model, and the upper limit of the number of virtual instances that the terminal can stably support is used as the training label of the model.

[0062] The neural network model is iteratively trained using the gradient descent algorithm. The internal parameters of the model are optimized by minimizing the loss function between the upper limit of the number of virtual instances predicted by the model and the actual observed number of stable bearers.

[0063] After the model training is completed, the generalization performance of the model is evaluated by cross-validation set, and the model parameters that meet the preset threshold are saved to form the terminal capability evaluation model.

[0064] Compared with the prior art, the advantages and positive effects of the present invention are as follows:

[0065] In the fragmentation optimization stage, the resource fragmentation rate is calculated for each "virtual instance-terminal" binding relationship in the initial resource allocation scheme, forming a resource allocation result set containing the binding relationship and fragmentation rate. By swapping the ownership of bound virtual instances on different candidate terminals, the fragmentation rate of each group after the swap is recalculated. The swapping method that reduces the average resource fragmentation rate is selected to complete the merging, generating an optimized result set. This technology quantifies fragmentation into a comparable indicator, replaces single-point migration with cross-terminal instance swapping, breaks the limitations of local fragmentation, makes the remaining resources of the terminal more concentrated and usable, reduces resource idleness caused by fragmentation, and improves the overall resource utilization rate.

[0066] During the model update phase, the scheduling and execution module collects real-time performance monitoring data from the virtual instance's operation. Based on this data, the model update module dynamically adjusts the computing power weight coefficients of the terminal capability assessment model. When the actual computing power output of the terminal continuously deviates from the model prediction, the corresponding weights are increased or decreased, and the terminal's comprehensive capability score is recalculated and the distribution table is updated according to the adjusted weights. This technology establishes a closed-loop feedback between real-time performance and the assessment model, enabling the capability distribution table to dynamically align with the actual terminal status. This allows subsequent resource matching to generate initial solutions based on a more accurate set of candidate terminals, reducing uneven load distribution or resource waste caused by assessment bias. Attached Figure Description

[0067] Figure 1 This is a timing diagram of the heterogeneous terminal adaptive virtualization cloud platform based on intelligent load balancing described in this invention.

[0068] Figure 2 A flowchart of the process for generating the initial resource allocation scheme;

[0069] Figure 3 Create a flowchart of the instruction generation process for the virtual machine;

[0070] Figure 4 Box plot of disk I / O wait time distribution for multiple virtual instances;

[0071] Figure 5 This provides time-series monitoring curves for multi-dimensional performance metrics of virtual instances. Detailed Implementation

[0072] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0073] In the description of this invention, it should be understood that the terms "length," "width," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientation or positional relationships, are based on the orientation or positional relationships shown in the accompanying drawings and are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, in the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0074] See Figure 1 The terminal evaluation module uses a pre-built terminal capability evaluation model to quantitatively evaluate the hardware capabilities of all terminal devices in the heterogeneous terminal cluster, generating a detailed terminal capability distribution table. The resource matching module receives the service request queue, parses the resource requirements defined by the type tags of the virtual instances to be deployed, and filters out a set of candidate terminals that meet these resource constraints from the terminal capability distribution table. Based on the current load rate of each terminal device in the candidate terminal set, this module generates a preliminary resource allocation scheme, i.e., the initial resource allocation scheme. The fragmentation optimization module receives this initial resource allocation scheme, calculates a resource fragmentation rate for each group of virtual instances and terminal devices, thus obtaining a resource allocation result set containing all binding relationships and their resource fragmentation rates. This module performs a fragmentation merging operation on the resource allocation result set, reducing the average resource fragmentation rate of the entire result set by attempting to swap the ownership of virtual instances on different terminal devices, and outputs an optimized resource allocation result set. The scheduling and execution module is responsible for converting the optimized resource allocation result set into executable instructions. Based on the result set, it generates virtual machine creation instructions for each specific terminal device and distributes these instructions to the heterogeneous terminal cluster for execution, thereby launching the corresponding virtual instances. This module also collects real-time performance monitoring data generated by each virtual instance during operation. The model update module, based on the real-time performance monitoring data fed back by the scheduling and execution module, dynamically adjusts the key parameters within the terminal capability assessment model, especially the computing power weight coefficients of various resource indicators, to update the terminal capability distribution table. This ensures that the resource assessment and matching of the entire platform can adapt to changes in actual operating conditions.

[0075] In one embodiment of the present invention, the formation of the terminal capability distribution table begins with obtaining hardware resource snapshots of each terminal device in a heterogeneous terminal cluster. A hardware resource snapshot is a data set recording the resource status of a terminal device at a specific point in time, including processor computing power margin, available memory space, storage read / write speed, and network bandwidth utilization. For example, a hardware resource snapshot might record that terminal device A has a processor computing power margin of 70 gigahertz, available memory space of 8 gigabytes, a storage read / write speed of 300 megabytes per second, and a network bandwidth utilization of 20%. Multi-dimensional resource feature extraction is performed on the hardware resource snapshot. This extraction process must normalize the processor computing power margin, available memory space, storage read / write speed, and network bandwidth utilization in the hardware resource snapshot to eliminate numerical differences caused by different units of measurement in subsequent evaluations. In a specific example, the processor computing power margin of all terminal devices is normalized using a maximum-minimum value, mapping the original values ​​to the range of 0 to 1. It is understood that normalization can employ various mathematical methods; one implementation uses a linear normalization formula expressed as: ;

[0076] Where: symbol Represents the normalized resource indicator value, symbol Represents the raw resource metric value read from the hardware resource snapshot, symbol Represents the minimum value of this resource indicator across all terminal devices, with the symbol... This represents the maximum value of this resource indicator across all terminal devices. Through this calculation, processor computing power margin, available memory space, storage read / write speed, and network bandwidth utilization are converted into dimensionless values.

[0077] In some embodiments, the normalized resource indicators are mapped to feature vector dimensions in the terminal capability assessment model. The normalized processor computing power margin corresponds to the computational density feature, the normalized available memory space corresponds to the concurrency support feature, the normalized storage read / write rate corresponds to the data throughput feature, and the normalized network bandwidth utilization corresponds to the communication latency feature. These four dimensions together constitute a four-dimensional feature vector to characterize the comprehensive resource status of a single terminal device. In a specific implementation, the feature vector is input into the terminal capability assessment model, which is trained by analyzing historical operating data. This model outputs the upper limit of the number of virtual instances that each terminal device can stably support under the current state described by the four-dimensional feature vector. For example, for a terminal device with a feature vector of [0.8, 0.6, 0.9, 0.2], the terminal capability assessment model might output that its upper limit for the number of virtual instances it can support is 5. Optionally, after obtaining the evaluation results of all terminal devices, the device identifiers of all terminal devices, the upper limit of the number of virtual instances that can be supported calculated by the terminal capability evaluation model, and the input feature vector corresponding to the generation of the upper limit of the number are summarized to generate a terminal capability distribution table in the form of a structured data table.

[0078] The construction of the terminal capability assessment model is an independent and crucial preliminary process. In some embodiments, building the terminal capability assessment model requires collecting performance monitoring datasets of various terminal devices in a heterogeneous terminal cluster running multiple virtual instances over a historical period. These performance monitoring datasets include terminal hardware resource utilization, actual resource consumption of virtual instances, and virtual instance operational stability indicators. Data cleaning and feature engineering are performed on the performance monitoring datasets to extract a multi-dimensional feature set related to virtual instance carrying capacity. This multi-dimensional feature set includes processor computing power dynamic margin, memory fragmentation rate, storage input / output concurrent load, and network bandwidth volatility. A neural network model structure containing an input layer, multiple hidden layers, and an output layer is constructed. The multi-dimensional feature set is used as the input features of the neural network model structure, and the upper limit of the number of virtual instances stably carried by the terminal is used as the training label of the neural network model structure. In specific implementations, a gradient descent algorithm is used to iteratively train the neural network model structure. By minimizing the loss function between the upper limit of the number of virtual instances predicted by the neural network model structure and the actual observed stable carrying capacity, the internal parameters of the neural network model structure are optimized. Each iteration adjusts the parameters to make the prediction closer to the true value. Optionally, after the neural network model structure is trained, the generalization performance of the neural network model structure is evaluated through an independent cross-validation set, that is, the prediction accuracy of the neural network model structure on new terminal device data that has not participated in the training is evaluated, the parameters of the neural network model structure that meet the preset prediction accuracy threshold are saved, and finally a terminal capability evaluation model for online evaluation is formed.

[0079] In one embodiment of the present invention, the resource matching module generates an initial resource allocation scheme based on the type tags of the virtual instances to be deployed in the service request queue, see below. Figure 2 The resource matching module first parses the type tag of each virtual instance to be deployed in the business request queue. The type tag explicitly defines the minimum processor computing power, minimum memory capacity, and minimum storage bandwidth required for the virtual instance to run. For example, the type tag of a compute-intensive virtual instance may define its minimum processor computing power as 2 gigahertz, minimum memory capacity as 4 gigabytes, and minimum storage bandwidth as 100 megabytes per second. It then traverses the terminal capability distribution table, which records the resource capacity and the maximum number of virtual instances each terminal device can support. The resource matching module filters out terminal devices from the terminal capability distribution table that meet all the above resource requirements, forming a candidate terminal set. Assuming there are five terminal devices in the terminal capability distribution table, and terminal devices A, C, and E meet all the resource requirements of the virtual instance, then the candidate terminal set includes terminal devices A, C, and E.

[0080] In some embodiments, the current load rate of each terminal device in the candidate terminal set is calculated. The current load rate is defined as the ratio of the total resources occupied by the allocated virtual instances on the terminal device to the total resources corresponding to the upper limit of the number of virtual instances that the terminal device can support. It can be understood that the ratio of allocated resources to the upper limit of supportable resources can be represented by specific numerical values. For example, if terminal device A has an upper limit of 10 virtual instances and is currently running 4 virtual instances, then terminal device A's current load rate is 0.4; if terminal device C has an upper limit of 8 virtual instances and is currently running 6 virtual instances, then terminal device C's current load rate is 0.75. The candidate terminal set is sorted in ascending order of current load rate, and the sorted candidate terminal set order is terminal device A, terminal device E, and terminal device C. The resource matching module sequentially allocates the virtual instances to be deployed in the business request queue to the terminal devices with the highest sorting order. Assuming there are two virtual instances to be deployed in the business request queue, virtual instance one is first allocated to terminal device A with the lowest current load rate, and virtual instance two is allocated to the next terminal device E with a low load rate, until all virtual instances to be deployed are allocated, thus forming an initial resource allocation scheme containing specific binding relationships.

[0081] After the initial resource allocation scheme is generated, the fragmentation optimization module begins to work, calculating the resource fragmentation rate for each group of virtual instances and terminal devices bound in the initial resource allocation scheme. In specific implementation, for each group of binding relationships in the initial resource allocation scheme, a snapshot of the remaining hardware resources of the terminal device after binding the virtual instance is extracted. The remaining hardware resource snapshot includes the remaining processor computing power margin, available memory space, storage read / write speed, and network bandwidth utilization rate after binding. For example, for the binding relationship between virtual instance one and terminal device A, the extracted remaining processor computing power margin of terminal device A after binding is 15 gigahertz, the remaining available memory space is 2 gigabytes, the remaining storage read / write speed is 150 megabytes per second, and the remaining network bandwidth utilization rate corresponds to 70% of the idle bandwidth. Based on the processor computing power margin, available memory space, storage read / write speed, and network bandwidth utilization rate in the remaining hardware resource snapshot, the dispersion of these remaining resources is calculated, and the dispersion value is used as the resource fragmentation rate of the binding relationship. One formula for calculating the dispersion of remaining resources is as follows:

[0082] ;

[0083] Where: symbol Represents the calculated resource fragmentation rate, with the symbol... This represents the number of different types of remaining hardware resources in this scenario. These correspond to four types of resources: processor, memory, storage, and network. Representing the The normalized value of the remaining resources of the class, with the following symbol. Representing all The formula calculates the standard deviation of the four types of remaining resource values ​​relative to their average value. A larger standard deviation indicates a more uneven distribution and higher degree of fragmentation of the remaining resources. Optionally, the unique identifier of the virtual instance, the identifier of the terminal device bound to the virtual instance, and the calculated resource fragmentation rate are associated and stored to form a record. All records with binding relationships are collected together to form a resource allocation result set. The resource allocation result set is a data collection containing multiple records, each of which contains at least three fields: virtual instance ID, terminal device ID, and resource fragmentation rate.

[0084] In some embodiments, the calculation of resource fragmentation rate relies on an accurate snapshot of remaining resources, which is an estimated state obtained by simulating the deduction of resource requirements after the virtual instance is deployed to the terminal device. Optionally, when calculating the resource fragmentation rate, the fragmentation optimization module pre-sets a weight coefficient for each type of resource to reflect the importance of different resources in the fragmentation assessment, but the core calculation logic still revolves around the dispersion of the remaining resource values. The final generated resource allocation result set fully describes the resource fragmentation status of each group of binding relationships under the initial allocation scheme, providing clear input data and optimization objectives for the next fragmentation merging operation.

[0085] In one embodiment of the present invention, the fragmentation optimization module performs a fragmentation merging operation on the resource allocation result set. This merging operation aims to reduce resource fragmentation by adjusting the deployment location of virtual instances. The average resource fragmentation rate of all binding relationships in the resource allocation result set is calculated. This average fragmentation rate reflects the overall level of resource fragmentation under the current allocation scheme, and its calculation can be based on the resource fragmentation rate value contained in each record in the resource allocation result set. See also... Figure 3 The optimization process iterates through any two binding relationships in the resource allocation result set, attempting to swap the terminal affiliation of virtual instances within these two binding relationships. Specifically, it envisions deploying virtual instances from binding relationship Alpha to the terminal device of binding relationship Beta, and vice versa. This swap generates a new, temporary resource allocation result set. The average resource fragmentation rate of the new temporary resource allocation result set is calculated. If the new average resource fragmentation rate is lower than the original average resource fragmentation rate before the swap, the swap operation is accepted, and the original resource allocation result set is updated with the new binding relationship. This swapping and comparison process is repeated until multiple consecutive swaps fail to further reduce the average resource fragmentation rate (e.g., one hundred consecutive swaps fail to produce a lower average resource fragmentation rate). At this point, the optimization process terminates, and the final optimized resource allocation result set is output. The average resource fragmentation rate in the optimized resource allocation result set is lower than the initial state.

[0086] In some embodiments, the average resource fragmentation rate of the resource allocation result set is used as the basis for evaluation and comparison. The formula for calculating the average resource fragmentation rate can be expressed as:

[0087] ;

[0088] Where: symbol The average resource fragmentation rate represents the resource allocation result set, with the symbol... The symbol represents the total number of binding relationships in the resource allocation result set. This represents the resource fragmentation rate corresponding to the k-th binding relationship in the resource allocation result set. Traversal and exchange operations are the core of fragment merging. The fragmentation optimization module systematically scans the resource allocation result set, for example, starting with the first binding relationship and sequentially attempting to exchange it pairwise with the second, third, and so on, up to the last binding relationship. It can be understood that after each exchange attempt, it is necessary to simulate and calculate the remaining resource status of the two terminal devices after receiving the new virtual instance, and recalculate the resource fragmentation rate of the corresponding binding relationship between the two terminal devices, thus obtaining the average resource fragmentation rate of the temporary resource allocation result set. Optionally, the judgment condition for accepting an exchange is strict: the result set is only updated if the new average resource fragmentation rate is clearly lower than the original average resource fragmentation rate. If the new average resource fragmentation rate is equal to or higher than the original value, the exchange is abandoned, and the original binding relationship remains unchanged.

[0089] The scheduling and execution module transforms the optimized resource allocation result set into virtual machine creation instructions for each terminal device. In practice, the virtual machine creation instruction includes the resource configuration parameters and scheduling priority of the virtual instance. Each binding relationship in the optimized resource allocation result set is parsed to obtain the unique type label of the virtual instance and the identifier of the bound terminal device. For example, from a binding relationship, the type label of the virtual instance is parsed as "Compute C2" and the terminal device identifier is "Host-05". Based on the type label of the virtual instance, the number of virtual processor cores, virtual memory size, and virtual disk space required for the virtual instance to run are determined. These parameters together serve as the resource configuration parameters in the virtual machine creation instruction. For example, the type label "Compute C2" corresponds to 2 virtual processor cores, 4 gigabytes of virtual memory, and 50 gigabytes of virtual disk space. Based on the current load rate of the terminal devices in the terminal capability distribution table, the scheduling priority of virtual instances is set. The lower the current load rate of the terminal devices in the terminal capability distribution table, the higher the scheduling priority of the virtual instances allocated to that terminal device is set. For example, the scheduling priority of virtual instances on terminal devices with a current load rate of 0.2 is set to "high", while the scheduling priority of virtual instances on terminal devices with a current load rate of 0.7 is set to "medium". The determined resource configuration parameters and the set scheduling priorities are encapsulated into complete virtual machine creation instructions, and all virtual machine creation instructions are classified and archived according to the terminal device identifier. For example, all virtual machine creation instructions that need to be issued to terminal device "Host-05" are grouped into the same instruction list for easy batch issuance and execution later.

[0090] In one embodiment of the present invention, the scheduling execution module executes virtual machine creation instructions and starts corresponding virtual instances in a heterogeneous terminal cluster. Based on the terminal device identifier encapsulated in the virtual machine creation instruction, the module sends the corresponding virtual machine creation instruction to the designated terminal device. For example, a virtual machine creation instruction containing the terminal identifier "Node-A" is sent to the server node corresponding to the physical address via a network protocol. On the terminal device side, the local virtualization program on the node creates the corresponding virtual machine instance according to the received virtual machine creation instruction, loads the operating system image and application dependencies specified in the instruction, and finally completes the virtual instance startup process. After the virtual instance starts, an agent program pre-installed inside the virtual instance periodically collects data on CPU usage, memory usage, disk I / O latency, and network packet round-trip time during virtual instance runtime. This collected data is used as real-time performance monitoring data. The agent program sends the collected real-time performance monitoring data back to the cloud platform's monitoring center for unified storage. The monitoring center persistently stores the monitoring data from all virtual instances in the form of a time-series database. For example, the monitoring data reported by a virtual instance four times within five minutes might be as shown in Table 1 below:

[0091] Table 1: Real-time performance monitoring data snippets for virtual instance VM-001

[0092]

[0093] The model update module dynamically adjusts the terminal capability assessment model based on real-time performance monitoring data stored in the monitoring center. In some embodiments, statistical analysis is performed on the real-time performance monitoring data to calculate the average processor computing power, memory capacity, and storage bandwidth actually used by each virtual instance during its complete runtime. For example, for the virtual instances in the table above, their average CPU utilization is 66.575%, their average memory usage is 3.15 gigabytes, and their average disk I / O latency can be converted to represent the actual storage bandwidth usage. It can be understood that calculating the average actual resource usage requires processing all monitoring sample points within a time window. The calculated average actual resource usage is compared with the theoretical resource requirements preset for the corresponding type of virtual instance in the terminal capability assessment model to obtain the deviation value for each resource dimension. For example, if the theoretical processor requirement for a certain type of virtual instance is 60% utilization, while the actual average is 66.575%, then the deviation value for the processor dimension is +6.575 percentage points.

[0094] In practice, the weighting coefficients of processor computing power margin, available memory space, storage read / write speed, and network bandwidth utilization in the terminal capability assessment model are adjusted proportionally based on the magnitude of the deviation. Dimensions with a large deviation between actual utilization and theoretical demand have their weighting coefficients increased. One formula for this weighting adjustment can be expressed as:

[0095] ;

[0096] Where: symbol This represents the amount of adjustment required for the weight coefficient corresponding to the i-th type of resource (such as a processor), denoted by [symbol]. Represents the average actual usage of the i-th type of resource, with the symbol... Represents the theoretical demand value for the i-th type of resource, symbol This represents a preset adjustment coefficient used to control the magnitude of the adjustment. Optionally, the model update module will update the model's internal weights according to this adjustment amount. For example, if the original processor weight is 0.3, the calculated weight will be... If the initial value is 0.02, the new weight is updated to 0.32. The terminal capability assessment model is rerun using the adjusted new weight coefficients to perform a completely new capability assessment on all terminal devices in the heterogeneous terminal cluster. Based on the latest hardware resource snapshot of the terminal devices and the updated weight coefficients, a new upper limit for the number of virtual instances that can be supported is calculated, thereby outputting an updated terminal capability distribution table that is closer to the actual operating state.

[0097] See Figure 4 The box plot visually presents the disk I / O latency (ms) distribution characteristics of the five virtual instances, VM-001 to VM-005. In terms of distribution dispersion, VM-001 has the largest box height and vertical strut span, and significant outliers, indicating the widest fluctuation range of its disk I / O latency and the worst I / O stability during operation. VM-003's box and strut segments shift downwards to around the 10ms range, exhibiting the smallest mean and fluctuation range of disk I / O latency among all instances, demonstrating the best I / O response stability. VM-002, VM-004, and VM-005 fall within the middle distribution range, with VM-002's median slightly lower than VM-004 and VM-005, indicating a slightly better overall I / O latency. From the distribution trend, the median of the box segments for each instance shows a pattern of VM-001 > VM-002 ≈ VM-004 > VM-005 > VM-003, reflecting hierarchical differences in disk I / O resource load performance among different virtual instances. Combined with the resource scheduling logic of the heterogeneous terminal adaptive virtualization cloud platform, this graph can be used to quantitatively evaluate the I / O performance loss of each terminal device after it hosts virtual instances. This provides quantitative data support for instance attribution and switching based on resource fragmentation rate in the fragmentation optimization module, and for adjusting the weight coefficients of the terminal capability evaluation model in the model update module, helping the platform achieve more accurate resource matching and load balancing.

[0098] In one embodiment of the present invention, the fault self-healing module is activated and runs after the resource matching module generates the initial resource allocation scheme. The fault self-healing module sets an independent keep-alive detection timer for each group of virtual instances and terminal devices bound in the initial resource allocation scheme. For example, a keep-alive detection timer with a period of ten seconds is set for the binding relationship "virtual instance VM-01 running on terminal device Host-07". When the period of the keep-alive detection timer expires, the fault self-healing module sends a heartbeat probe message to the corresponding virtual instance and waits for the virtual instance to return a response message. The heartbeat probe message is used to confirm whether the process or service of the virtual instance is in a responsive state. If no response is received from the virtual instance within a preset timeout period, the virtual instance is determined to be in a disconnected state. For example, if no response is received within three consecutive detection cycles, a fault determination is triggered. The fault self-healing module puts the relevant information of the lost virtual instance back to the head of the business request queue to ensure that it can be rescheduled first. Then, it triggers a new and complete resource allocation process, starting with the resource matching module, to find a suitable deployment location for the lost virtual instance among available terminal devices, thereby realizing the rapid migration of abnormal instances and business recovery.

[0099] In some embodiments, the period and preset timeout of the keep-alive detection timer can be configured differently according to the type of virtual instance. For example, for critical business virtual instances, the keep-alive detection timer period is set to five seconds and the timeout is set to two heartbeat cycles; for non-critical business virtual instances, the period can be set to thirty seconds and the timeout is set to three heartbeat cycles. It can be understood that the heartbeat detection message can be implemented based on the ICMP protocol or a dedicated application-layer health check interface. The agent or monitoring service inside the virtual instance is responsible for receiving and responding to this message. After a virtual instance is determined to be disconnected, it is marked as abnormal from its original bound terminal device and awaits cleanup. Simultaneously, its configuration information and status are repackaged into a new deployment request and placed at the forefront of the business request queue. Optionally, the triggered new resource allocation process will undergo complete processing by the resource matching module and fragmentation optimization module again, and finally, the scheduling execution module will recreate and start the virtual instance on potentially different terminal devices, thereby achieving fault self-healing.

[0100] In practice, the resource-oriented scheduling module is activated after the model update module completes the update of the terminal capability distribution table. The module divides the terminal devices in the updated table according to their maximum capacity for virtual instances. Devices with a higher maximum capacity are grouped into a high-capacity terminal group, and those with a lower capacity are grouped into a low-capacity terminal group. The capacity threshold used for grouping can be a preset fixed value or a dynamic median calculated based on the capacity of all terminal devices. For newly added virtual instances in the service request queue, the resource-oriented scheduling module parses the virtual instance's type tag. If the type tag indicates that the virtual instance is computationally intensive and insensitive to communication latency, it is prioritized for allocation to a suitable terminal device in the high-capacity terminal group. For virtual instances in the service request queue whose type tag indicates they are communication-intensive and have low computational resource requirements, they are prioritized for allocation to the low-capacity terminal group. This grouping-oriented allocation strategy reduces mutual interference between computationally intensive and communication-intensive tasks in resource contention.

[0101] In some embodiments, the division of high-capacity terminal groups into low-capacity terminal groups can be based on a defined capacity threshold, and the formula for calculating the capacity threshold can be expressed as:

[0102] ;

[0103] Where: symbol The symbol Q represents the capacity threshold used for grouping, and Q represents the total number of terminal devices in the updated terminal capability distribution table. This represents the maximum number of virtual instances that the j-th terminal device can support, as recorded in the updated terminal capacity distribution table. The formula calculates the average of the maximum number of virtual instances that all terminal devices can support as a dynamic threshold. It can be understood that when the maximum number of virtual instances that a terminal device can support is greater than or equal to the capacity threshold... When the terminal device is in the high-capacity terminal group, it is classified as such; when the maximum number of virtual instances it can support is less than the capacity threshold... If a virtual instance is assigned to a high-capacity terminal group, it will be placed in the low-capacity terminal group. This grouping mechanism divides heterogeneous terminal clusters into two pools with different resource preferences. Optionally, for compute-intensive virtual instances, when matching resources within the high-capacity terminal group, the current load rate of the terminal devices can still be considered for sorting and selection; for communication-intensive virtual instances, when matching within the low-capacity terminal group, the network bandwidth margin or physical topology location of the terminal devices can be additionally considered. Through the group-oriented allocation strategy, compute-intensive virtual instances are more likely to be scheduled to device groups with more abundant compute resources, while communication-intensive virtual instances are more likely to be scheduled to device groups that may be closer to the network edge or have less resource contention, thus forming a classified and adaptive resource scheduling mechanism.

[0104] See Figure 5 In real-time performance monitoring of virtual instances, the dynamic changes in multi-dimensional resource metrics can be used to evaluate the scheduling effectiveness and load balancing status of a heterogeneous terminal adaptive virtualization cloud platform. Specifically, using time series as the horizontal axis, four core performance metrics—CPU utilization, memory utilization, disk I / O wait time, and network round-trip time—are mapped to discrete monitoring points, constructing a performance curve showing the coordinated changes of multiple metrics. The curve trends show that CPU utilization peaks at 76% at 50 seconds, remaining between 35% and 65% for the rest of the time, reflecting the phased fluctuations in virtual instance computing load; memory utilization gradually increases and then decreases over time, generally remaining between 27% and 62%, reflecting the dynamic allocation and release of memory resources; disk I / O wait time peaks at 57ms at 40 seconds, remaining between 17ms and 45ms for the rest of the time, representing the instantaneous impact of storage layer I / O load; and network round-trip time generally remains between 14ms and 38ms, with relatively gentle fluctuations, reflecting the stability of network layer communication latency. The coordinated changes of the four types of indicators can be used to verify the effectiveness of the intelligent load balancing strategy: when the CPU or memory load suddenly increases, the disk I / O and network latency do not fluctuate synchronously and drastically, indicating that the scheduling mechanism has achieved resource isolation and load shifting to a certain extent; while the appearance of indicator peaks provides data basis for the weight update of the terminal capability assessment model, and the weight coefficients of dimensions such as processor computing power and memory capacity can be adjusted in a targeted manner to optimize the accuracy of subsequent resource allocation.

[0105] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any other way. Any person skilled in the art may make changes or modifications to the above-disclosed technical content to create equivalent embodiments that can be applied to other fields. However, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the protection scope of the present invention.

Claims

1. A heterogeneous terminal adaptive virtualization cloud platform based on intelligent load balancing, characterized in that, include: The terminal assessment module generates a terminal capability distribution table using a pre-set terminal capability assessment model. The resource matching module matches a set of candidate terminals that meet resource constraints in the terminal capability distribution table based on the type tags of the virtual instances to be deployed in the business request queue, and generates an initial resource allocation scheme based on the current load rate. The fragmentation optimization module binds each virtual instance in the initial resource allocation scheme to the corresponding candidate terminal. During the binding process, a resource fragmentation rate is calculated for the binding relationship between each group of virtual instances and candidate terminals to obtain a resource allocation result set containing several binding relationships and their resource fragmentation rates. The fragmentation merging operation is performed on the resource allocation result set. The fragmentation merging operation reduces the average resource fragmentation rate of the resource allocation result set by swapping the ownership of virtual instances on different terminals, and generates an optimized resource allocation result set. The scheduling and execution module transforms the optimized resource allocation result set into virtual machine creation instructions for each terminal device, executes the virtual machine creation instructions in the heterogeneous terminal cluster, starts the corresponding virtual instances, and collects real-time performance monitoring data of each virtual instance during operation. The model update module dynamically adjusts the computing power weight coefficient in the terminal capability assessment model based on real-time performance monitoring data to update the terminal capability distribution table. The process involves binding each virtual instance in the initial resource allocation scheme to its corresponding candidate terminal. During the binding process, a resource fragmentation rate is calculated for each group of virtual instances and candidate terminals to obtain a resource allocation result set containing several binding relationships and their resource fragmentation rates, including: For each group of virtual instances and candidate terminals in the initial resource allocation scheme, extract a snapshot of the remaining hardware resources of the candidate terminals after binding. Based on the processor computing power margin, available memory space, storage read / write speed and network bandwidth utilization in the remaining hardware resource snapshot, the dispersion of the remaining resources is calculated as the resource fragmentation rate of the binding relationship. The resource fragmentation rate is calculated as the standard deviation of the remaining resource value relative to the average value. The larger the standard deviation value, the more uneven the distribution of the remaining resources and the higher the degree of fragmentation. The unique identifier of the virtual instance, the bound terminal identifier, and the corresponding resource fragmentation rate are associated and stored to form a resource allocation result set; The fragmentation merging operation on the resource allocation result set, which reduces the average resource fragmentation rate of the resource allocation result set by swapping the ownership of virtual instances on different terminals, generates an optimized resource allocation result set, includes: Calculate the average resource fragmentation rate across all binding relationships in the resource allocation result set; Iterate through any two binding relationships in the resource allocation result set, attempt to swap the terminal affiliation of the virtual instances in these two binding relationships, and generate a new temporary resource allocation result set; Calculate the average resource fragmentation rate of the new temporary resource allocation result set. If the new average resource fragmentation rate is lower than the original average resource fragmentation rate, accept the exchange and update the resource allocation result set. Repeat the swapping and comparison process until multiple consecutive swaps fail to further reduce the average resource fragmentation rate, and output the optimized resource allocation result set.

2. The heterogeneous terminal adaptive virtualization cloud platform based on intelligent load balancing according to claim 1, characterized in that, The process of generating a terminal capability distribution table using a pre-set terminal capability assessment model includes: Obtain hardware resource snapshots of each terminal device in the heterogeneous terminal cluster. The hardware resource snapshots include processor computing power margin, available memory space, storage read / write speed, and network bandwidth utilization. Multi-dimensional resource feature extraction is performed on the hardware resource snapshot. The extracted multi-dimensional resource features are input into a pre-set terminal capability evaluation model to obtain the upper limit of the number of virtual instances that each terminal device can support, thereby forming a terminal capability distribution table, specifically including: Normalize the processor computing power margin, available memory space, storage read and write speed and network bandwidth utilization in the hardware resource snapshot to eliminate numerical differences between different units. The normalized resource indicators are mapped to the feature vector dimensions in the terminal capability assessment model, where the processor computing power margin corresponds to the computing density feature, the available memory space corresponds to the concurrency support feature, the storage read and write rate corresponds to the data throughput feature, and the network bandwidth utilization rate corresponds to the communication latency feature. The feature vector is input into the terminal capability assessment model, which is trained using historical operating data, and is used to output the upper limit of the number of virtual instances that each terminal device can stably support in the current state. By summarizing the device identifiers of all terminal devices, the calculated upper limit of the number of virtual instances that can be supported, and the corresponding feature vectors, a terminal capability distribution table is generated.

3. The heterogeneous terminal adaptive virtualization cloud platform based on intelligent load balancing according to claim 1, characterized in that, The step of matching a set of candidate terminals that meet resource constraints in the terminal capability distribution table based on the type tags of virtual instances to be deployed in the service request queue, and generating an initial resource allocation scheme based on the current load rate, includes: The type tag of each virtual instance to be deployed in the business request queue is parsed. The type tag defines the minimum processor computing power, minimum memory capacity and minimum storage bandwidth required by the virtual instance. Traverse the terminal capability distribution table, filter out terminal devices that meet the resource requirements of the virtual instance to be deployed, and form a candidate terminal set; Calculate the current load rate of each terminal device in the candidate terminal set, where the current load rate is the ratio of allocated resources to the upper limit of bearable resources; The candidate terminal set is sorted in ascending order of current load rate, and the virtual instances to be deployed are allocated to the terminal devices ranked first in the sorting, until all virtual instances to be deployed have been allocated, thus forming the initial resource allocation scheme.

4. The heterogeneous terminal adaptive virtualization cloud platform based on intelligent load balancing according to claim 1, characterized in that, The step of converting the optimized resource allocation result set into virtual machine creation instructions for each terminal device includes: The virtual machine creation instruction includes the resource configuration parameters and scheduling priority of the virtual instance; Parse each binding relationship in the optimized resource allocation result set to obtain the type tag of the virtual instance and the terminal identifier it is bound to; Based on the type label of the virtual instance, determine the number of virtual processor cores, virtual memory size, and virtual disk space required by the virtual instance as resource configuration parameters; Based on the current load rate of the terminal devices described in the terminal capability distribution table, set the scheduling priority of the virtual instance. The lower the load rate, the higher the scheduling priority. Resource configuration parameters and scheduling priorities are encapsulated into virtual machine creation instructions and archived according to terminal identifiers.

5. The heterogeneous terminal adaptive virtualization cloud platform based on intelligent load balancing according to claim 1, characterized in that, The process of executing virtual machine creation instructions in a heterogeneous terminal cluster, starting corresponding virtual instances, and collecting real-time performance monitoring data of each virtual instance during operation includes: Based on the terminal identifier in the virtual machine creation instruction, the corresponding virtual machine creation instruction is sent to the specified terminal device; On the terminal device side, a virtual machine instance is created according to the virtual machine creation instructions, the operating system image and application dependencies are loaded, and the virtual instance is started. The agent program installed inside the virtual instance periodically collects the virtual instance's CPU usage, memory usage, disk I / O latency, and network packet round-trip time as real-time performance monitoring data. The collected real-time performance monitoring data is transmitted back to the monitoring center of the cloud platform for unified storage.

6. The heterogeneous terminal adaptive virtualization cloud platform based on intelligent load balancing according to claim 1, characterized in that, The step of dynamically adjusting the computing power weight coefficient in the terminal capability assessment model based on real-time performance monitoring data to update the terminal capability distribution table includes: Perform statistical analysis on real-time performance monitoring data to calculate the average value of processor computing power, memory capacity and storage bandwidth actually used by each virtual instance during operation; The calculated average actual resource usage is compared with the theoretical resource requirements preset in the terminal capability assessment model to obtain the deviation value of each resource dimension. Based on the magnitude of the deviation, the weight coefficients corresponding to processor computing power margin, available memory space, storage read and write speed and network bandwidth utilization in the terminal capability assessment model are adjusted proportionally, and the weights of resource dimensions with large deviations are increased. The terminal capability assessment model is rerun using the adjusted weighting coefficients to reassess all terminal devices in the heterogeneous terminal cluster, generating an updated terminal capability distribution table.

7. The heterogeneous terminal adaptive virtualization cloud platform based on intelligent load balancing according to claim 1, characterized in that, The platform also includes: The fault self-healing module sets a keep-alive detection timer for the binding relationship between each group of virtual instances and candidate terminals in the initial resource allocation scheme; During the keep-alive detection timer period, a heartbeat probe message is sent to the virtual instance, and the virtual instance is waited for a response. If no response is received from the virtual instance within the preset timeout period, the virtual instance is determined to be in a disconnected state, and the virtual instance is returned to the head of the business request queue. Trigger a new resource allocation process to reallocate terminal devices to the disconnected virtual instance, enabling rapid migration and recovery of the abnormal instance; The platform also includes: The source-oriented scheduling module divides the terminals in the updated terminal capability distribution table into high-capacity terminal groups and low-capacity terminal groups according to the maximum number of virtual instances they can support. For virtual instances in the business request queue that are computationally intensive and not sensitive to communication latency, priority should be given to allocating them in the high-capacity terminal group; For virtual instances in the business request queue that are communication-intensive and have low computing resource requirements, priority should be given to allocating them in low-capacity terminal groups. This group-oriented allocation strategy reduces resource competition between different types of virtual instances, forming a resource scheduling mechanism that adapts to different categories.

8. The heterogeneous terminal adaptive virtualization cloud platform based on intelligent load balancing according to claim 1, characterized in that, The construction of the terminal capability assessment model includes: Collect performance monitoring datasets of various terminal devices in a heterogeneous terminal cluster when running multiple virtual instances within a historical period. The performance monitoring datasets include terminal hardware resource utilization, actual resource consumption of virtual instances, and virtual instance running stability indicators. Data cleaning and feature engineering are performed on the performance monitoring dataset to extract a multi-dimensional feature set related to the virtual instance carrying capacity. The multi-dimensional feature set includes processor computing power dynamic margin, memory space fragmentation rate, storage input / output concurrent load and network bandwidth fluctuation rate. A neural network model structure containing an input layer, multiple hidden layers, and an output layer is constructed. The multidimensional feature set is used as the input features of the model, and the upper limit of the number of virtual instances that the terminal can stably support is used as the training label of the model. The neural network model is iteratively trained using the gradient descent algorithm. The internal parameters of the model are optimized by minimizing the loss function between the upper limit of the number of virtual instances predicted by the model and the actual observed number of stable bearers. After the model training is completed, the generalization performance of the model is evaluated by cross-validation set, and the model parameters that meet the preset threshold are saved to form the terminal capability evaluation model.

Images