Migration method and device of application data, storage medium, electronic device and program product

Abstract

Embodiments of the present application provide a kind of application data migration method and device, storage medium, electronic equipment and program product, it is related to computer field, wherein, method includes: in response to the migration request triggered by application data of cloud platform, the target instruction set indicated by migration request is acquired;Performance portrait associated with application data on source node is acquired, wherein, performance portrait is used to indicate source node, the first load data of first resource configuration associated with source instruction set architecture is run by application data;Based on performance portrait, equivalence prediction is carried out to target node, and the second resource configuration associated with target instruction set architecture is obtained, wherein, the second load data of second resource configuration is run by application data in target node, and it corresponds with first load data;Second resource configuration is determined from the multiple nodes of cloud platform to target node, and application data is migrated from source node to target node.

Description

Technical Field

[0001] This application relates to the field of computers, and more specifically, to a method and apparatus for migrating application data, a storage medium, an electronic device, and a program product. Background Technology

[0002] In heterogeneous computing environments (server clusters employing multiple instruction set architectures), traditional migration methods simply migrate application data and configurations directly when migrating application data from nodes with one instruction set architecture to nodes with another. However, due to differences in CPU cores, memory management, and I / O performance between servers with different architectures, traditional migration methods can lead to a significant decrease in application performance on the target node, or even prevent the application from running properly due to insufficient resources, resulting in low efficiency for cross-architecture migration of application data.

[0003] Therefore, there is a technical problem in the related technologies where the cross-architecture migration of application data is inefficient. Summary of the Invention

[0004] This application provides a method and apparatus for migrating application data, a storage medium, an electronic device, and a program product, to at least solve the technical problem of low efficiency in cross-architecture migration of application data in related technologies.

[0005] According to one embodiment of this application, an application data migration method is provided, comprising: responding to a migration request triggered by application data on a cloud platform, obtaining a target instruction set architecture indicated by the migration request, wherein the migration request is used to indicate migrating application data from a source node of a source instruction set architecture to a target node of a target instruction set architecture, and the cloud platform includes at least two nodes with different instruction set architectures; obtaining a performance profile associated with the application data on the source node, wherein the performance profile is used to indicate that the source node runs first load data of the application data on a first resource configuration associated with the source instruction set architecture; performing an equivalence prediction on the target node based on the performance profile to obtain a second resource configuration associated with the target instruction set architecture, wherein the target node runs second load data of the application data on the second resource configuration, which corresponds to the first load data; determining the target node from multiple nodes of the cloud platform based on the second resource configuration, and migrating the application data from the source node to the target node.

[0006] According to one embodiment of this application, an application data migration apparatus is provided, comprising: a first acquisition unit, configured to acquire a target instruction set architecture indicated by the migration request in response to a migration request triggered by application data on a cloud platform, wherein the migration request is used to instruct the application data to be migrated from a source node of a source instruction set architecture to a target node of a target instruction set architecture, and the cloud platform includes at least two nodes with different instruction set architectures; a second acquisition unit, configured to acquire a performance profile associated with the application data on the source node, wherein the performance profile is used to indicate that the source node runs first load data of the application data on a first resource configuration associated with the source instruction set architecture; a prediction unit, configured to perform equivalent prediction on the target node based on the performance profile to obtain a second resource configuration associated with the target instruction set architecture, wherein the second load data of the application data run on the target node on the second resource configuration corresponds to the first load data; and a migration unit, configured to determine the target node from multiple nodes of the cloud platform based on the second resource configuration and migrate the application data from the source node to the target node.

[0007] According to yet another embodiment of this application, a computer-readable storage medium is also provided, in which a computer program is stored, wherein the computer program is configured to perform the steps in any of the above method embodiments when it is run.

[0008] According to yet another embodiment of this application, an electronic device is also provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0009] According to the embodiments provided in this application, upon receiving an application data migration request, the request is parsed to determine the target instruction set architecture. This identification process determines the direction of all subsequent migration activities, i.e., from the source node of the source instruction set architecture to the target node of the target instruction set architecture. Next, performance metrics of the application data currently running on the source node are obtained, including but not limited to CPU utilization, memory consumption, network throughput, I / O operation frequency, latency, and throughput. This data constitutes a performance profile of the application, reflecting its operating status and resource requirements under the source instruction set architecture. Using the performance profile of the source node, the equivalent resource configuration required for the application data to run under the target instruction set architecture is derived through resource equivalence prediction. The prediction of equivalent resource configuration considers the hardware differences and performance characteristics between different architectures, ensuring that the resource requirements under the target architecture are equivalent to those under the source architecture. Finally, based on the predicted second resource configuration, the most suitable node is selected and determined as the target node from cloud platforms containing different instruction set architectures. The selection of the target node considers factors such as real-time resource utilization, node health status, and network latency, ensuring that the selected node is optimal under the current conditions. Then, the data migration process is executed. By accurately analyzing the performance of application data under the source architecture and predicting the resource requirements under the target architecture, we can ensure a smooth transition of application performance under the target architecture, reduce the impact on business during the migration process, and achieve smooth service migration. This improves the efficiency and success rate of cross-architecture migration of application data, achieves the technical effect of improving the efficiency of cross-architecture migration of application data, and solves the technical problem of low efficiency in cross-architecture migration of application data. Attached Figure Description

[0010] Figure 1 This is a hardware structure block diagram of an application data migration method according to an embodiment of this application.

[0011] Figure 2 This is a flowchart of an application data migration method according to an embodiment of this application.

[0012] Figure 3 This is a schematic diagram of the system architecture of a smooth migration system for cross-architecture applications in a multi-core cloud environment according to an embodiment of this application.

[0013] Figure 4 This is a schematic diagram of the functional modules of a migration control plane according to an embodiment of this application.

[0014] Figure 5 This is a schematic diagram of the functional modules of a data and flow plane according to an embodiment of this application.

[0015] Figure 6 This is a schematic diagram of the functional modules of a monitoring and model plane according to an embodiment of this application.

[0016] Figure 7 This is a structural block diagram of an application data migration device according to an embodiment of this application. Detailed Implementation

[0017] The embodiments of this application will be described in detail below with reference to the accompanying drawings and examples.

[0018] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "including" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0019] To facilitate a clearer understanding of the embodiments of this application, some terms appearing in the embodiments are explained below.

[0020] SLA (Service Level Agreement): This application aims to ensure that the SLA does not degrade, meaning that during the migration process, the key performance indicators of the application's external services (such as response latency and error rate) must be maintained above the preset standards.

[0021] ISA (Instruction Set Architecture): Refers to the set of instructions that a CPU can understand and execute; it serves as the interface between hardware and software. This application primarily addresses the application migration problem between different ISAs (such as x86, ARM, and RISC-V).

[0022] API (Application Programming Interface): In this application, communication and collaboration between the three planes and between the system and external infrastructure are achieved through standardized APIs, which is key to achieving modularity and loose coupling.

[0023] AIM (Automatic ISA Matching): An automatic instruction set architecture matching module, one of the modules in this application, is responsible for automatically checking and confirming that the target architecture has a compatible application image version during the migration planning phase, thus avoiding migration failures caused by software incompatibility from the source.

[0024] PAS (Performance-Aware Scheduling): A performance-aware scheduling module, an intelligent scheduling module in this application, which not only considers the amount of resource requests, but also combines the equivalent computing power model and the real-time performance data of the nodes to select the optimal target physical or virtual node for the migration task.

[0025] CDC (Change Data Capture): Change data capture is a core technology used for migrating stateful services. It achieves near real-time data synchronization by capturing incremental data changes (such as transaction logs) in the source database and replaying them on the target database.

[0026] TPS (Transactions Per Second): Transactions per second is a key performance indicator that measures the system's processing capacity. In this application, it is used to evaluate the change in application throughput before and after migration (i.e., TPS deviation) and is one of the core metrics of smoothness.

[0027] RTO (Recovery Time Objective): This refers to the maximum time required from the occurrence of a migration failure to the point where the service is fully restored on the source end when a rollback is triggered. The automated rollback mechanism in this application aims to control the RTO to the minute level.

[0028] RPO (Recovery Point Objective): The recovery point objective refers to the amount of data (measured in time) that may be lost after a failure or migration of a stateful service. The strong consistency synchronization strategy in this application aims to achieve an RPO of zero, i.e., no data loss.

[0029] PID (Proportional-Integral-Derivative): a control algorithm based on proportional-integral-derivative. This application uses it in an adaptive flow orchestration controller to achieve an automatic balance between migration speed and system stability by dynamically adjusting the parameters of the flow switching curve.

[0030] The methods and embodiments provided in this application can be executed on a computer terminal or similar computing device. Taking running on a computer terminal as an example, Figure 1 This is a hardware structure block diagram of a computer terminal for an application data migration method according to an embodiment of this application. For example... Figure 1 As shown, a computer terminal may include one or more ( Figure 1Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. The computer terminal may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the computer terminal described above. For example, the computer terminal may also include components that are more complex than those described above. Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0031] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the application data migration method in this embodiment. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thus implementing the above-described method. The memory 104 may include high-speed random access memory and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to a computer terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0032] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by a communication provider for the computer terminal. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0033] As an optional solution, this embodiment provides a method for migrating application data, such as... Figure 2 As shown, it includes:

[0034] S202, in response to a migration request triggered by application data on the cloud platform, obtain the target instruction set architecture indicated by the migration request, wherein the migration request is used to indicate that the application data is migrated from the source node of the source instruction set architecture to the target node of the target instruction set architecture, and the cloud platform includes at least two nodes with different instruction set architectures.

[0035] S204, Obtain the performance profile of the application data associated with the source node, wherein the performance profile is used to indicate the first load data of the application data running on the first resource configuration associated with the source instruction set architecture on the source node.

[0036] S206. Based on the performance profile, perform equivalent prediction on the target node to obtain the second resource configuration associated with the target instruction set architecture. The second load data of the target node running application data in the second resource configuration corresponds to the first load data.

[0037] S208 determines the target node from multiple nodes on the cloud platform based on the second resource configuration and migrates application data from the source node to the target node.

[0038] Optionally, in this embodiment, the cloud platform is a platform composed of multiple computing nodes that provides unified computing, storage, and network resource management services. In this embodiment, the cloud platform can manage computing nodes with different instruction set architectures such as x86, ARM, and RISC, achieving heterogeneous resource management.

[0039] Optionally, in this embodiment, application data refers to running application instances and their backend stateful data, such as databases, cached data, etc.

[0040] Optionally, in this embodiment, the instruction set architecture defines the set of instructions that the processor can understand and execute, serving as a crucial interface between hardware and software. In this embodiment, the source instruction set architecture specifically refers to the architecture on which the application is currently running, while the target instruction set architecture is the architecture to which the application will be migrated. The source node is the computing node where the application data currently resides and runs on the source instruction set architecture; the target node is the computing node to which the application data will be migrated and runs on the target instruction set architecture.

[0041] Optionally, in this embodiment, the performance profile indicates a description of the application data's operating status under a specific architecture and configuration, including but not limited to metrics such as CPU utilization, memory consumption, network throughput, I / O operation frequency, application latency, and throughput. Resource configuration refers to the resources allocated for running the application data, including the number of CPU cores, memory size, network bandwidth, and disk I / O rate.

[0042] Optionally, in this embodiment, when an application data migration request is triggered through the cloud platform user interface or API, the target instruction set architecture information in the request must first be parsed. This information explicitly indicates the direction of migration, i.e., from the source node of the source ISA architecture to the target node of the target ISA architecture.

[0043] Upon receiving a request, the system collects performance metrics data from the application instances running on the source node, creating a detailed performance profile. This data reflects the actual operating status and resource consumption of the application under the source ISA architecture, serving as the basis for equivalent prediction.

[0044] The acquired performance profile is input into the equivalent computing power model, which predicts the resource configuration required to maintain the same performance level under the target architecture based on the resource configuration and application load data of the source architecture. This process takes into account the differences in hardware characteristics between the source and target architectures, such as processor architecture, memory model, and I / O performance.

[0045] Based on the resource allocation obtained from the equivalent prediction, the system selects the most suitable node from multiple nodes on the cloud platform to meet the operational requirements of the target architecture. This selection comprehensively considers factors such as node resource availability, load level, network topology, and security policies to ensure that the target node can meet the performance requirements of the new instance. Subsequently, the application data is redeployed on the target node, and data is synchronized from the source node to the target node, completing the entire migration process.

[0046] In this embodiment, the optimal resource configuration under the target architecture is determined in a data-driven manner through precise performance profiling analysis and equivalent computing power model prediction. This ensures that the migration process is not only efficient but also maintains the same performance and service level agreement as the source architecture. Specifically, the system first responds to the migration request and clarifies the target architecture; then, it collects performance profiles of the source nodes to provide basic data for resource prediction; next, based on the performance profiles and equivalent predictions, it intelligently selects the target node and determines its resource configuration; finally, it performs the migration of application data, including the redeployment of application instances and the replication of stateful data. Throughout the process, the system significantly reduces the complexity and risk of cross-architecture migration through automated and intelligent decision-making, enabling smooth migration of application data in heterogeneous environments and improving the resource scheduling efficiency and business continuity of the cloud platform.

[0047] According to the embodiments provided in this application, upon receiving an application data migration request, the request is parsed to determine the target instruction set architecture. This identification process determines the direction of all subsequent migration activities, i.e., from the source node of the source instruction set architecture to the target node of the target instruction set architecture. Next, performance metrics of the application data currently running on the source node are obtained, including but not limited to CPU utilization, memory consumption, network throughput, I / O operation frequency, latency, and throughput. This data constitutes a performance profile of the application, reflecting its operating status and resource requirements under the source instruction set architecture. Using the performance profile of the source node, the equivalent resource configuration required for the application data to run under the target instruction set architecture is derived through resource equivalence prediction. The prediction of equivalent resource configuration considers the hardware differences and performance characteristics between different architectures, ensuring that the resource requirements under the target architecture are equivalent to those under the source architecture. Finally, based on the predicted second resource configuration, the most suitable node is selected and determined as the target node from cloud platforms containing different instruction set architectures. The selection of the target node considers factors such as real-time resource utilization, node health status, and network latency, ensuring that the selected node is optimal under the current conditions. Then, the data migration process is executed. By accurately analyzing the performance of application data under the source architecture and predicting the resource requirements under the target architecture, we can ensure a smooth transition of application performance under the target architecture, reduce the impact on business during the migration process, and achieve smooth service migration. This improves the efficiency and success rate of cross-architecture application data migration, and achieves the technical effect of improving the efficiency of cross-architecture application data migration.

[0048] As an optional approach, based on performance profiling, equivalence prediction is performed on the target node to obtain the second resource configuration associated with the target instruction set architecture, including:

[0049] Obtain the number of transactions per second parameter for the application data running on the first resource configuration of the source node;

[0050] The target application type and target instruction set architecture corresponding to the application data are determined from multiple configuration prediction models. Each configuration prediction model corresponds to one application type and one instruction set architecture.

[0051] Input the transaction-per-second parameter into the target configuration prediction model to obtain the second resource configuration predicted by the target configuration prediction model. The target configuration prediction model is used to predict the application data of the target application type and the resource configuration required to achieve the transaction-per-second parameter when running on the node of the target instruction set architecture.

[0052] Optionally, in this embodiment, the transactions per second (TPS) parameter is used to indicate a key metric for measuring the application's processing capacity, representing the number of transactions the application can process in one second. A transaction can be any activity that can be quantified as a single processing unit, such as a user request, database operation, or message processing.

[0053] Optionally, in this embodiment, the prediction model is configured as a model for predicting the resource configuration required for an application to achieve a specific performance target under a specific instruction set architecture. These models are trained based on historical data and can quantify the impact of different architectures and configurations on application performance.

[0054] Optionally, in this embodiment, the target application type can be classified into different application types based on the nature and function of the application, such as web services, databases, batch processing, etc. Identifying the application type is a prerequisite for selecting the correct configuration prediction model.

[0055] Optionally, in this embodiment, the TPS parameter of the application data running under the first resource configuration is first extracted from the performance profile of the source node. This parameter directly reflects the application's throughput and performance requirements and is a key data point for configuring the prediction model input.

[0056] Based on the characteristics and functions of the application data, the system identifies the application type to which it belongs. Subsequently, it selects the prediction model corresponding to that application type and target instruction set architecture from multiple configuration prediction models. Each configuration prediction model is specifically designed for a particular application type and architecture, enabling more accurate prediction of resource requirements.

[0057] The source node's transactions per second (TPS) parameter is used as input to the target configuration prediction model. Based on internally trained parameters and rules, the model calculates the resource configuration required to achieve the same TPS under the target architecture. The predicted result is the second resource configuration, which considers factors such as the target architecture's processor performance characteristics, memory management methods, and I / O performance, ensuring accurate resource matching.

[0058] Optionally, in this embodiment, by acquiring the actual processing capacity of application data on the source node, the performance requirements of the application are reflected in a quantitative form, providing a key basis for subsequent predictions. The application type is intelligently identified, and the most suitable configuration prediction model is selected based on the type and the target ISA architecture. Different applications have significantly different resource requirements and performance characteristics, and the accuracy of model matching directly affects the prediction effect of resource configuration. The TPS parameter is fed into the target configuration prediction model, and the model's algorithm calculates the resource configuration required to maintain the same performance on the target architecture. The output of the prediction model is based on machine learning algorithms, which can adapt to the characteristics of different architectures, provide refined resource configuration suggestions, and ensure a smooth performance transition for applications in heterogeneous environments.

[0059] The embodiments provided in this application extract and utilize the TPS parameters of the application, and combine the application type identification and target architecture adaptation configuration prediction model to achieve accurate prediction of resource configuration in cross-architecture migration. This ensures that the performance of application data on the target node is consistent with or close to that of the source node, while optimizing resource utilization efficiency and reducing the risk of migration failure.

[0060] As an optional approach, the method also includes the following when migrating application data from the source node to the target node:

[0061] If the response latency parameter of the target node is detected to be greater than the reference latency parameter, obtain the number of computing resources and the number of instance replicas indicated by the second resource configuration.

[0062] Input the number of computing resources, the number of instance replicas, and the response latency parameter into the configuration prediction model, perform configuration adjustment operations, and obtain the number of instance replicas after the first adjustment of the response latency parameter with the number of computing resources remaining unchanged, and the number of computing resources after the second adjustment of the response latency parameter with the number of instance replicas remaining unchanged.

[0063] If the first magnitude is greater than or equal to the second magnitude, the number of computing resources and the adjusted number of instance replicas will be determined as the adjusted second resource configuration;

[0064] If the first magnitude is less than the second magnitude, the adjusted number of computing resources and the number of instance replicas will be determined as the adjusted second resource configuration;

[0065] Update the resource configuration of the target node according to the adjusted second resource configuration.

[0066] Optionally, in this embodiment, the response latency parameter is a metric that measures the time required for an application to process a request, typically in milliseconds. In this embodiment, the response latency parameter is used to evaluate the performance of the application instance on the target node.

[0067] Optionally, in this embodiment, the reference latency parameter is the latency standard in the preset service level agreement (SLA). The response latency of the application instance cannot exceed this parameter in order to maintain service quality.

[0068] Optionally, in this embodiment, the number of computing resources refers to the number of CPU cores, memory size, and other computing power resources allocated to the application instance. The number of instance replicas indicates that multiple application instance replicas can be created to share traffic in order to improve application availability and load balancing.

[0069] Optionally, in this embodiment, during the migration of application data from the source node to the target node, the system continuously monitors the application instance response latency parameter on the target node. Once the system detects that the latency parameter exceeds the reference latency parameter (i.e., the maximum allowable latency defined in the SLA), it initiates the configuration adjustment process.

[0070] The system reads the number of computing resources (such as the number of CPU cores and memory size) and the number of instance replicas from the current secondary resource configuration, providing basic data for subsequent model prediction and resource adjustment.

[0071] The current target node response latency parameters, computing resource quantity, and instance replica quantity are fed into the configuration prediction model for analysis and prediction. The model calculates the magnitude of response latency reduction by increasing the number of instance replicas while keeping the computing resource quantity constant (first magnitude); it also predicts the magnitude of response latency reduction by increasing the number of computing resources while keeping the instance replica quantity constant (second magnitude).

[0072] The system compares the first and second magnitudes to select the more effective adjustment method. If the first magnitude is greater than or equal to the second magnitude, it indicates that increasing the number of instance replicas is more effective in optimizing response latency. Therefore, the system will keep the number of computing resources unchanged while adjusting the number of instance replicas. Conversely, if the first magnitude is less than the second magnitude, the number of computing resources will be increased first. The adjusted resource configuration (i.e., the adjusted second resource configuration) will be applied to the target node.

[0073] Based on the configuration adjustment results, the system updates the application instance resource configuration on the target node to optimize response latency parameters and ensure service quality and SLA achievement.

[0074] The embodiments provided in this application solve the problem of response latency exceeding SLA standards after application data migration by dynamically adjusting resource configuration through real-time monitoring of the target node's response latency parameters and combining this with a configuration prediction model. This ensures service quality stability and SLA achievement. This dynamic adjustment mechanism can intelligently select the most effective resource configuration strategy based on the real-time performance feedback of the target node, improving the optimization and scheduling level of data center resources.

[0075] As an optional approach, before determining the target application type and the target configuration prediction model corresponding to the target instruction set architecture from multiple configuration prediction models, the method further includes:

[0076] Using training samples, for each combination of application type and instruction set architecture, a corresponding configuration prediction model is trained and generated, resulting in multiple configuration prediction models.

[0077] After updating the resource configuration of the target node according to the adjusted second resource configuration, the method also includes:

[0078] Based on the adjusted second resource allocation, the parameters of the target configuration prediction model are updated.

[0079] Optionally, in this embodiment, the training samples are historical datasets used to train the configuration prediction model, including performance data applied under different configurations and architectures, such as transactions per second (TPS), response time, resource consumption, etc.

[0080] Optionally, in this embodiment, before migrating application data, a large number of training samples are used to train and generate configuration prediction models for each combination of application types and instruction set architectures. Each set of models is specifically designed for resource configuration prediction under a specific ISA architecture for a specific application type. Through machine learning algorithms, the models learn to predict the required computing resources and the number of instance replicas when given specific performance metrics (such as TPS).

[0081] Upon receiving an application data migration request, the system first identifies the application type and target ISA architecture, and then selects a matching configuration prediction model from the pre-trained model library for the next step of resource prediction.

[0082] After the migration is complete, the system compares the actual performance of the target node under the adjusted resource configuration with the model's prediction results. If there are significant differences (i.e., computing power residuals), the system uses this actual data as new training samples to update the parameters of the corresponding configuration prediction model, thereby optimizing the model's prediction accuracy. This process forms a closed loop for model optimization, ensuring that the model can iterate and improve itself as the actual operating environment of the data center changes.

[0083] The embodiments provided in this application enable intelligent prediction and dynamic adjustment of resource allocation for application data in cross-instruction set architecture migration scenarios by training and optimizing a configuration prediction model. The model's training and update mechanism continuously improves the accuracy and effectiveness of resource allocation prediction based on the actual conditions of the data center.

[0084] As an optional approach, the target node is determined from multiple nodes on the cloud platform based on a second resource configuration, including:

[0085] Multiple candidate nodes whose resource configuration satisfies the second resource configuration are identified from multiple nodes;

[0086] Based on the resource configuration and load status of multiple candidate nodes, a migration evaluation is performed on multiple candidate nodes to obtain a migration score for each candidate node;

[0087] The candidate node with the highest migration score among multiple candidate nodes is determined as the target node.

[0088] Optionally, in this embodiment, the multiple nodes are a collection of computing nodes with different instruction set architectures contained in the cloud platform, and each node has unique resource capacity and load status.

[0089] Optionally, in this embodiment, the migration assessment refers to a comprehensive evaluation of candidate nodes that meet the second resource configuration requirements during the target node selection process, including considerations of multiple dimensions such as resource sufficiency, node health status, current load level, network latency, and cost-effectiveness.

[0090] Optionally, in this embodiment, the migration score is a quantitative indicator obtained through migration evaluation, which measures the suitability of each candidate node as a target node. The higher the score, the more suitable the node is to receive the migrated application data.

[0091] Optionally, in this embodiment, nodes whose resource specifications meet the second resource configuration requirements predicted by the equivalent computing power model are selected from multiple nodes on the cloud platform as candidate target nodes. This step ensures the basic resource sufficiency of the target nodes, providing a basis for subsequent migration assessment and score calculation.

[0092] For the selected candidate nodes, the system conducts a detailed migration evaluation, considering factors such as resource sufficiency, current load status, network topology, and security policies. Each indicator has its own weight, reflecting its impact on the final migration outcome. Based on the evaluation results, the system calculates a migration score for each candidate node, which comprehensively reflects the node's suitability for accepting application data migration.

[0093] The candidate node with the highest migration score is selected as the target node, and the application data is migrated to that node. This selection ensures that the application data is migrated to the target node with the best performance, the highest resource matching degree, and the lowest network latency, thereby maximizing the smoothness and efficiency of the application data migration and maintaining the achievement of the SLA.

[0094] The embodiments provided in this application intelligently determine the most suitable computing node as the target node through resource adaptation screening and comprehensive migration evaluation of candidate nodes, achieving efficient and smooth migration of application data in heterogeneous cloud platforms. This target node selection mechanism, combined with resource prediction models and multi-dimensional evaluation algorithms, provides strong protection for the migration of application data between different instruction set architectures.

[0095] As an optional approach, after identifying multiple candidate nodes whose resource configurations satisfy the second resource configuration from among multiple nodes, the method further includes:

[0096] When the application data is a stateful application, obtain the data storage location associated with the application data, and obtain the node locations of multiple candidate nodes;

[0097] Among multiple candidate nodes, the candidate node whose node location is closest to the data storage location is determined as the target node;

[0098] When the application type is a multi-service interaction type, obtain the multiple network locations of multiple services associated with the application data;

[0099] Among multiple candidate nodes, the candidate node whose location is closest to the average distance of multiple network locations is determined as the target node.

[0100] Optionally, in this embodiment, stateful applications refer to applications that need to maintain persistent data during operation, such as database services and caching services. The performance and data consistency of these applications are highly dependent on their interaction with data storage.

[0101] Multi-service interaction refers to application types involving frequent communication and collaboration between multiple application services, such as typical applications in a microservice architecture. In this type of application scenario, network latency and communication efficiency between services have a significant impact on overall performance.

[0102] Optionally, in this embodiment, the data storage location refers to the physical location of the data storage (such as a database or key-value store) that stateful applications rely on within the cloud platform. The network location refers to the location of services or data storage on the cloud platform within the network topology, typically identified by their IP address, subnet, availability zone (AZ), or region. Node location and distance refer to the location information of computing nodes within the cloud platform and the network distance between nodes and other critical services or data storage. Network distance can be quantified using network latency or hop count.

[0103] Optionally, in this embodiment, after selecting multiple candidate nodes that meet the second resource configuration requirements from multiple nodes of the cloud platform, the system further performs a more refined evaluation of these nodes to determine the final target node.

[0104] For stateful applications, the system obtains the location information of the data storage that the application depends on, as well as the geographical location of candidate nodes. By calculating the network latency between the candidate node location and the data storage location, the system finds the node closest to the data storage and selects it as the target node. This selection ensures that stateful applications can continue to maintain efficient data access speeds after migration, which is crucial for maintaining data consistency and application performance.

[0105] For applications involving multiple service interactions, the system first obtains the network locations of the services the application depends on. Then, it calculates the average network latency from each candidate node location to these service network locations. Selecting the candidate node with the lowest network latency as the target node helps reduce communication latency between services, improving overall interaction efficiency and application performance.

[0106] Based on the principle of proximity in the network, an optimal target node is determined from multiple candidate nodes, which is then used as the destination for the migration of application data.

[0107] The embodiments provided in this application intelligently optimize the node selection process for stateful applications and multi-service interaction applications by taking into account network distance and latency, ensuring the performance and data consistency of application data after migration to the target node.

[0108] As an optional approach, the method also includes the following steps before migrating application data from the source node to the target node:

[0109] Based on the historical traffic information of the application data, determine the traffic code path associated with the application data;

[0110] Execute the first simulation operation on the target node, wherein the first simulation operation is used to indicate the overlay traffic code path, generate multiple codes and compile the code queue;

[0111] Retrieve hotspot data related to application data;

[0112] Perform a second simulation operation on the target node, wherein the second simulation operation is used to indicate cached hot data;

[0113] Retrieve multiple connection pools associated with application data;

[0114] A third simulation operation is performed on the target node, wherein the third simulation operation is used to instruct the establishment of multiple session connections between multiple connection pools and service objects associated with application data.

[0115] Optionally, in this embodiment, historical traffic information refers to request records of application data during its operation on the source node, including request frequency, type, and source, used to analyze the application's hot code paths and data access patterns. The traffic code path is the logical code path traversed by the application when processing high-frequency requests; it is usually closely related to the application's core functions and services and is a key point for performance optimization. The first simulation operation instructs the simulation of the application's actual operating environment on the target node, executing simulated requests and operations covering the traffic code path to generate and compile a code queue, ensuring that the application's computing resources (such as the JIT compiler) on the target node are adequately warmed up.

[0116] Optionally, in this embodiment, hot data refers to data frequently accessed during application runtime. For stateful applications, the cache hit rate of hot data has a significant impact on overall performance. The second simulation operation instructs the target node to preload the application's hot data into the cache through simulation operations, thereby improving data access speed and cache hit rate.

[0117] Optionally, in this embodiment, the multiple connection pools are a set of connection resource pools established and maintained by the application to improve the connection efficiency and response speed with downstream services (such as databases and message queues). The third simulation operation instructs the establishment of multiple session connections on the target node by simulating concurrent requests, warming up the connection pool between the application and related service objects, and avoiding the first packet delay and connection establishment overhead caused by the connection pool being idle.

[0118] Optionally, in this embodiment, before migrating application data, the system analyzes its historical traffic information to identify the main hot code paths of the application, i.e., the code logic that handles high-frequency requests. This step provides direction for subsequent warm-up operations.

[0119] The first simulation operation is performed on the target node to simulate the application's runtime environment on the source node. By overriding the traffic code path, a code queue is generated and compiled, enabling the Just-In-Time (JIT) compiler or runtime environment on the target node to preprocess hot code, thus achieving the effect of warming up computing resources.

[0120] The application acquires hot data, which is the dataset most frequently accessed during application runtime. Then, a second simulation operation is performed on the target node to preload the hot data into the cache, improving data access speed and ensuring that the application can quickly achieve a stable cache hit rate after migration.

[0121] Identify multiple connection pools associated with the application, including connections to backend services such as databases and message queues. Perform a third simulation operation on the target node to force the application to establish and maintain multiple session connections by simulating concurrent requests, thus warming up the connection pools and reducing latency when the application first connects to backend services.

[0122] Through the embodiments provided in this application, by executing the first, second, and third simulation operations, comprehensive warm-up of the target node's computing resources, data cache, and network connectivity is achieved, ensuring rapid and stable startup after application data is migrated to the target node. This warm-up mechanism effectively overcomes the cold start problem of application migration in heterogeneous environments, guarantees the achievement of business SLAs, and reduces performance fluctuations perceived by users during the migration process.

[0123] As an optional approach, the method also includes the following steps before migrating application data from the source node to the target node:

[0124] Obtain the first simulation metric after the first simulation operation is completed, wherein the first simulation metric is used to indicate the generation time of multiple code segments and the queue length of the compiled code queue;

[0125] Obtain the second simulation metric after the second simulation operation is completed, wherein the second simulation metric is used to indicate the cache coverage of hot data;

[0126] Obtain the third simulation metric after the third simulation operation is completed, wherein the third simulation metric is used to indicate the number of idle session connections among multiple session connections;

[0127] If the generation time is less than the preset time and the queue length is less than the preset length, the first simulation operation is determined to pass the simulation verification.

[0128] If the cache coverage is greater than a preset ratio, the second simulated operation is determined to have passed the simulation verification.

[0129] If the number of connections exceeds the preset number, the third simulation operation is confirmed to have passed the simulation verification.

[0130] If the first, second, and third simulation operations all pass simulation verification, application data can be migrated from the source node to the target node.

[0131] Optionally, in this embodiment, the first simulation metric refers to the performance metrics related to computing resource warm-up collected after performing the first simulation operation on the target node, including the generation time of generating multiple code snippets and the queue length of the compiled code queue. These metrics are used to evaluate the effectiveness and completeness of computing resource warm-up.

[0132] Optionally, in this embodiment, the second simulation metric refers to the performance metrics related to the data preheating effect collected after performing the second simulation operation, mainly the cache coverage rate of hot data. Cache coverage rate reflects the degree to which hot data is filled in the target node cache and is a key metric for evaluating the quality of data preheating.

[0133] Optionally, in this embodiment, the third simulation metric refers to the performance metric related to network connection warm-up recorded when the third simulation operation is completed, focusing on the number of idle session connections among multiple session connections. The number of connections directly affects the latency of the application's initial access to downstream services and the efficiency of establishing connections.

[0134] Optionally, in this embodiment, the preset time, preset length, preset ratio, and preset quantity are thresholds pre-set in the migration strategy to determine whether the first, second, and third simulation operations have achieved the expected results. These thresholds are typically set based on historical performance data and a deep understanding of the characteristics of the target node and application type.

[0135] Optionally, in this embodiment, after the first simulation operation is completed on the target node, the system immediately records the code generation time and the length of the compiled code queue, and compares these two indicators with the preset time and preset length to verify whether the preheating of computing resources has achieved the expected effect.

[0136] After completing the second simulation operation, the cache coverage rate of hot data is collected in real time, and the quality of data warm-up is evaluated by comparing it with the preset ratio.

[0137] After completing the third simulation operation, the system checks the number of idle session connections among multiple session connections to ensure that the connection pool has been adequately warmed up and that the number of connections is sufficient to meet the network requirements of the application.

[0138] Compare the code generation time and queue length in the first simulation index with the preset thresholds. If the code generation time is shorter than the preset time and the length of the compiled code queue is lower than the preset length, it indicates that the preheating of computing resources is effective and the first simulation operation passes the verification.

[0139] The cache coverage rate in the second simulation metric is evaluated. If the cache coverage rate of hot data is higher than the preset ratio, it proves that the data preheating is sufficient and the second simulation operation is verified.

[0140] Check the number of idle session connections in the third simulation metric. If the number is greater than the preset minimum number, it indicates that the network connection warm-up was successful and the third simulation operation was verified.

[0141] Only when the first, second, and third simulation operations all pass verification will the system consider the target node to have completed effective warm-up. At this point, application data can be officially migrated from the source node to the target node to ensure smooth migration and SLA compliance.

[0142] The embodiments provided in this application ensure that the target node's computing resources, data cache, and network connectivity are in optimal preheating state by setting and verifying specific performance indicators after the preheating operation, before receiving application data migration. This comprehensive preheating verification process provides a solid guarantee for smooth application migration in heterogeneous environments, contributing to business continuity and high SLA achievement.

[0143] As an optional solution, application data is migrated from the source node to the target node, including:

[0144] Perform a snapshot operation on the application data to obtain a copy of the application data corresponding to the application data at the first point in time, and then copy the copy of the application data to the target node;

[0145] If the replication of the application data is completed at the second time point, a freeze operation is performed on the application data of the source node. The freeze operation is used to indicate that the application data should not be changed within a specified period after the second time point.

[0146] Obtain incremental application data obtained from the changes in the application data sent by the source node between the first and second time points;

[0147] Within the expected timeframe, incremental application data will be replicated to the target node.

[0148] Optionally, in this embodiment, a snapshot operation refers to a full copy of the application data at a specific point in time to preserve the state of the application data at that point in time for subsequent data migration and synchronization. The copied application data is a complete copy of the application data obtained after the snapshot operation, used to reconstruct the initial state of the application data on the target node.

[0149] Optionally, in this embodiment, the freeze operation indicates a temporary protection measure for the application data of the source node during the data migration process, prohibiting any write operations on the application data within a specific time period to ensure the consistency and integrity of the data during the migration process.

[0150] Optionally, in this embodiment, incremental application data indicates data changes that occur in the source node's application data between the completion of the snapshot operation and the execution of the freeze operation, including added, modified, and deleted data records. The expected time period is a short time window set by the system after the freeze operation to ensure data synchronization integrity and consistency, used to wait for all incremental data in transit to be copied to the target node.

[0151] Optionally, in this embodiment, when the application data migration process starts, the system first performs a snapshot operation on the application data on the source node to preserve the state of the application data at the start of the migration. This operation generates a copy of the application data for subsequent data replication while minimizing business interruption.

[0152] Once the snapshot operation is complete, the system immediately copies the application data to the target node, providing a foundation for subsequent data synchronization and application restart. This copying process is typically performed over the network and may employ different compression and transmission optimization strategies depending on the network conditions between the source and target nodes to improve copying efficiency.

[0153] After replicating the application data, the system checks whether the replica data has caught up with the real-time state of the source data. Once data synchronization is confirmed, the system performs a final check on the application data on the target node to ensure data consistency. Subsequently, the moment the target node is ready, the system performs a freeze operation on the application data on the source node, prohibiting any new data changes from occurring during the freeze period.

[0154] Between the first point in time when the snapshot operation is executed and the second point in time when the freeze operation is executed, the system continuously monitors changes to the application data on the source node, collects all data change operations that occur, and forms incremental application data for subsequent data synchronization.

[0155] During the freeze operation, the system continues to replicate the collected incremental application data to the target node, ensuring that the data state of the target node is completely consistent with the state of the source node at the freeze time. This replication process is also affected by network conditions and the replication mechanism, and may employ strategies such as multi-threading and data compression to accelerate data synchronization.

[0156] During the expected period of the freeze operation, the system will continuously verify the data consistency of the target node, and after confirming that there are no errors, immediately switch the traffic and requests of the source node to the target node, and at the same time unfreeze the state to complete the smooth migration of application data.

[0157] Through the embodiments provided in this application, a series of operations such as snapshotting, freezing, incremental data replication, and data consistency verification are used to achieve smooth migration of application data in a heterogeneous architecture environment, ensuring data integrity and consistency.

[0158] As an optional approach, after replicating the incremental application data to the target node, the method also includes:

[0159] According to the first switching speed, the first access traffic of the first traffic size of the source node is switched to the target node;

[0160] According to the second switching speed, the second access traffic of the second traffic size of the source node is switched to the target node;

[0161] According to the first switching speed, the third access traffic of the third traffic size of the source node is switched to the target node;

[0162] Among them, the first switching speed is less than the second switching speed, the first traffic size is less than the second traffic size, the third traffic size is less than the second traffic size, and the sum of the first traffic size, the second traffic size, and the third traffic size is the total traffic size of the source node.

[0163] Optionally, in this embodiment, a small portion of traffic (a first traffic volume) is first redirected from the source node to the target node at a first switching speed for preliminary performance evaluation and stability testing. This operation is typically performed after data synchronization is complete and the target node has successfully warmed up, and the traffic proportion may be only 1%-5% of the total traffic, used to monitor the application's initial response under the target architecture.

[0164] After the first traffic gray-scale test confirms that the target node's performance is stable and meets the SLA requirements, the system will switch a larger proportion of the traffic (second traffic size) from the source node to the target node according to the second switching speed.

[0165] As the second traffic switching nears completion, the system switches back to the first switching speed, transferring the remaining traffic (the third traffic volume) to the target node for final traffic smoothness and application stability verification. This phase may represent only a few percentage points of the total traffic, designed to ensure that the final traffic switching phase does not cause performance fluctuations in the target node.

[0166] Throughout the traffic switching process, the switching of the first, second, and third traffic volumes, as well as the corresponding switching speeds, are all dynamically adjusted based on a canary release strategy using the Sigmoid curve, combined with real-time monitoring data from the SLA guardian. If the system detects performance fluctuations in the target node, the PID controller will automatically reduce the traffic switching speed; conversely, it may accelerate the switching.

[0167] The embodiments provided in this application achieve a smooth migration of application data from the source node to the target node through a phased, variable-speed traffic switching strategy, ensuring business continuity and SLA compliance. This strategy effectively balances the requirements of migration efficiency and target node performance stability, providing technical assurance for building a highly reliable and efficient private cloud environment.

[0168] As an optional approach, during the process of switching the second access traffic of the second traffic size from the source node to the target node according to the second switching speed, the method further includes:

[0169] If the response delay parameter of the target node is detected to be less than the reference delay parameter, and the delay difference between the response delay parameter and the reference delay parameter is greater than the reference delay difference, the delay difference is proportionally calculated according to the preset ratio parameter to obtain the first adjustment speed;

[0170] Based on the second switching speed, the first adjustment speed is increased.

[0171] Optionally, in this embodiment, the response latency parameter refers to the response time of the target node when processing business traffic, typically expressed as P99 latency (i.e., 99% of request response times are below this value), used to measure the application's response speed and system performance. Reference latency parameter: A preset latency threshold serves as a standard for judging whether the target node's performance meets SLA requirements. The reference latency parameter is customized based on historical data and business characteristics, aiming to ensure that the application's performance under the target architecture is not lower than that of the source architecture.

[0172] Optionally, in this embodiment, the latency difference is the difference between the target node's response latency parameter and the reference latency parameter, used to quantify the deviation of the target node's performance from the expected target. The reference latency difference is a preset latency difference threshold, used to determine whether the target node's performance has significantly improved, serving as the basis for improving traffic switching speed. The preset ratio parameter is a fixed ratio value used to perform proportional calculations on the latency difference, determining the adjustment range of the traffic switching speed. The preset ratio parameter can be adjusted according to business needs and system characteristics to optimize the migration process.

[0173] Optionally, in this embodiment, during the process of switching the second traffic volume (a larger proportion of service traffic) of the source node to the target node at the second switching speed, the SLA guardian of the monitoring plane continuously monitors the response latency parameter of the target node, compares it with the preset reference latency parameter, and calculates the latency difference to determine whether the performance of the target node is significantly better than that of the source node.

[0174] When the system detects that the response latency parameter of the target node is less than the reference latency parameter, and the latency difference is greater than the reference latency difference, it will perform a proportional calculation on the latency difference according to a preset proportional parameter to obtain the first adjustment speed. This speed adjustment aims to further improve the traffic switching speed based on the performance advantages of the target node, so as to shorten the migration process, while ensuring the smoothness of the migration and business continuity.

[0175] Based on the second switching speed, the traffic switching speed is dynamically increased according to the first adjustment speed, that is, the rate at which traffic from the source node is directed to the target node is accelerated, thereby achieving traffic switching control optimization based on real-time performance.

[0176] The embodiments provided in this application achieve efficient migration control based on performance advantages by dynamically adjusting the traffic switching speed through real-time monitoring of the target node's performance and combining it with preset proportional parameters for proportional calculation. This mechanism not only improves the efficiency of the migration process and shortens business interruption time, but also ensures the smoothness of the migration and business continuity, providing strong technical support for building a highly reliable and responsive private cloud architecture.

[0177] As an optional approach, during the process of switching the second access traffic of the second traffic size from the source node to the target node according to the second switching speed, the method further includes:

[0178] If the response delay parameter of the target node is detected to be continuously greater than the reference delay parameter during a preset time period, the delay difference between the response delay parameter and the reference delay parameter is integrated according to the preset integration parameter to obtain the second adjustment speed;

[0179] Based on the second switching speed, reduce the second adjustment speed.

[0180] Optionally, in this embodiment, the preset time period is a continuous time period during which the system monitors the performance of the target node during traffic switching, in order to determine whether the performance degradation is continuous, rather than an occasional spike phenomenon.

[0181] Optionally, in this embodiment, the preset integral parameter is the proportional coefficient used for integral calculation in the PID controller, which determines the contribution of integral calculation to the flow switching speed adjustment.

[0182] Optionally, in this embodiment, the second adjustment speed is a traffic switching speed adjustment value obtained by integral calculation when the performance of the target node is detected to be continuously degrading. This value is used to reduce the traffic switching speed and give the target node more time to recover its performance.

[0183] Optionally, in this embodiment, during the process of switching the second traffic volume (a larger proportion of service traffic) from the source node to the target node at the second switching speed, the SLA guardian of the monitoring and model plane continuously monitors the response latency parameter of the target node. If the response latency parameter of the target node is consistently greater than the reference latency parameter within a preset time period, it indicates that the performance of the target node is lower than expected.

[0184] To address the continued performance degradation of the target node, the system integrates the latency difference based on preset integration parameters to obtain a second adjustment speed. This speed adjustment is primarily used to reduce the traffic switching speed, giving the target node more time to adapt to the load, preventing further performance deterioration, and thus ensuring business continuity and SLA achievement.

[0185] After detecting continuous performance degradation of the target node, the system dynamically reduces the second adjustment speed based on the second switching speed, thereby achieving fine control over the traffic switching speed and ensuring the smoothness and security of the migration process.

[0186] The embodiments provided in this application achieve dynamic adjustment of traffic switching speed through continuous performance monitoring and integral calculations based on PID control theory to address the challenge of continuous performance degradation of target nodes. This not only enhances the system's adaptability and ensures the smoothness and security of the migration process, but also provides stronger technical support for resource scheduling and business continuity management in private cloud environments, contributing to improved overall stability of cloud infrastructure and user experience. Through intelligent control mechanisms, this embodiment can effectively prevent business interruptions or service quality degradation caused by performance degradation.

[0187] As an optional approach, during the process of switching the second access traffic of the second traffic size from the source node to the target node according to the second switching speed, the method further includes:

[0188] If the rate of change of the response delay parameter of the target node is detected to be greater than the reference rate of change within a preset time period, the reference change is differentially calculated according to the preset differential parameter to obtain the third adjustment speed.

[0189] Based on the second switching speed, the third adjustment speed is reduced.

[0190] Optionally, in this embodiment, the preset time period indicates a continuous time window set to detect changes in performance indicators, used to evaluate the stability of the target node's performance. The reference change rate is a preset performance indicator change rate threshold, used to determine whether the target node's response latency parameter has undergone abnormally rapid changes, indicating potential performance instability or deterioration. The change rate indicates the rate of change of the response latency parameter within the preset time period, used to quantify the trend of the target node's performance over time.

[0191] Optionally, in this embodiment, the reference change is the change between the response delay parameter of the target node and the reference delay parameter within a preset time period, used to calculate the difference in the rate of change. The preset derivative parameter is the proportional coefficient used for the derivative operation in the PID controller, determining the strength of the derivative operation in the flow switching speed adjustment.

[0192] Optionally, in this embodiment, the third adjustment speed is the flow switching speed adjustment amount obtained by the system through differential operation when the target node performance index shows an abnormal rate of change. This adjustment is used to immediately adjust the switching speed and prevent sudden performance degradation.

[0193] Optionally, in this embodiment, during the process of switching from the source node's second traffic volume (a higher proportion of traffic) to the target node at the second switching speed, the monitoring and model plane's SLA guardian closely monitors the rate of change of the target node's response latency parameters. If the rate of change is greater than the system's preset reference rate of change, it means that the target node's performance indicators are rapidly deteriorating or fluctuating, requiring an immediate response.

[0194] Upon detecting an abnormal rate of change, the system performs a differential calculation on the reference change based on preset differential parameters to obtain a third adjustment rate. This rate adjustment is primarily used to immediately reduce the traffic switching speed, preventing rapid deterioration of the target node's performance from impacting business continuity and ensuring that the SLA does not degrade.

[0195] When an abnormal rate of change in the target node's response latency parameter is detected, the traffic switching speed will be dynamically reduced based on the third adjustment speed and the current second switching speed, in order to achieve rapid adaptation to the migration process and prevent the further spread of performance degradation events.

[0196] The embodiments provided in this application achieve real-time adjustment of traffic switching speed by monitoring the rate of change of target node performance and responding using differential operations in PID control theory. This effectively addresses sudden performance fluctuations and ensures the smoothness of the migration process and business continuity. This mechanism enhances the system's adaptability and robustness in the face of complex migration challenges in heterogeneous environments, guaranteeing stable operation of services during the migration process.

[0197] As an optional approach, the target instruction set architecture for obtaining the migration request indication includes:

[0198] Parse the deployment description file corresponding to the application data to obtain the architecture tags of the container image of the application data;

[0199] If an architecture image matching the architecture tag exists in the architecture image repository, the instruction set architecture indicated by the architecture tag is determined as the target instruction set architecture.

[0200] Optionally, in this embodiment, the deployment description file is a metadata file used in a container orchestration or virtualization environment to define the configuration and requirements of the application data runtime environment, such as a Dockerfile, Kubernetes DeploymentYAML, or a resource configuration script of a cloud management platform. The architecture tag is an information identifier in the deployment description file indicating the instruction set architecture supported by the container image or application data, typically in the format \arch:x86_64\ or \architecture:arm64\. The architecture image repository is a central repository storing container images compatible with different instruction set architectures, ensuring that the application data can run smoothly on the target architecture.

[0201] Optionally, in this embodiment, after receiving a migration request, the AIM module of the migration control plane first parses the deployment description file corresponding to the application data and extracts information related to architecture compatibility from it, specifically, it looks up the architecture tags of the container image.

[0202] The AIM module further searches the architecture image repository to confirm the existence of a container image that matches the instruction set architecture indicated in the architecture tag. This check is crucial because it directly affects whether the target application instance can successfully start and run on the target instruction set architecture.

[0203] After finding a container image that matches the architecture tag in the architecture image repository, the AIM module determines the instruction set architecture indicated by the architecture tag as the target instruction set architecture, providing a basis for the next step of resource planning and scheduling.

[0204] The embodiments provided in this application achieve accurate determination of the target instruction set architecture by deeply parsing the architecture tags in the deployment description file and combining them with matching checks of the architecture image repository. This lays a solid foundation for resource scheduling and application instance deployment during cross-architecture migration. This mechanism ensures software compatibility and system performance during the migration process, avoids migration risks caused by architecture incompatibility, and improves the migration success rate and the smoothness of the overall migration process.

[0205] As an optional approach, before obtaining the target instruction set architecture indicated by the migration request in response to a migration request triggered by application data on the cloud platform, the method further includes:

[0206] Perform load prediction on the cloud platform for a reference time period to obtain the predicted load parameters of the cloud platform during the reference time period.

[0207] When the predicted load parameters are greater than the reference load parameters, multiple migration requests are triggered for multiple application data on the cloud platform. The multiple application data are application data on nodes of the source instruction set architecture. The multiple migration requests are used to request the migration of multiple application data to nodes of the target instruction set architecture. The multiple application data include application data.

[0208] Optionally, in this embodiment, the reference time period indicates a time window defined for load forecasting, used to analyze historical data and predict future load. The load forecasting indicator predicts the computing and storage needs of the cloud platform during a specific time period (such as peak hours) based on historical load data and business trends.

[0209] Optionally, in this embodiment, the predicted load parameter is the expected load level of the cloud platform within a reference time period, including key indicators such as CPU utilization, memory consumption, and network traffic. The reference load parameter is a preset load threshold, based on the cloud platform's resource capacity and business SLA requirements, used to determine whether migration needs to be triggered to optimize resource allocation.

[0210] Optionally, in this embodiment, before receiving a migration request, the system first performs load prediction on the cloud platform within a reference time period. By analyzing historical load data and current business trends, predicted load parameters are obtained to assess future computing resource requirements.

[0211] The predicted cloud platform load parameters are compared and analyzed with the preset reference load parameters to determine whether the predicted load exceeds the normal range or the expected resource capacity limit.

[0212] If the predicted load parameters exceed the reference value, the system proactively triggers migration requests for application data running on multiple nodes of the source instruction set architecture. These requests aim to smoothly migrate application data to nodes of the target instruction set architecture to optimize resource allocation and cope with the upcoming high load.

[0213] By using rules in the policy library, application data from multiple source instruction set architecture nodes is selected, and requests are initiated to migrate to the target instruction set architecture node. This process includes the application data currently triggering the migration. This operation ensures resource optimization and load balancing, preparing for upcoming high loads.

[0214] The embodiments provided in this application combine historical data analysis and prediction algorithms to achieve accurate prediction of the future load of the cloud platform. When the predicted load exceeds the reference value, the cross-architecture migration of multiple application data is proactively triggered, thereby realizing forward-looking and intelligent scheduling of resources.

[0215] As an optional approach, before obtaining the target instruction set architecture indicated by the migration request in response to a migration request triggered by application data on the cloud platform, the method further includes:

[0216] Perform load detection on the source node to obtain the node load parameters of the source node;

[0217] If the load parameter of a node is greater than the load parameter of the reference node, a migration request is triggered on the application data of the source node. The migration request is used to request the migration of the application data to the target node, where the load parameter of the target node is less than or equal to the load parameter of the reference node.

[0218] Optionally, in this embodiment, the node load parameter is a comprehensive indicator describing the current computing, storage, and network resource usage of the computing node, typically including CPU utilization, memory usage, disk I / O, and network bandwidth. The reference node load parameter is a load threshold set by the system to determine whether the node is in a high-load state. When the node load exceeds this threshold, the system will consider initiating a migration to optimize the load.

[0219] Optionally, in this embodiment, before responding to any migration request, the system first performs real-time load detection on the source node, collecting key indicators including CPU utilization, memory usage, disk I / O and network traffic to obtain the node load parameters of the source node.

[0220] The system compares the load parameters of the source node with the preset reference node load parameters. If the load parameters of the source node exceed the reference value, it indicates that the node may be under resource pressure. The system will then consider migrating the application data on that node to distribute the load and avoid performance bottlenecks.

[0221] If the source node is determined to be overloaded, the system will trigger a migration request for its application data and simultaneously select a target node from the resource pool of the target instruction set architecture whose node load parameter is less than or equal to the reference node's load parameter. This selection ensures that application data is migrated to a node with a lower load, which helps optimize cloud platform resource allocation and improve overall performance.

[0222] The embodiments provided in this application, by combining real-time load detection and intelligent decision-making mechanisms, proactively trigger cross-architecture migration of application data from high-load source nodes and preferentially select target nodes with lower loads, thereby achieving dynamic resource optimization and intelligent load balancing. This mechanism not only helps prevent performance issues caused by source node resource bottlenecks but also reduces the overall operating costs of the cloud platform and improves resource utilization.

[0223] As an alternative, the aforementioned application data migration methods can be applied to smooth cross-architecture application migration scenarios in a one-cloud, multi-chip environment. With the development and deepening of cloud computing technology, the construction and operation of data centers face higher requirements in terms of cost, energy efficiency, and supply chain security. Against this backdrop, the one-cloud, multi-chip heterogeneous computing model has emerged, which involves using a variety of computing chips with different instruction set architectures within a unified cloud platform to leverage the unique advantages of different architectures under specific loads, thereby achieving overall cost reduction and efficiency improvement for the data center. However, this heterogeneous environment also brings unprecedented operational challenges, the most prominent and intractable of which is how to achieve smooth migration of applications between servers with different architectures.

[0224] Enterprises may need to migrate online services running on one ISA (such as x86) node to another ISA (such as ARM) node for reasons such as cost optimization, hardware upgrades, load balancing, or supply chain strategy adjustments. In existing technologies, this process is often challenging, making it difficult to balance efficiency, security, and business continuity.

[0225] This embodiment proposes a smooth cross-architecture application migration system in a multi-core cloud environment. Its core objective is to achieve seamless and smooth online migration of applications running on the source Instruction Set Architecture (ISA) node to a target heterogeneous ISA node, while ensuring that the Service Level Agreement (SLA) does not degrade. This system is specifically designed for virtualized cloud operating systems and cloud management platforms in the private cloud domain, aiming to unify the management and scheduling of computing resources across multiple architectures such as x86, ARM, and RISC-V, thereby improving the overall resource utilization of the data center, optimizing energy efficiency, and reducing operating costs.

[0226] To achieve precise control and closed-loop feedback over complex migration processes, this embodiment employs a modular architecture with three planes working collaboratively. A schematic diagram of the system architecture for a smooth cross-architecture application migration system in a one-cloud, multi-core environment is shown below. Figure 3 As shown, the migration plane includes a migration control plane 302, a data and traffic plane 304, and a monitoring and modeling plane 306. The migration control plane 302, acting as the brain of the migration process, is responsible for decision-making, orchestration, and lifecycle management of the entire migration process. Based on preset strategies and real-time feedback, it initiates, monitors, and terminates migration tasks, and handles all anomalies. The data and traffic plane 304, acting as the hands and feet of the migration process, is responsible for executing all low-level operations related to application instances, data, and network traffic. It interacts directly with the infrastructure to complete resource creation, data replication, and traffic switching. The monitoring and modeling plane 306, acting as the eyes and advisor of the migration process, is responsible for continuously collecting performance metrics from both the source and target applications. Through data analysis and model calculations, it provides decision-making support to the control plane and evaluates the smoothness of the migration process in real time.

[0227] Optionally, these three planes communicate through a standardized Application Programming Interface (API) to form a complete feedback control loop. For example, if the monitoring and modeling plane detects that the target performance is substandard, it will immediately notify the control plane; the control plane will adjust its strategy based on this information and issue new instructions to the data and traffic plane, such as slowing down the traffic switching rate or triggering a rollback.

[0228] Optionally, in a typical private cloud environment, this system is logically deployed in the core layer of the cloud management platform. Users / administrators initiate an application migration request through the cloud management platform's user interface or API. This request is first received by the migration control plane. The migration orchestrator within the control plane begins creating a new migration task and enters the first phase of the state machine. The control plane queries the equivalent computing power service in the monitoring and model plane to obtain suggestions on converting the resource requirements of the source architecture (e.g., x86) to the resource requirements of the target architecture (e.g., ARM). Based on the computing power suggestions and application characteristics, the control plane selects the optimal target physical or virtual node through its built-in automatic ISA matching module and performance-aware scheduling module. The control plane issues instructions to the infrastructure layer (e.g., a virtualization platform or container orchestration platform) to create the virtual machines or containers required for the application instance on the target node. The instructions reach the data and traffic plane, where the corresponding modules begin performing specific operations: pulling application images adapted to the target architecture, creating storage volumes, configuring networks, etc. For stateful services, the data replication module (e.g., a CDC agent) of the data and traffic plane starts, beginning to synchronize data from the source to the target. Throughout the process, the monitoring and model plane's probes (Agents) continuously collect performance metrics (such as CPU utilization, memory usage, network throughput, application response latency, etc.) from both the source and target ends, and aggregate the data into a time-series database. Upon receiving instructions from the control plane, the canary controller in the data and traffic plane begins to redirect a small portion of real-time traffic to the target end by adjusting the routing rules of the load balancer or service mesh. The SLA guardian in the monitoring and model plane analyzes the target end's performance in real time. If the performance meets expectations, it notifies the control plane that the traffic percentage can be increased further; if performance degradation occurs, it issues an alert. Based on the feedback from the SLA guardian, the control plane adaptively adjusts the traffic switching curve until 100% of the traffic is switched to the target end. After the migration is complete, the control plane instructs the data and traffic plane to clean up source end resources and update service registration information in the configuration center. The entire process forms a complete closed loop.

[0229] Optionally, in this embodiment, the migration control plane is the command center of the entire system, and its core responsibility is to ensure that migration tasks are executed in an orderly and safe manner according to a predetermined strategy. A schematic diagram of the functional modules of a migration control plane is shown below. Figure 4 As shown, it includes a migration orchestrator 402, a migration state machine 404, a policy library 406, a rollback controller 408, an automatic ISA matching module 410, and a performance-aware scheduling module 412.

[0230] Specifically, the migration orchestrator 402 is the core engine of the control plane, responsible for managing the entire lifecycle of each migration task. When a migration request is accepted, the orchestrator creates a task instance and drives it through a predefined migration state machine. It coordinates all other modules to ensure that the correct operation is performed at the right time.

[0231] The migration state machine 404 defines all possible states of the migration process (such as planning, warming up, synchronizing, switching, completed, failed, and rolling back) as well as the transition conditions and triggering actions between states. This design makes complex migration processes structured and predictable. For example, the state machine can only transition to the data synchronization or traffic switching state after the target end's warm-up state has been successfully completed.

[0232] Policy Library 406 is a configurable rules database that stores various policies used to guide migration decisions. Administrators can define different policy sets based on the importance and characteristics of the business.

[0233] The rollback controller 408 is responsible for performing automatic or manual rollback operations when serious problems occur during the migration process. Based on the rollback thresholds defined in the policy library, it immediately generates a reverse migration plan upon receiving an alarm from the monitoring plane, safely switching traffic and data state back to the source, minimizing business downtime.

[0234] The automatic ISA matching module 410 is responsible for automatically selecting the correct target image for the migration task. It identifies the target architecture tags declared within the application's deployment description file (such as a container manifest or virtual machine metadata). Then, it queries the integrated multi-architecture image repository to verify the existence of a tested and verified image version that matches the target ISA. If no matching image is found, the migration task will fail prematurely, avoiding subsequent resource waste.

[0235] The performance-aware scheduling module 412, after selecting the correct image, is responsible for choosing the most suitable physical or virtual nodes in the target cluster to host application instances. Unlike traditional schedulers that only consider CPU and memory request volumes, the PAS module is a more intelligent decision engine: it first queries the equivalent computing power service in the monitoring and model plane to convert the resource consumption of the source application (e.g., 4 x86 vCPUs) into the equivalent resource requirements under the target ISA (e.g., it may require 6 ARM vCPUs).

[0236] Then, it acquires real-time performance data of all candidate nodes in the target cluster, including CPU load, memory pressure, network bandwidth utilization, I / O wait time, etc.

[0237] The PAS module comprehensively considers the equivalent computing power requirement and the real-time load of the nodes, and scores each node using a weighted scoring algorithm. The scoring model tends to select nodes with lower load, lower network latency, and sufficient resources.

[0238] Ultimately, the node with the highest score will be selected as the migration target to ensure that the application has sufficient performance guarantees after migration.

[0239] It's important to note that the migration control plane doesn't directly manipulate the hardware; instead, it interfaces with the underlying cloud infrastructure management platform via an adapter. In a container orchestration platform environment, the control plane calls the platform's APIs to create resources such as Deployments, Services, and Ingresses to deploy application instances and configure networks on the target nodes. In a virtualization platform environment, the control plane calls its APIs to create virtual machine instances, mount storage volumes, and configure security groups. This loosely coupled design allows this embodiment to be flexibly integrated into private cloud environments with different technology stacks.

[0240] Optionally, in this embodiment, the data and traffic plane is the collection of all actual operations performed. It precisely completes tasks such as data replication, traffic scheduling, and application instance lifecycle management according to the instructions of the control plane. A schematic diagram of the functional modules of a data and traffic plane is shown below. Figure 5 As shown, it includes: a change data capture module 502, a snapshot module 504, a dual-write agent module 506, a grayscale controller 508, an input module 510, an output module 512, a flow dynamic adjustment module 514, a connection drain module 516, and a preheating and probe module 518.

[0241] Specifically, Change Data Capture Module 502: This module is designed for the migration of stateful applications such as databases and message queues.

[0242] Snapshot module 504: In the early stages of migration, it creates a consistent point-in-time snapshot of the data volume of the source application and restores that snapshot to the new storage volume on the target side as the basis for data synchronization.

[0243] After the base snapshot is restored, the CDC agent attaches to the transaction log (such as MySQL's binlog) of the source database or the storage log of the message queue, captures all new data change operations (insert, delete, modify) in real time, and replays these changes on the target end at near real-time speed.

[0244] Traditional physical replication can fail across heterogeneous architectures due to byte order or data alignment issues. This module translates underlying physical data changes (such as binary log entries) into logical operations (such as SQL statements or key-value pair operations), and then re-executes them on the target end in a manner consistent with its ISA. For example, when migrating from an x86 MySQL instance to an ARM MySQL instance, the CDC agent reads logical SQL events from the binlog and then executes these SQL statements on the ARM MySQL instance, thus mitigating the risk of incompatible underlying data formats.

[0245] Dual-write proxy module 506: As an alternative to CDC (Data Synchronization Detection), dual-write proxy can be implemented at the application layer. It is a lightweight proxy service deployed between the application and the database. During the data synchronization phase of the migration, all write requests are intercepted by the proxy and then written to both the source and target databases simultaneously. To handle potential duplicate write issues (e.g., CDC is also synchronizing), the target database or application needs to have idempotency capabilities, or the proxy itself needs to implement deduplication logic.

[0246] The 508 grayscale controller is responsible for precisely controlling the real-time ratio of business traffic flowing to the source and destination. It is typically integrated with a service mesh or API gateway.

[0247] Input module 510: Receives instructions from the control plane, which include the target flow rate percentage (e.g., 5%), switching duration, and flow curve type (e.g., sigmoid).

[0248] Output module 512: Generates and applies configurations to the corresponding traffic management components (such as VirtualService of the service mesh or forwarding rule of the load balancer).

[0249] Flow Dynamic Adjustment 514: The grayscale controller not only executes static plans, but also subscribes to performance alarms from the monitoring plane. When it receives a signal of performance degradation at the target end, it can autonomously pause increasing the flow, and even proactively reduce the flow ratio in emergency situations, waiting for the control plane to issue a final decision (whether to continue, slow down, or roll back).

[0250] Connection Flushing Module 516: In the final stage of migration, after all traffic has switched to the target, the source instance cannot be immediately destroyed. This is because there may still be some long-running requests or background tasks being processed. The connection flushing module is responsible for gracefully shutting down the source instance. It instructs the load balancer to stop sending new requests to the source and sets a timeout (e.g., defined by `grace_period_seconds` in the policy library) to wait for all established connections to close naturally. After the timeout, any remaining connections will be forcibly terminated, and only then will the instance be safely destroyed.

[0251] Warm-up and Probe Module 518: Newly created application instances are typically in a cold state before receiving real traffic. Their internal cache is empty, the Just-In-Time (JIT) compiler has not yet optimized hot code, and the connection pool has not been established. Directly switching traffic to cold instances can cause a sharp increase in latency for initial requests, or even timeouts. The warm-up module aims to address this issue.

[0252] It simulates real user requests, sending a series of predefined warm-up traffic to the target instance. This traffic can be replay traffic recorded from the production environment or aggregated traffic generated based on interface definitions. Simultaneously, the Health Probe continuously probes key performance indicators of the target instance, such as application startup time, first request response time, and CPU cache hit rate. Only when these indicators reach the readiness thresholds defined in the policy library will the warm-up module notify the control plane that the target is ready to receive production traffic.

[0253] Optionally, in this embodiment, the monitoring and model plane serves as the system's perception and analysis hub, providing assurance for the smoothness and security of migration through a data-driven approach. A schematic diagram of the functional modules of a monitoring and model plane is shown below. Figure 6 As shown, it includes: an indicator collector 602, a monitoring data pipeline 604, a drift detection and statistical testing engine 606, an SLA guardian 608, and an equivalent computing power predictor 610.

[0254] Specifically, the metrics collector 602 is deployed on the node where the application instance resides in the form of an agent or sidecar. It is responsible for collecting various performance metrics from the operating system, virtualization layer, container runtime, and application internals (through code instrumentation or standard interfaces such as JMX and Prometheus Exporter).

[0255] Monitoring data pipeline 604: The collected data is formatted into a uniform format (such as Prometheus metricsformat) and appended with contextual tags (such as application name, instance ID, architecture type, migration task ID). This data is then sent via a high-throughput message queue (such as Kafka) to a central time-series database (such as Prometheus, InfluxDB, M3DB) for storage and querying.

[0256] The data collection cycle for the metrics is configurable. For sensitive metrics such as latency, the collection frequency can be as high as once per second; for trend-based metrics such as resource utilization, it may be once every 15 seconds or once per minute.

[0257] Drift Detection and Statistical Testing Engine 606: This is the core component that ensures SLA does not degrade.

[0258] SLA Guardian 608: It continuously queries the time series database to obtain the real-time performance metrics of the target application under grayscale traffic and compares them with the SLA thresholds defined in the policy library.

[0259] Statistical Testing Methods: Simple threshold comparisons are easily affected by spikes in data, leading to false alarms. To improve decision-making accuracy, this embodiment introduces more advanced statistical process control methods. CUSUM (Cumulative Sum) Algorithm: This algorithm accumulates and sums a series of consecutive performance samples, sensitively detecting small but persistent shifts in the data mean. For example, if the target's P99 delay is consistently 5ms higher than the source's, even if a single measurement is within the SLA threshold, CUSUM can quickly accumulate this deviation and trigger an alarm. SPRT (Sequential Probability Ratio Test): This is a more efficient hypothesis testing method. It does not require a fixed sample size but recalculates the probability ratio between accepting the hypothesis of no performance degradation or performance degradation each time a new data point arrives. Once the probability ratio exceeds a preset confidence boundary, a decision can be made immediately, thus detecting problems as quickly as possible.

[0260] Equivalent Compute Power Predictor 610: This is key to achieving accurate cross-architecture resource mapping. Because processors across different ISAs differ in core count, frequency, cache size, pipeline design, etc., simply replacing vCPUs one-to-one is not feasible.

[0261] Offline model training: The predictor first collects performance data on all managed heterogeneous hardware in an offline environment by running a series of standardized benchmark programs (such as SPEC CPU, Geekbench) and representative business workloads. It builds a multidimensional database containing hardware parameters, workload types, and performance scores.

[0262] Performance surface modeling: Using machine learning algorithms (such as gradient boosting trees or neural networks), a performance-resource surface model is built for each ISA and application type based on offline data. This model can answer questions such as: For a typical web service, on an ARM architecture A-type server, with X vCPUs and Y GB of memory, what is the expected TPS (Transactions Per Second)?

[0263] The trained model is deployed as an API service. When the PAS module in the control plane needs to make scheduling decisions, it provides the resource configuration and performance of the source application (e.g., 4 x86 vCPUs, 8GB of memory, supporting 500 TPS). The service then uses its model to deduce the resource configuration required to support the same load (500 TPS) on the target ARM architecture (e.g., 6 ARM vCPUs, 8GB of memory).

[0264] The model is not static. After each migration task, the monitoring and model plane collects the target device's performance under actual load and compares it with the model's predictions. This residual (the difference between prediction and reality) is fed back to the model to adjust and optimize model parameters online, making it more accurate over time. For example, if the model predicts that 6 ARM vCPUs are sufficient, but it is found that 6.5 are needed to achieve equivalent performance, this data point will be used to update the model, making it more conservative or accurate in future predictions.

[0265] Optionally, the cross-architecture smooth migration process in this embodiment is strictly defined as a state machine comprising six main stages. This design ensures the standardization, automation, and observability of the migration process. The objectives, key activities, and technical implementations of each stage will be described in detail below.

[0266] The migration task will go through the following six core stages from creation to completion: perception and planning stage, target end warm-up stage, data synchronization stage, smooth traffic switching, stage verification and convergence stage, and completion / cleanup stage.

[0267] Furthermore, if a serious failure occurs at any stage, the state machine can enter a special failure and rollback state. State transition representations are shown in Table 1, for example.

[0268] Table 1 State Transition Table

[0269]

[0270] The perception and planning phase is the starting point of the migration. Its goal is to develop a detailed, feasible, and low-risk migration plan based on a comprehensive understanding of the application and the environment.

[0271] Reading the equivalent computing power model: The migration orchestrator first queries the equivalent computing power predictor in the monitoring and model plane. It provides the identifier of the source application, and the service returns a performance profile of the application under the current load, as well as the estimated resources (CPU, memory, network bandwidth, etc.) required to maintain equivalent performance under the target ISA.

[0272] Using AIM / PAS to select compatible nodes: The AIM module intervenes, parsing the application's metadata to determine if its software stack supports the target ISA. For example, it checks the application's container image manifest file to confirm that it contains layers for the target architecture (such as Linux / arm64). If some libraries that the application depends on do not provide ARM versions, AIM will mark them as incompatible at this stage and abort the migration.

[0273] The PAS module receives the target architecture and resource requirements provided by the equivalent computing power service confirmed by AIM, and begins searching for the optimal deployment location within the target cluster. The PAS scoring algorithm considers the following factors:

[0274] 1. Resource adequacy: Whether the available CPU and memory of the node meet the requirements.

[0275] 2. Node health status: Whether the node is active and fault-free.

[0276] 3. Load level: Prioritize nodes with lower current load to avoid performance interference caused by neighbor effect.

[0277] 4. Network Topology: For stateful applications, prioritize the node with the lowest latency to the target storage. For applications involving multiple service interactions, prioritize the node with the closest network distance to the dependent services.

[0278] 5. Stains and Tolerance: Follow the scheduling policies of the container orchestration platform to ensure that the application is placed on a group of nodes that allow it to run.

[0279] Output migration plan: The final output of this stage is a structured migration plan document (usually in JSON or YAML format) that contains all the information required for subsequent stages: a unique migration task ID, detailed information about the source instance (ID, IP address, resource configuration, etc.), selected target node information, resource specifications of the target instance (e.g., CPU: 6, memory: 8 Gi), an AIM-confirmed mirror address adapted to the target architecture, redundancy factor (the ratio of the number of instances created on the target to the number of instances on the source), usually greater than or equal to 1, to provide additional capacity buffering, and migration strategies.

[0280] Compared to traditional static scheduling (which only matches requested resources), the perception and planning phases in this embodiment are dynamic and intelligent. It addresses the issue of inconsistent metrics for heterogeneous resources through an equivalent computing power model, and ensures software compatibility and post-implementation performance through AIM and PAS, thus preventing a large number of potential migration failures from the outset.

[0281] Target-end warm-up phase: The goal of this phase is to ensure that newly created application instances on the target node reach a performance level comparable to that of the source instance before receiving any real business traffic.

[0282] Multi-stage preheating: The preheating process is broken down into multiple levels, going deeper layer by layer to ensure that the application is fully heated.

[0283] Infrastructure warm-up: The first step is to pull the application image adapted to the target architecture to the target node and start the container or virtual machine. This process can be time-consuming and needs to be completed in advance.

[0284] Application runtime warm-up: For languages ​​using Just-In-Time (JIT) compilation, it is necessary to trigger the compilation and optimization of hot-spot code by sending simulated requests. For example, in a Java service based on Spring Boot, the warm-up script will call all its main API endpoints several times to ensure that the relevant classes are loaded, and the JIT compiler will compile the frequently executed bytecode into efficient native machine code.

[0285] Cache preheating: Internal application caches (such as Caffeine and GuavaCache) and external distributed caches (such as Redis) are empty at startup. The preheating module proactively pulls frequently accessed data from databases or other data sources based on the application's dependencies and populates the caches at various levels. For example, for a product details service in an e-commerce application, the preheating script requests the details pages of the 1000 most visited products, thus loading their data into the cache.

[0286] Connection pool warm-up: The connection pools between the application and backend services such as databases and message queues are initially empty. The warm-up script simulates concurrent requests, forcing the application to establish and maintain a minimum number of healthy connections, avoiding latency jitter and resource consumption caused by establishing a large number of connections instantaneously when real traffic comes in.

[0287] Health probe verification: Throughout the warm-up process, the health probes on the monitoring plane continuously monitor the key performance indicators of the target instance and compare them with the warm-up completion thresholds defined in the policy library.

[0288] Example of preheating indicators:

[0289] Has the JIT compilation activity stabilized?

[0290] Has the internal cache hit rate reached a stable level (e.g., >90%)?

[0291] Is the disk I / O latency consistently low?

[0292] Has the number of active connections in the database connection pool reached the preset value?

[0293] Is the P99 response delay under simulated preheating flow rate lower than a certain threshold (e.g., 50ms)?

[0294] Only when all key metrics meet the conditions is the target device considered to have successfully warmed up and is ready to enter the next stage. This quantitative, metric-based warm-up verification mechanism replaces the crude mode of relying solely on application startup signals in traditional migrations, greatly improving the performance stability of the initial stage after migration.

[0295] Data synchronization phase (stateful services): For stateful services such as databases, distributed caches, and message queues, data synchronization is the most complex and riskiest part of the entire migration process. The goal of this phase is to replicate the data state from the source to the target server completely and consistently, while minimizing service interruption or data loss.

[0296] Replication Pipeline: This embodiment employs a multi-stage pipeline approach to ensure smooth and efficient data synchronization.

[0297] Initial Snapshot: At the start of the migration, an online snapshot is performed on the source data volume. To ensure snapshot consistency, the database may be briefly locked, or the consistent snapshot feature supported by the storage system itself may be utilized. Once the snapshot operation is complete, the lock is released immediately, and the impact on business operations is controlled within seconds.

[0298] Incremental synchronization: Once a snapshot is created, it is immediately restored on the target database. Simultaneously, a Change Data Capture (CDC) agent is initiated, connecting to the transaction log of the source database. It captures all subsequent data changes, starting from the snapshot creation time (e.g., GTID or LSN). These changes are continuously and with low latency sent to the target database and replayed.

[0299] Calibration and Catch-up: During incremental synchronization, the data state at the target end may temporarily lag behind the source end due to network latency or target end load. The CDC system continuously monitors this replication latency.

[0300] The migration controller will wait for this latency to decrease to a very small, acceptable threshold (e.g., less than 1 second).

[0301] Eventual consistency check: Before switching traffic, a data verification can be performed by sampling and hashing the key tables of the two ends to ensure that there is no inconsistency in the data.

[0302] Brief Write Freeze and Switchover: To achieve zero data loss (RPO=0), a very brief write freeze window is needed at the moment of traffic switching. The control plane instructs the application or agent to pause writing new data to the source database, waiting for the CDC to complete the synchronization of the last batch of logs. Once it is confirmed that the data on both ends is completely consistent, the database connection is immediately switched to the target end, and the write freeze is lifted. This window can typically be controlled within milliseconds to seconds.

[0303] Logical Layer Replication and Byte Order Conversion: As mentioned earlier, this invention emphasizes the use of logical layer replication to solve data compatibility issues between heterogeneous ISAs. The CDC tool is configured to parse logical operations in the transaction log, rather than physical page changes. This naturally solves byte order issues such as endianness, because the SQL statements or logical records themselves are platform-independent.

[0304] Dual-write and deduplication mechanism: In some scenarios where latency is extremely sensitive but eventual consistency can be tolerated, dual-write can be used as an alternative or supplement. During the synchronization phase of migration, all write operations of the application are sent to both the source and target ends simultaneously through a proxy.

[0305] Deduplication: Since the CDC may also be synchronizing data simultaneously, the target end may receive duplicate operations. To solve this problem, the target table must be designed to be idempotent. For example, at the business logic level, each write operation has a unique transaction ID, and duplicate IDs are ignored.

[0306] Synchronization strategies for different services:

[0307] Relational databases (such as MySQL) primarily use CDC based on transaction logs (binlog).

[0308] Key-value stores (such as Redis): Redis's built-in replication functionality (PSYNC) can be utilized, or an incremental approach using RDB snapshots + AOF can be employed. For cross-architecture migrations, a more robust approach is to scan the source data and replay it on the target side using the SET command to avoid potential incompatibility issues with the RDB file format.

[0309] Message queues (such as Kafka): Utilize their native cross-cluster replication tools (such as MirrorMaker) to completely mirror topic data from the source cluster to the target cluster. Because Kafka's message format is platform-independent, physical replication can be performed directly.

[0310] Smooth Traffic Switching Phase: Once the target device has finished warming up and data synchronization is complete, the migration enters the most critical traffic switching phase. The goal of this phase is to smoothly and seamlessly transfer user traffic from the source device to the target device, much like tuning a knob.

[0311] Gradual rollout based on grayscale curves: This invention abandons the high-risk approach of traditional one-time switching (BigBang) and adopts a traffic control strategy based on grayscale release.

[0312] Application of the Sigmoid Curve: The Sigmoid function (logistic Sigmoid function) is used by default as the control curve for flow allocation. Its formula is f(t)=L / (1+e^(-k(t-t0))), where t is time, f(t) is the percentage of flow allocated to the target end, L is the total flow (100%), k controls the steepness of the curve (i.e., the switching speed), and t0 is the midpoint time of the switching.

[0313] Advantages: The Sigmoid curve is very flat at the beginning and end, accelerating the switchover in the middle. This slow-fast-slow pattern allows for initial testing of the target device's true performance with extremely low traffic (e.g., 1%). If problems arise, they can be detected immediately and rolled back with minimal impact. Once stability is confirmed, traffic can be rapidly increased, shortening the migration window. Towards the end of the switchover, the speed is slowed down again to ensure a smooth final cleanup.

[0314] Adaptive adjustment of curve and current limiting rate: The grayscale controller does not rigidly execute the preset curve, but has adaptive capabilities.

[0315] Linked with the monitoring plane: The controller subscribes to performance health signals published by the monitoring plane in real time. This signal is generated by the SLA guardian based on statistical test algorithms such as CUSUM / SPRT.

[0316] Dynamic adjustment: If the target end performs well (low latency, no errors), the controller can dynamically increase the steepness k of the curve, thereby accelerating the migration process.

[0317] If the target device experiences a slight performance degradation (such as a slight increase in P99 latency, but still within the SLA threshold), the controller will automatically reduce the k value to slow down the flow switching speed, giving the target device more breathing room to adapt to the load.

[0318] If performance degradation reaches a critical threshold defined in the policy library, the controller will immediately pause the switching, or even proactively revert the traffic ratio back to the previous stable state and request a ruling from the control plane.

[0319] Sequential statistical testing for real-time degradation detection: At each adjustment step of the traffic percentage (e.g., increasing from 5% to 10%), the system enters a short observation period. During this period, the SLA guardian uses the SPRT algorithm to quickly determine whether the performance is stable under the new traffic percentage. The advantage of the SPRT algorithm is that it can make a judgment as soon as sufficient statistical confidence is obtained, without waiting for a fixed, lengthy observation window, thus greatly improving the efficiency and response speed of the entire switching process.

[0320] Verification and Convergence Phase: Once 100% of the traffic has successfully switched to the target endpoint, the migration task does not end immediately but enters the verification and convergence phase. The goal of this phase is to ultimately confirm the success of the migration and optimize the system model.

[0321] SLA reconciliation: The system will run for a relatively long time window (e.g., 15 minutes or 1 hour) to continuously monitor whether the target device's performance fully and consistently meets all SLA metrics defined in the policy library. This is equivalent to a final acceptance test.

[0322] Equivalent computing power model residual evaluation: A core innovation at this stage is the formation of a closed loop for model optimization.

[0323] Residual calculation: The monitoring plane records the actual amount of resources (such as CPU and memory) consumed by the target device to meet the SLA when it is carrying 100% production traffic. Then, this actual resource consumption is compared with the resource requirements predicted by the equivalent computing power model during the migration planning phase. The difference between the two is the computing power residual.

[0324] For example, during planning, the model predicted the need for 6 ARM vCPUs. However, in actual operation, it was found that an average of 6.5 vCPUs were used to stabilize the P99 latency below the target value. Therefore, this +0.5 vCPU is the residual computing power from this migration.

[0325] Strategy library and model updates: The calculated residuals are fed back to the equivalent computing power predictor. The model will then fine-tune its internal parameters based on this new data point, making its future predictions more accurate.

[0326] If certain SLA metrics are found to be too stringent or lenient in actual operation, adjustment suggestions can be generated at this stage for administrators to optimize the strategy library.

[0327] Source instance cleanup and resource retention: After SLA reconciliation is passed, the control plane initiates a connection cleanup process for the source instance, gracefully closing all remaining connections. Depending on the policy, the virtual machines or containers of the source instance and their associated storage volumes may not be immediately destroyed, but will enter a cold standby state and be retained for a period of time (e.g., 24 hours) as a final, foolproof rollback guarantee.

[0328] Anomaly Path and Rollback Phase: Robust anomaly handling and rapid rollback capabilities are the bottom line for ensuring a smooth migration. This invention designs an anomaly detection and automated rollback mechanism throughout the entire migration process.

[0329] Define rollback trigger thresholds: The strategy library explicitly defines quantitative metrics for triggering rollbacks, which are divided into multiple levels:

[0330] CriticalAlert: Triggers an immediate, unconditional rollback. For example:

[0331] ΔTPS>50%: The processing capacity of the target end drops by more than 50% compared to the source end.

[0332] P99_latency>500ms: P99 latency exceeds an absolute, unacceptable hard limit.

[0333] failure_rate>5%: The error rate spikes dramatically.

[0334] SustainedAlert: Triggers a rollback when a performance metric lingers in the medium alert range for an extended period (e.g., for 3-5 consecutive sampling periods). For example, P99 latency is consistently above normal but below the hard limit.

[0335] Execute rollback: Once the rollback controller is triggered, it will immediately execute a contingency plan.

[0336] Partial / Global Rollback: The first step in a rollback is to instruct the canary controller to switch all traffic back to the still-running source instance as quickly as possible (usually linearly or in one step). Because the source instance is in a hot standby state until the migration is complete, this switchover process is very rapid.

[0337] Database / State Switchback: For stateful services, if the switchover occurs after data synchronization is complete, a database connection switchback may also be required. If the target end has already written a small amount of data, depending on the policy, this data may be discarded (if business requirements permit), or it may need to be redirected back to the source end through a reverse data synchronization process.

[0338] Timing and Log Auditing: All operations and decisions made during the entire rollback process are recorded in detail in the audit log, including the performance metrics that triggered the rollback, timestamps, and executed commands. This provides crucial information for subsequent fault analysis and root cause analysis (RCA).

[0339] Examples of abnormal scenarios:

[0340] Bandwidth drop: During traffic switching, if the network bandwidth of the physical machine where the target node is located is suddenly preempted by other applications, causing a sharp increase in the latency of the target application, the SPRT algorithm will quickly detect this change and trigger a rollback.

[0341] Kernel incompatibility: After the application starts on the target ARM node, although it passes basic health checks, a deep, ARM architecture-related kernel bug or library function incompatibility issue is triggered when handling a certain type of request, causing the process to crash. The monitoring plane detects continuous instance restarts and a spike in the error rate, immediately triggering a rollback.

[0342] Through this multi-layered, automated anomaly handling and rollback loop, the present invention keeps migration risks at an extremely low level, ensuring rapid service recovery even in the worst-case scenario and minimizing the impact on business.

[0343] To achieve the aforementioned refined migration workflow, this embodiment also designs a series of core control algorithms and mechanisms, which are the cornerstone of the system's intelligence and adaptability.

[0344] Adaptive Traffic Orchestration Controller: The core objective of this controller is to minimize the disruption to services during the migration process while satisfying both Service Level Agreements (SLAs) and Recovery Time Objectives (RTOs). It achieves intelligent orchestration of traffic switching by combining classical cybernetics with modern statistical methods.

[0345] Objective function: The optimization objective of the controller can be formally described as: minimizing the total migration time T_migration under the constraints of Latency_p99(t)<=L_max and Error_rate(t)<=E_max.

[0346] Adaptive curve selection and rate shaping: The controller does not mechanically execute a fixed Sigmoid curve, but dynamically adjusts the curve shape and switching speed according to the real-time performance of the system.

[0347] This mechanism is based on the PID (proportional-integral-derivative) control principle, which enables the migration process to automatically balance between acceleration and deceleration, ensuring a smooth and safe flow switching.

[0348] Input and output:

[0349] Input signal:

[0350] e(t) = L_target - L_observed(t)

[0351] Where: L_target is the desired performance target (e.g., 80% of the SLA limit, for example, 100ms × 0.8 = 80ms); L_observed(t) is the real-time observed latency (e.g., the current P99 latency). When e(t) is positive, it indicates good performance; when e(t) is negative, it indicates decreased system performance or increased stress.

[0352] Output signal:

[0353] The adjustment amount Δk of the slackness parameter k of the Sigmoid curve controls the grayscale switching speed: the larger k is, the steeper the grayscale curve and the faster the flow switching; the smaller k is, the smoother the curve and the slower and more stable the switching.

[0354] Control logic and examples:

[0355] The controller adjusts Δk through three parts working together:

[0356] 1. Proportion (P) item

[0357] Δkp=Kp×e(t), the larger the deviation, the more adjustments are needed.

[0358] When the system performance is much better than the target (significantly lower latency), the controller will switch over more quickly.

[0359] Example: Target delay L_target = 100ms, measured L_observed = 70ms, then e(t) = 100 - 70 = +30. If the scaling factor Kp = 0.02, then Δk_p = 0.02 × 30 = +0.6. Increasing the controller's k value (e.g., from 2.0 to 2.6) makes the Sigmoid curve steeper, accelerating the grayscale switching rate.

[0360] 2. Integral (I) term

[0361] Δki=Ki× The integral term e(t)dt is used to accumulate the performance deviation over a period of time, reflecting the long-term trend of the system.

[0362] When the latency remains slightly higher than the target for an extended period, it indicates that the switching rate is too fast. The controller will gradually decrease the parameter k through the integral term, creating a continuous deceleration effect to prevent the problem from accumulating and amplifying. Here, dt represents the time interval (deltatime), which is the time difference between each performance sample, used to measure the length of time the deviation has accumulated. For example, if the system samples every minute, the integral is equivalent to gradually accumulating the deviation from each past minute.

[0363] Example: If the average delay over the past 5 minutes is 110ms (the target remains 100ms), then the deviation per minute e(t) ≈ -10. With a sampling interval dt = 1 minute, the cumulative integral is: e(t)dt≈(-10)×5=-50. If the integral coefficient K_i=0.005, then: Δki=0.005×(-50)=-0.2. The controller therefore reduces k from 2.6 to about 2.35, making the Sigmoid curve flatter, reducing the grayscale switching speed, and gradually bringing the system delay back to the stable range.

[0364] 3. Differential (D) term

[0365] Δkd=Kd×de(t) / dt, which provides a rapid response to changing trends.

[0366] When the delay suddenly increases sharply (i.e., the rate of change of deviation is large, de(t) / dt is negative and the amplitude is high), the controller immediately reduces k, which is equivalent to emergency braking.

[0367] Example: If the latency increases from 90ms to 150ms in a short period of time, the change is ΔL = -60ms, and the sampling period is 30 seconds. Then de(t) / dt ≈ (-60) / 30 = -2ms / s. If Kd = 0.5, then Δk_d = 0.5 × (-2) = -1.0. The controller immediately reduces k from 2.35 to 1.35, significantly slowing down the traffic switching speed or even pausing the traffic flow.

[0368] The comprehensive adjustment formula Δk=Δkp+Δki+Δkd represents the combined effect of the three terms: when the system is stable and performs well, term P dominates (acceleration); when the delay is slightly high and has been accumulated for a long time, term I dominates (deceleration); when the performance changes abruptly and a peak occurs, term D dominates (emergency stop).

[0369] Through this PID adaptive mechanism, the Sigmoid curve is no longer fixed, but can be dynamically shaped in real time in response to performance signals. It automatically balances migration speed, latency, and error rate, thereby achieving: a smooth migration curve (no abrupt changes); dynamic stabilization (automatic peak suppression); no SLA degradation; and automatic optimization of the grayscale process.

[0370] Traditional linear grayscale deployments have a constant throughput, which cannot cope with nonlinear changes in the target system's capacity and sudden problems. The adaptive Sigmoid control in this embodiment detects risks through slow start, shortens the window through fast mid-range, and ensures stability through slow finish. It also combines PID and statistical tests to achieve dynamic speed regulation and circuit breaking, which has significant advantages in migration success rate, smoothness, and efficiency.

[0371] To address the cold start problem, this embodiment also proposes a hierarchical, quantified multidimensional warm-up algorithm to ensure that the application is in optimal readiness before receiving traffic.

[0372] Warm-up dimensions:

[0373] Computational warm-up: Primarily for JIT-compiled languages. The algorithm analyzes the application's API definitions (such as OpenAPI / Swagger documentation) or historical traffic logs to identify hotspot paths (the most frequently invoked code logic). It then generates a series of comprehensive requests covering these hotspot paths, forcing the JIT compiler to perform deep optimizations and native code generation in advance. The warm-up metrics are the time spent on JIT compilation and the length of the compilation queue; the goal is to bring both metrics close to zero.

[0374] Data preheating: This applies to all layers of application caching. The algorithm analyzes the application's cache configuration and data access patterns. For local caches, it simulates requests to populate them; for distributed caches, it connects directly to the cache service via scripts and executes commands such as SET or HMSET to preload frequently accessed data (such as configuration information, popular products, and user sessions) retrieved from the database. The preheating metric is cache hit rate, with the goal of reaching or approaching stable production levels.

[0375] Network warm-up: This applies to various connection pools. The algorithm concurrently initiates simulated requests, forcing the application to create TCP connections to downstream services (databases, message queues, other microservices) and complete authentication and session establishment. The warm-up metrics are the number of active connections and available connections for each connection pool, with the goal of reaching at least the configured minimum number of idle connections.

[0376] Optimization and Quantization Results: Each dimension of the algorithm provides adjustable parameters, such as the concurrency of warm-up requests, target cache hit rate, and target connection count. By implementing this algorithm, the following quantization effects can be achieved:

[0377] Eliminate first-packet latency: The response time of the first real request after migration is reduced from hundreds of milliseconds or even seconds during cold start to tens of milliseconds, which is no different from a normal request.

[0378] Avoid initial errors: Prevent a spike in error rates during the initial migration phase due to issues such as connection timeouts and uninitialized resources.

[0379] Quantitative results example: In a Java microservice migration scenario, the P99 latency of the first 100 requests for the target instance without preheating was 800ms; after multidimensional preheating, the P99 latency under the same conditions stabilized at 60ms, which was the same as that of the source instance.

[0380] This embodiment also provides a flexible and reliable consistency guarantee mechanism for the migration of stateful services.

[0381] Fine-grained control of pipeline stages: As mentioned earlier, the replication pipeline is divided into multiple stages such as snapshot, incremental, calibration, freeze, and switchover. The core of this mechanism lies in the precise control of the transitions between these stages.

[0382] Consistency Strategy Selector: During the migration planning phase, users can select different consistency levels based on business needs, and the controller will adjust the pipeline behavior accordingly.

[0383] Eventual Consistency: Suitable for applications that are not sensitive to data loss. In this mode, no write freeze window is set; after a traffic switch, the last few seconds of data may be lost. The Recovery Point Objective (RPO) is in the seconds.

[0384] Session consistency: Ensures that operations within a single user session are consistent after migration. This can be achieved by routing all subsequent requests from the same user to the target endpoint during traffic switching.

[0385] Strong Consistency: Guarantees zero data loss (RPO=0). In this mode, a brief write freeze window must be enabled to ensure that all in-transit write operations are synchronized to the target before switching.

[0386] Cross-ISA data alignment and verification:

[0387] Endianness Check: While logical replication can circumvent most problems, caution is still necessary in certain scenarios (such as transmitting custom binary data blocks). During data synchronization, a lightweight probe containing a specific byte pattern can be added. Upon receiving this data at the target end, its byte order is checked for correctness, thus verifying that the data path has correctly handled endianness conversion.

[0388] Data Validation: After catching up with incremental synchronization, a background data validation task can be started. This task will not block the migration; it will randomly select records from the source and target ends for hash comparison. If inconsistencies are found, it will log and issue an alert, but will not immediately stop the migration. Instead, it will allow administrators to intervene and determine the severity of the problem.

[0389] Snapshot Compression and Transmission Optimization: For terabyte-scale databases, the transmission of initial snapshots is a bottleneck. This mechanism integrates snapshot compression algorithms (such as LZ4 and Zstandard), compressing the snapshot at the source after it is generated, transmitting it over the network, and then decompressing and restoring it at the destination. This can improve the efficiency of initial synchronization by several times.

[0390] This embodiment also proposes a rollback closed-loop algorithm. Rollback is not just an action, but a complete closed-loop decision-making and execution process.

[0391] Decision-making process:

[0392] Trigger: The monitoring plane SLA daemon continuously evaluates performance. Once it reaches the rollback_thresholds defined in the policy library, it immediately sends a rollback request with detailed context (which metric, current value, threshold) to the control plane rollback controller via API.

[0393] Confirmation: Upon receiving a request, the rollback controller performs a rapid secondary confirmation, such as checking whether it is an isolated single-point glitch or whether multiple metrics deteriorate simultaneously. This prevents overreaction caused by transient jitter.

[0394] Tiered: The scope and speed of the rollback are determined based on the severity of the trigger. If it is a localized issue (such as a single instance failure), it may only trigger the reconstruction of that instance; if it is a global performance degradation, it will trigger a traffic rollback for the entire application.

[0395] Execution: Generate rollback plan, execute command data and traffic plane. The core is to call the canary controller to set the traffic weight back to the source at 100% as quickly as possible.

[0396] Verification: After traffic is switched back, the monitoring plane will immediately begin to verify the health status of the source service to ensure that the service has returned to normal.

[0397] Cleanup and Reporting: After confirming service recovery, the rollback controller will instruct the cleanup of failed resources on the target side (or isolate them for analysis) and generate a detailed rollback report that records the entire process of the event.

[0398] Self-healing strategy: In certain scenarios, the system can attempt self-healing instead of immediate rollback. For example, if a target instance is detected to be experiencing performance degradation due to a memory leak, the rollback controller can prioritize restarting the instance instead of switching all traffic back to the source. Only if the problem persists after restarting should a full rollback be initiated.

[0399] It should be noted that this embodiment does not treat the equivalent computing power model as a one-time, static query tool, but rather deeply couples it into the dynamic closed loop of the entire migration.

[0400] From point prediction to surface mapping: The equivalent computing power model can not only predict how many ARM instances a single x86 instance is equivalent to, but also provide a performance surface. This surface describes the relationship between resource allocation (CPU, memory), the number of replicas, and application performance (TPS, latency) on the target architecture: Performance = f(CPU, Memory, Replicas).

[0401] Coordinate descent optimization based on real-time metrics: During the migration process, the system obtains performance data of the target endpoint under real load. This data is used to perform online coordinate descent optimization on the performance surface.

[0402] For example, during initial planning, the model suggests a configuration of {CPU:6, Replicas:3}. When the canary deployment reaches 20%, the system detects high latency. At this point, instead of blindly increasing the CPU, the controller queries the performance surface model: under the current constraint of Replicas:3, how much latency improvement is expected from increasing the CPU to 7? Or, under the current constraint of CPU:6, what is the effect of increasing the number of replicas to 4? The model returns the most cost-effective adjustment suggestion (e.g., adding one replica is more efficient than increasing the CPU), and the controller performs replica shaping or resource adjustments accordingly.

[0403] The convergence process of computational power residuals: The computational power residuals calculated after migration are key nutrients for the model's self-evolution. By continuously feeding these residuals back to the model for retraining, the model becomes increasingly aware of the performance of specific applications on different architectures. For example, after multiple migrations of Java applications, the model may automatically learn the empirical rule that Java applications on ARM architecture typically require 30% more CPU than x86 to achieve equivalent JIT performance. This makes subsequent migration planning increasingly accurate, and the residuals gradually converge to zero.

[0404] This embodiment also proposes a hybrid scheduling strategy for heterogeneous environments.

[0405] Homogeneous scheduling is prioritized, while heterogeneous scheduling is corrected: When an application needs to scale up or recover from a failure, the global scheduler will prioritize finding a location on a node with the same ISA as its currently running instance (homogeneous scheduling), as this eliminates the need for cross-architecture migration and has the lowest cost. Cross-architecture migration will only be triggered when the homogeneous resource pool is insufficient or when there are explicit cost / energy efficiency optimization instructions.

[0406] Node selection using AIM / PAS: When a cross-architecture migration is determined to be necessary, the global scheduler delegates the task to the migration control plane of this invention. The AIM and PAS modules within the control plane take over the subsequent node selection process, ensuring that the selected nodes not only have sufficient resources but also are software compatible and offer optimal performance.

[0407] Performance balancing objective: In multi-cluster deployment scenarios, the goal of scheduling strategies is to maintain load balancing across resource pools of different architectures. For example, it avoids concentrating all low-latency applications on the x86 cluster while crowding all batch processing tasks onto the ARM cluster. The scheduler intelligently distributes applications across different architectures based on their performance profiles and business criticality, achieving risk diversification and resource complementarity.

[0408] To ensure decision-making quality while achieving second-level scheduling, this embodiment also employs a two-level distributed scheduling architecture.

[0409] Global Layer: The global scheduler runs on the core management node of the data center and has a view of the resources and load of all clusters and all nodes. The global layer intervenes when large-scale migrations or scheduling across regions or clusters are required (for example, regional migrations to achieve disaster recovery switching or in response to changes in electricity prices).

[0410] Constraint-based solution: It models the problem as a mixed-integer linear programming or dynamic programming problem. The objective function is to minimize the total operating cost (considering computing power, electricity, heat dissipation, network, etc.), and the constraints include application SLA, data affinity, compliance requirements, etc.

[0411] Output: The global layer does not directly determine which node the application will ultimately land on, but outputs a macro-level scheduling decision, such as migrating 50% of the instances of application A from the x86 cluster in region 1 to the ARM cluster in region 2.

[0412] LocalTier: Each cluster deploys a local scheduler responsible for executing the macro-level plans issued by the global scheduler. The local scheduler utilizes the PAS module of this invention for rapid intra-node scoring and placement, as well as replica reshaping based on real-time load.

[0413] Efficiency Analysis: This two-tier architecture separates complex, time-consuming global optimization (minute-level decision-making) from rapid, real-time local placement (second-level decision-making), balancing global optimization and local efficiency. In multi-region migration scenarios, the global scheduler first determines the optimal target region and cluster, and then the local scheduler quickly completes the placement of all instances within that cluster. The entire end-to-end scheduling decision-making time can be controlled within seconds.

[0414] The smooth migration capability of this embodiment can create a powerful synergy with the Serverless computing paradigm and elastic scaling mechanism.

[0415] Peak-valley prediction-based pre-migration / pre-warming: Load prediction models in cloud management platforms (e.g., based on time series analysis such as ARIMA or LSTM) can predict application load peaks within a future timeframe (e.g., one hour later). This system can leverage this prediction to proactively migrate a subset of instances from high-cost x86 architecture to low-cost ARM architecture before the peak arrives, ensuring sufficient pre-warming. When the traffic peak arrives, these warmed instances on the ARM architecture can be immediately deployed, thus handling peak loads at a lower cost.

[0416] Dynamic scaling and scaling linkage: When the application's automatic elastic scaling system detects the need to add instances, it can scale beyond just the nodes in the current ISA. HPA can be configured with a cross-architecture scaling strategy, for example: when the load exceeds 80%, prioritize scaling new instances in the ARM cluster. In this case, HPA will trigger the migration system of this invention to deploy the application on the target architecture in a new instance creation mode (rather than migrating existing instances). This essentially adds cross-architecture migration capability as a new dimension of elastic scaling.

[0417] Comparison of Cold Start and Hot Migration: In scenarios with sudden load surges, traditional Serverless platforms need to start a function or container instance from scratch on cold nodes, a process (cold start) that can take several seconds. This invention, through pre-migration and pre-warming, can maintain a certain number of hot standby instances on ARM nodes at all times. When a sudden load surge occurs, traffic can be directly switched to these hot instances, with a response speed indistinguishable from hot migration, providing a virtually imperceptible experience for users. This significantly improves the elastic scaling experience of Serverless platforms in heterogeneous environments.

[0418] To quantify the smoothness of the migration process, this embodiment also establishes a comprehensive indicator system.

[0419] Core indicators and their mathematical definitions:

[0420] TPS bias (ΔTPS): Measures the degree of decrease in throughput after migration. A smooth migration should result in ΔTPS close to 0.

[0421] Latency increment (ΔLatency): Measures the change in a core latency metric. A smooth migration should result in it being less than a very small positive value or negative (indicating a performance improvement).

[0422] Failure Rate: The failure rate of requests to the target application should be as close as possible to 0.

[0423] Connection Loss Rate: The percentage of connections that are interrupted due to unsuccessful connection transfer at the moment of handover. Should be 0.

[0424] Recovery Time Objective (RTO): The time required from the occurrence of a failure to the complete restoration of service on the source side when a rollback is performed. The objective is to keep it within minutes.

[0425] Recovery Point Objective (RPO): For stateful services, the amount of data loss due to migration or rollback, measured in time. Under a strong consistency strategy, the RPO should be 0.

[0426] Gray Window Duration: The total time from the arrival of the first batch of grayscale traffic to the completion of the 100% traffic transition. A smaller value is better while ensuring smoothness.

[0427] Data Sampling and Statistics: These metrics are collected at a high frequency (e.g., every second) by the monitoring plane and stored in a time-series database. The migration report will display the trend of these metrics in the form of a line graph throughout the migration window, thus visually demonstrating the smoothness of the migration process.

[0428] To ensure the reliability of the system in the production environment, this embodiment defines a strict pre-launch acceptance and testing process.

[0429] Testing phase:

[0430] Rehearsal: In a non-production environment, the migration process is executed completely using the same configuration and data replicas as the production environment. This phase aims to identify bugs and configuration errors in the process.

[0431] Canary Release: In a production environment, select a non-core application with low traffic and perform a real cross-architecture migration. This phase aims to verify the system's performance under real production network and load conditions.

[0432] Full rollout: After successful testing with a small amount of traffic, gradually open this capability to more applications.

[0433] Test scenarios: The test case library needs to cover various boundary and exceptional conditions, such as: migration under high load; migration during network jitter or interruption; migration when the target node's resources are exhausted; migration of stateful services under heavy writes; and manually triggering rollback during the migration process.

[0434] Acceptance criteria: The system can only be deemed to have passed acceptance if its smoothness index meets the preset SLA requirements in all core test scenarios.

[0435] When dealing with data and traffic across nodes and regions, security and compliance are of paramount importance.

[0436] Transmission security:

[0437] Encrypted links: All control commands and data transmitted between the three planes, as well as between the data and traffic planes and the infrastructure, must be encrypted using protocols such as TLS / SSL to prevent eavesdropping and tampering.

[0438] Data replication encryption: For data replication of stateful services (whether snapshots or CDC streams), the transport channel itself must also be encrypted.

[0439] Authentication and Authorization:

[0440] Key rotation: When system components communicate with each other via API, short-lived access tokens are used for authentication, and keys are rotated periodically to reduce the risk of key leakage.

[0441] The principle of least privilege: Each component is granted only the minimum permissions necessary to complete its task. For example, a data replication agent can only access the databases it needs to synchronize, and cannot access other databases.

[0442] Auditing and Tracking: All migration operations, including who initiated them, when they were initiated, which application was migrated, the results, and all automated decision-making processes, must be recorded in detail in an immutable audit log for security audits and compliance checks.

[0443] Cross-regional compliance: When migration involves data centers across different jurisdictions (e.g., migrating data from jurisdiction A to jurisdiction B), the system must comply with local data sovereignty regulations (such as GDPR). During the planning phase, the migration control plane checks compliance rules in the policy library, such as prohibiting the migration of application data containing personally identifiable information (PII) out of jurisdiction A, and constrains the scheduler's behavior accordingly.

[0444] Optionally, the system in this embodiment can be implemented and evolved in stages.

[0445] Phase 1: Stateless Service Migration. This phase begins with a smooth cross-architecture migration of stateless applications such as web servers and API gateways. This part does not involve complex data synchronization and allows for rapid verification of the system's core capabilities, such as the equivalent computing power model and adaptive traffic switching.

[0446] Phase Two: Migration of Stateful Services. Building on the success of Phase One, support for stateful services such as databases, caches, and message queues will be gradually introduced, with a focus on tackling technical challenges such as CDC (Consolidate Management), logical replication, and consistency guarantees.

[0447] Phase 3: Collaboration with Hardware Offloading. With the development of Data Processing Unit (DPU) and SmartNIC technologies, some migration burdens can be offloaded from the CPU to hardware. For example, traffic mirroring, data compression, encryption / decryption, and other operations can be performed on the SmartNIC, further reducing the impact of migration on application performance and improving migration efficiency.

[0448] The smooth migration capability of this embodiment is the foundation for building higher-level disaster recovery and active-active architectures.

[0449] Ordered failover across Availability Zones / Regions: This feature allows you to orchestrate multiple microservices of an application into a single migration unit based on their dependencies. When data center-level disaster recovery drills or failovers are required, you can trigger an ordered migration of the entire unit across Availability Zones (AZs) or Regions with a single click. The system ensures that downstream services migrate first, followed by upstream services, guaranteeing business continuity.

[0450] Disaster recovery consistency strategy: In a dual-active or multi-active architecture, the data synchronization module of this system can be used as the engine for data replication between sites, and provides flexible consistency strategy options (synchronous / asynchronous) to meet the RPO and RTO requirements in different scenarios.

[0451] The architecture demonstrated in this embodiment has good scalability and can support more types of runtime environments in the future.

[0452] Compatible with virtual machines / functions: In addition to containers, by developing corresponding adapters for virtualization platforms (such as QEMU / KVM) and function computing platforms, the migration control plane can uniformly orchestrate cross-architecture migrations of virtual machines and serverless functions.

[0453] Compatibility Layer and Binary Translation: In extreme cases, if an legacy application cannot provide a native version of the target ISA, binary translation technologies (such as QEMU user-mode or Rosetta2) can be introduced as a last resort. The migration system can run x86 applications on the target ARM node through a special runtime environment with an embedded binary translation layer. Although there will be a performance penalty, this provides a viable migration path for the most demanding applications.

[0454] In summary, this embodiment constructs a complete, efficient, and secure cross-architecture application smooth migration solution in a multi-core cloud environment through a three-plane collaborative architecture, a refined workflow state machine, a series of intelligent control algorithms and mechanisms, and deep integration with global scheduling and elastic scaling. It not only solves the core technical challenges of application migration in heterogeneous environments but also provides a solid foundation for cloud data centers to achieve higher resource efficiency, lower operating costs, and stronger business continuity, demonstrating significant commercial potential and broad application prospects.

[0455] To more clearly illustrate this invention, the following uses a typical web application—a product details microservice—as an example to detail the specific implementation process of smoothly migrating from an x86 architecture server to an ARM architecture server. This service is a stateful service, and its backend uses a MySQL database to store product information.

[0456] Step 1: Initiate migration and perception planning

[0457] Task acceptance steps: The administrator selects the product details microservice running on the x86 node through the cloud management platform UI, initiates a migration request to the ARM resource pool, and selects the SLA-guaranteed smooth migration strategy.

[0458] Perception and planning steps: The migration orchestrator in the migration control plane receives the request, creates a migration task, and the state machine enters the perception and planning state.

[0459] Computational equivalence step: The orchestrator queries the equivalent computational power predictor in the monitoring and model plane. The input is the resource profile of the product details microservice on the source x86 node (e.g., 4 vCPUs, 8GB memory, currently supporting 2000 TPS). Based on its machine learning model, the predictor outputs the estimated resource requirements to achieve equivalent performance (2000 TPS) on the target ARM architecture (e.g., requiring 6 ARM vCPUs and 8GB memory).

[0460] Image selection steps: The Automatic ISA Matching (AIM) module in the control plane starts, parses the service's deployment description file, confirms that a Linux / arm64 version image exists in its container image repository, and also confirms that the dependent MySQL database has an official ARM version. AIM confirms compatibility.

[0461] The Performance Aware Scheduling (PAS) module receives the ARM resource requirement (6 vCPUs, 8 GB) and begins scoring and selecting a target node within the target ARM cluster. It comprehensively evaluates the real-time CPU load, memory pressure, and network conditions of each node, ultimately selecting the node with the lowest load and the most abundant resources as the target.

[0462] Next, a detailed migration plan in JSON format is generated, which includes source / target instance information, selected target nodes, adapted ARM image addresses, and strategy parameters such as gray_release_curve:sigmoid.

[0463] Step 2: Target end preheating

[0464] Entering the preheating stage: The orchestrator drives the state machine to enter the target end preheating state.

[0465] Deployment Instance: Based on the migration plan, the control plane, instruction data, and traffic plane create containers for the product details microservice and a new MySQL database instance on the target ARM node.

[0466] Perform multi-dimensional warm-up: warm-up of the data and flow planes and startup of the probe module.

[0467] Computational warm-up: It sends a series of simulated API requests to the target service instance, covering core interfaces such as obtaining product details and querying inventory, forcing the Java Virtual Machine's JIT compiler to compile the hot-top code into efficient ARM native machine code.

[0468] Data preheating: It connects to the target's MySQL database and exports the IDs of the top 1000 most frequently accessed products from the source database. Then, it simulates requests for these products on the target side, thereby filling the application's internal Caffeine cache and external Redis cache with this hot data.

[0469] Network warm-up: It simulates concurrent requests, forcing the application to establish and maintain a healthy pool of database connections with the new ARMMySQL instance.

[0470] Warm-up Verification: The probes in the monitoring and model planes continuously monitor the target instance until the JIT compilation activity subsides, the cache hit rate reaches 95%, the database connection pool stabilizes, and the P99 response latency under simulated traffic is less than 50ms. At this point, the probes notify the control plane that the warm-up was successful.

[0471] Step 3: Data Synchronization

[0472] Entering the data synchronization phase: For this stateful service, the state machine enters the data synchronization state after successful warm-up.

[0473] Execute the replication pipeline: The CDC / snapshot replication module for the data and flow plane is started.

[0474] Initial snapshot: Perform an online snapshot (such as using mysqldump or storage tier snapshot) on the source x86 MySQL database and immediately restore it on the target ARM MySQL instance.

[0475] Incremental synchronization: The CDC agent starts, connects to and reads the binlog of the source MySQL database from the snapshot time point. It parses the binary events in the binlog into logical SQL statements (such as UPDATE products SET price=199 WHERE id=123).

[0476] Cross-ISA replay: These platform-independent SQL statements are sent to the target ARM MySQL instance for execution. This perfectly avoids data corruption issues that may occur between x86 and ARM due to differences in byte order (endianness).

[0477] Catching up delay: The CDC continues to monitor replication delay and waits for it to decrease to less than 1 second.

[0478] Step 4: Smooth Traffic Switching

[0479] Entering the switching phase: After the data synchronization catches up, the orchestrator drives the state machine to enter the smooth flow switching state.

[0480] Initiate grayscale scaling: The grayscale controller of the control plane command data and traffic plane begins to adjust the routing rules of the service mesh according to the Sigmoid curve.

[0481] Initial probing: First, direct 1% of production traffic to the pre-warmed target ARM instance.

[0482] Real-time monitoring and adaptive adjustment: The SLA guardian of the monitoring and model plane is started, and the SPRT sequential verification algorithm is used to analyze the P99 latency and error rate of the target instance at high frequency.

[0483] Scenario 1 (Normal): If the performance indicators remain stable within the SLA threshold, the guardian issues a health signal. Based on this (PID controller e(t) is positive), the adaptive flow orchestration controller in the control plane smoothly increases the flow rate to 5%, 10%, 20%, etc.

[0484] Scenario 2 (Performance Jitter): When the traffic increases to 50%, the target node experiences a sudden increase in network latency due to interference from other applications. The SLA guardian immediately detects the drift in P99 latency, and the derivative (D) term of the PID controller responds by immediately halting the increase in traffic, maintaining the ratio at 50%, and waiting for performance to recover.

[0485] Scenario 3 (Severe Degradation and Rollback): If latency continues to worsen and reaches the severe alarm threshold, the SLA guardian will trigger a rollback signal. The rollback controller in the control plane is activated, immediately instructing the canary controller to switch 100% of traffic back to the source x86 instance within 1 second, while simultaneously recording a fault report. Since the source is always online, services recover in a very short time.

[0486] Switching complete: Under normal circumstances, the flow rate ratio will eventually and smoothly reach 100% under the adaptive adjustment of the PID controller.

[0487] Step 5: Verification, Convergence, and Cleanup

[0488] Entering the verification and convergence phase: After 100% traffic switching is successful, the state machine enters the verification and convergence phase.

[0489] SLA reconciliation: The system enters a 15-minute observation period to continuously confirm that all SLA indicators are stably met under 100% production load.

[0490] Model optimization:

[0491] Eventual consistency guarantee: The control plane performs a very brief write freeze, suspending the application's writes to the source database, waiting for the CDC to synchronize the last few logs, and then completely switches the application's database connection configuration to the target ARM database, achieving RPO=0.

[0492] Computational residual: Monitoring data shows that to maintain the SLA, the target instance's average CPU utilization for stable operation is 5.5 vCPUs. The predicted utilization during the planning phase was 6 vCPUs. Therefore, the residual for this migration is -0.5 vCPUs.

[0493] Model Update: This residual is fed back to the equivalent computing power predictor, whose model parameters are fine-tuned based on this new real data point, making its cross-architecture performance predictions for Java applications more accurate in the future.

[0494] Entering the completion / cleanup phase: After the SLA reconciliation is passed, the state machine enters the completion / cleanup state.

[0495] Resource cleanup: Control plane command data and traffic plane execution connections are drained, gracefully closing all connections to the source x86 instance. According to the policy, the source instance is retained for 24 hours as a cold backup, after which it is automatically destroyed to release resources. The migration task completes successfully.

[0496] Through the above specific implementation methods, the present invention transforms a complex, high-risk cross-architecture stateful application migration into a fully automated, observable, adaptive, and SLA-guaranteed standardized process.

[0497] The method and system for smooth migration of cross-architecture applications in a multi-core cloud environment proposed in this embodiment have the following significant advantages compared with existing technologies:

[0498] Ensuring core business continuity and achieving truly smooth migration: The greatest advantage of this invention lies in achieving uninterrupted service during cross-architecture migration. Through mechanisms such as adaptive traffic orchestration, multi-dimensional preheating, and SLA closed-loop feedback control, it ensures that key performance indicators of the application (such as response latency and error rate) remain within the preset SLA thresholds throughout the entire migration window, and users are unaware of the migration process. This solves the core pain point of existing downtime migration or blue-green deployment solutions that cannot avoid business interruption or performance fluctuations.

[0499] Significantly improves data center resource efficiency and ROI: This invention breaks the binding between applications and specific hardware architectures, allowing cloud platforms to freely and dynamically schedule workloads between servers with different architectures such as x86 and ARM based on factors such as cost, energy efficiency, and performance. For example, energy-sensitive online services can be migrated to ARM servers, while compute-intensive tasks can be retained on x86 servers, thereby maximizing the overall cost-effectiveness and energy efficiency of the data center and reducing the total cost of ownership (TCO).

[0500] Achieving full automation and intelligence in the migration process significantly reduces operation and maintenance costs and risks: This invention encapsulates the complex migration process into a standardized state machine and automated control algorithms, replacing much of the manual operation in traditional migrations that relies on expert experience. From computing power assessment and node selection to data synchronization, traffic switching, and anomaly rollback, the entire process requires no human intervention. This not only greatly improves migration efficiency, but more importantly, through the precise execution and intelligent decision-making of the machine, it effectively avoids production accidents caused by human error, significantly reducing operation and maintenance risks.

[0501] Overcoming the Challenge of Online Migration of Stateful Services in Heterogeneous Environments: Migrating stateful services is a recognized challenge in the industry. This embodiment cleverly avoids problems caused by incompatibility of physical data formats (such as byte order) between different ISAs through an innovative Logical Layer Change Data Capture (CDC) mechanism. Combined with pipeline technologies such as snapshots, incremental synchronization, and brief write freezes, it can complete the smooth online migration of stateful services such as databases while ensuring strong data consistency (RPO=0).

[0502] Possessing self-learning and self-optimization capabilities, continuously improving decision-making accuracy: The equivalent computing power predictor and its computing power residual feedback learning closed loop introduced in this invention enable the system to self-evolve. The actual effect of each migration is used to calibrate and optimize the prediction model, allowing the system to gain an increasingly clear understanding of the performance of different applications under different architectures. This adaptive and self-optimizing characteristic ensures that the accuracy of migration planning continuously improves over time, which is unmatched by static rules or manual evaluation.

[0503] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of this application.

[0504] This embodiment also provides an application data migration apparatus for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0505] Figure 7 This is a structural block diagram of an application data migration apparatus according to an embodiment of this application, such as... Figure 7 As shown, the device includes:

[0506] The first acquisition unit 702 is used to acquire the target instruction set architecture indicated by the migration request in response to a migration request triggered by application data on the cloud platform. The migration request is used to indicate that the application data is migrated from the source node of the source instruction set architecture to the target node of the target instruction set architecture. The cloud platform includes at least two nodes with different instruction set architectures.

[0507] The second acquisition unit 704 is used to acquire the performance profile of the application data associated with the source node, wherein the performance profile is used to indicate the first load data of the application data running on the first resource configuration associated with the source instruction set architecture on the source node.

[0508] The prediction unit 706 is used to perform equivalent prediction on the target node based on the performance profile to obtain the second resource configuration associated with the target instruction set architecture, wherein the second load data of the target node running application data on the second resource configuration corresponds to the first load data.

[0509] Migration unit 708 is used to determine the target node from multiple nodes of the cloud platform based on the second resource configuration and migrate application data from the source node to the target node.

[0510] As an optional solution, prediction unit 706 includes:

[0511] The first acquisition module is used to acquire the number of transactions per second parameter of the application data running on the first resource configuration of the source node;

[0512] The first determining module is used to determine the target application type and target instruction set architecture corresponding to the application data from multiple configuration prediction models, wherein one configuration prediction model corresponds to one application type and one instruction set architecture.

[0513] The first input module is used to input the transaction count per second parameter into the target configuration prediction model to obtain the second resource configuration predicted by the target configuration prediction model. The target configuration prediction model is used to predict the application data of the target application type and the resource configuration required to achieve the transaction count per second parameter when running on the node of the target instruction set architecture.

[0514] As an optional solution, the device also includes:

[0515] The second acquisition module is used to acquire the number of computing resources and the number of instance replicas indicated by the second resource configuration when the response latency parameter of the target node is detected to be greater than the reference latency parameter during the process of migrating application data from the source node to the target node.

[0516] The second input module is used to input the number of computing resources, the number of instance replicas, and the response latency parameter into the configuration prediction model during the process of migrating application data from the source node to the target node, and to perform configuration adjustment operations to obtain the number of instance replicas after the response latency parameter is reduced by the first magnitude while keeping the number of computing resources unchanged, and to obtain the number of computing resources after the response latency parameter is reduced by the second magnitude while keeping the number of instance replicas unchanged.

[0517] The second determining module is used to determine the number of computing resources and the adjusted number of instance replicas as the adjusted second resource configuration when the first magnitude is greater than or equal to the second magnitude during the process of migrating application data from the source node to the target node.

[0518] The third determining module is used to determine the adjusted number of computing resources and the number of instance replicas as the adjusted second resource configuration when the first magnitude is less than the second magnitude during the process of migrating application data from the source node to the target node.

[0519] The first update module is used to update the resource configuration of the target node according to the adjusted second resource configuration during the process of migrating application data from the source node to the target node.

[0520] As an optional solution, the device also includes:

[0521] The training module is used to train and generate a corresponding configuration prediction model for each combination of application type and instruction set architecture before determining the target configuration prediction model corresponding to the target application type and target instruction set architecture of the application data from multiple configuration prediction models, thereby obtaining multiple configuration prediction models.

[0522] The device also includes:

[0523] The second update module is used to update the parameters of the target configuration prediction model according to the adjusted second resource configuration after updating the resource configuration of the target node according to the adjusted second resource configuration.

[0524] As an optional solution, migration unit 708 includes:

[0525] The fourth determination module is used to determine multiple candidate nodes whose resource configurations satisfy the second resource configuration from multiple nodes;

[0526] The evaluation module is used to perform migration evaluation for multiple candidate nodes based on their resource configuration and load status, and obtain a migration score for each candidate node.

[0527] The fifth determination module is used to determine the candidate node with the highest migration score among multiple candidate nodes as the target node.

[0528] As an optional solution, the device also includes:

[0529] The third acquisition module is used to, after determining multiple candidate nodes whose resource configuration satisfies the second resource configuration from multiple nodes, and in the case that the application data is a stateful application type, to acquire the data storage location associated with the application data and the node location of the multiple candidate nodes.

[0530] The sixth determining module is used to determine the target node after identifying multiple candidate nodes whose resource configuration satisfies the second resource configuration from multiple nodes;

[0531] The fourth acquisition module is used to acquire multiple network locations of multiple services associated with application data after determining multiple candidate nodes whose resource configurations satisfy the second resource configuration from multiple nodes, in the case that the application type is a multi-service interaction type.

[0532] The seventh determination module is used to determine the target node after identifying multiple candidate nodes whose resource configuration satisfies the second resource configuration from multiple nodes.

[0533] As an optional solution, the device also includes:

[0534] The eighth determination module is used to determine the traffic code path associated with the application data based on the historical traffic information of the application data before migrating the application data from the source node to the target node.

[0535] The first execution module is used to perform a first simulation operation on the target node before migrating application data from the source node to the target node. The first simulation operation is used to indicate the overlay traffic code path, generate multiple codes, and compile the code queue.

[0536] The fifth acquisition module is used to acquire hot data associated with the application data before migrating the application data from the source node to the target node;

[0537] The second execution module is used to perform a second simulation operation on the target node before migrating application data from the source node to the target node, wherein the second simulation operation is used to indicate the caching of hot data;

[0538] The sixth acquisition module is used to acquire multiple connection pools associated with the application data before migrating the application data from the source node to the target node;

[0539] The third execution module is used to perform a third simulation operation on the target node before migrating application data from the source node to the target node. The third simulation operation is used to instruct the establishment of multiple session connections between multiple connection pools and service objects associated with the application data.

[0540] As an optional solution, the device also includes:

[0541] The seventh acquisition module is used to acquire the first simulation indicator after the first simulation operation is completed before migrating application data from the source node to the target node. The first simulation indicator is used to indicate the generation time of multiple code generation and the queue length of the compiled code queue.

[0542] The eighth acquisition module is used to acquire the second simulation metric after the second simulation operation is completed before migrating application data from the source node to the target node. The second simulation metric is used to indicate the cache coverage of hot data.

[0543] The ninth acquisition module is used to acquire the third simulation metric after the third simulation operation is completed before migrating application data from the source node to the target node. The third simulation metric is used to indicate the number of idle session connections among multiple session connections.

[0544] The ninth determination module is used to determine whether the first simulation operation passes the simulation verification before migrating application data from the source node to the target node, provided that the generation time is less than a preset time and the queue length is less than a preset length.

[0545] The tenth determination module is used to determine whether the second simulation operation passes the simulation verification if the cache coverage is greater than a preset ratio before migrating application data from the source node to the target node.

[0546] The eleventh determination module is used to determine whether the third simulation operation passes the simulation verification if the number of connections is greater than a preset number before migrating application data from the source node to the target node.

[0547] The verification module is used to allow application data to be migrated from the source node to the target node, provided that the first, second, and third simulation operations have all passed the simulation verification.

[0548] As an optional solution, migration unit 708 includes:

[0549] The snapshot module is used to perform snapshot operations on application data, obtain a copy of the application data corresponding to the application data at the first point in time, and copy the copy of the application data to the target node;

[0550] The freeze module is used to perform a freeze operation on the application data of the source node when the replication of the application data is completed at the second time point. The freeze operation is used to indicate that the application data should not be changed within a expected period of time after the second time point.

[0551] The tenth acquisition module is used to acquire incremental application data obtained from changes in the application data sent by the source node between the first and second time points.

[0552] The replication module is used to replicate incremental application data to the target node within a specified time period.

[0553] As an optional solution, the device also includes:

[0554] The first switching module is used to switch the first access traffic of the first traffic size of the source node to the target node according to the first switching speed after the incremental application data is copied to the target node.

[0555] The second switching module is used to switch the second access traffic of the second traffic size of the source node to the target node according to the second switching speed after the incremental application data is copied to the target node.

[0556] The third switching module is used to switch the third access traffic of the third traffic size of the source node to the target node according to the first switching speed after the incremental application data is copied to the target node.

[0557] Among them, the first switching speed is less than the second switching speed, the first traffic size is less than the second traffic size, the third traffic size is less than the second traffic size, and the sum of the first traffic size, the second traffic size, and the third traffic size is the total traffic size of the source node.

[0558] As an optional solution, the device also includes:

[0559] The first calculation module is used to perform a proportional calculation on the delay difference according to a preset ratio parameter to obtain a first adjustment speed when, during the process of switching the second access traffic of the second traffic size of the source node to the target node according to the second switching speed, it is detected that the response delay parameter of the target node is less than the reference delay parameter and the delay difference between the response delay parameter and the reference delay parameter is greater than the reference delay difference.

[0560] The first adjustment module is used to increase the first adjustment speed based on the second switching speed during the process of switching the second access traffic of the second traffic size of the source node to the target node according to the second switching speed.

[0561] As an optional solution, the device also includes:

[0562] The second calculation module is used to perform an integral calculation on the delay difference between the response delay parameter and the reference delay parameter according to a preset integral parameter when the response delay parameter of the target node is detected to be continuously greater than the reference delay parameter during the preset time period, in the process of switching the second access traffic of the second traffic size of the source node to the target node according to the second switching speed, so as to obtain the second adjustment speed.

[0563] The second adjustment module is used to reduce the second adjustment speed based on the second switching speed during the process of switching the second access traffic of the second traffic size of the source node to the target node according to the second switching speed.

[0564] As an optional solution, the device also includes:

[0565] The third calculation module is used to perform differential calculation on the reference change amount according to the preset differential parameter to obtain the third adjustment speed when the second access traffic of the second traffic size of the source node is switched to the target node according to the second switching speed and the change rate of the response delay parameter of the target node is detected to be greater than the reference change rate within a preset time period.

[0566] The third adjustment module is used to reduce the third adjustment speed based on the second switching speed during the process of switching the second access traffic of the second traffic size of the source node to the target node according to the second switching speed.

[0567] As an optional solution, the first acquisition unit 702 includes:

[0568] The parsing module is used to parse the deployment description file corresponding to the application data to obtain the architecture tag of the container image of the application data;

[0569] The twelfth determination module is used to determine the instruction set architecture indicated by the architecture tag as the target instruction set architecture when an architecture image matching the architecture tag exists in the architecture image repository.

[0570] As an optional solution, the device also includes:

[0571] The prediction module is used to respond to migration requests triggered by application data on the cloud platform, and before obtaining the target instruction set architecture indicated by the migration request, to perform load prediction on the cloud platform for a reference time period, and obtain the predicted load parameters of the cloud platform for the reference time period.

[0572] The first triggering module is used to respond to the migration request triggered by the application data of the cloud platform. Before obtaining the target instruction set architecture indicated by the migration request, if the predicted load parameter is greater than the reference load parameter, it triggers multiple migration requests for multiple application data of the cloud platform. The multiple application data are application data on the nodes of the source instruction set architecture. The multiple migration requests are used to request the migration of the multiple application data to the nodes of the target instruction set architecture. The multiple application data includes application data.

[0573] As an optional solution, the device also includes:

[0574] The detection module is used to perform load detection on the source node before obtaining the target instruction set architecture indicated by the migration request in response to the migration request triggered by the application data of the cloud platform, and to obtain the node load parameters of the source node.

[0575] The second triggering module is used to trigger a migration request for the application data of the source node before obtaining the target instruction set architecture indicated by the migration request in response to the migration request triggered by the application data of the cloud platform, provided that the node load parameter is greater than the reference node load parameter. The migration request is used to request the migration of the application data to the target node, where the node load parameter of the target node is less than or equal to the reference node load parameter.

[0576] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0577] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of this application.

[0578] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0579] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above method embodiments when run.

[0580] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0581] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0582] In one exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0583] Embodiments of this application also provide a computer program product, including a non-volatile computer-readable storage medium storing the computer program product, wherein the computer program, when executed by a processor, implements the steps of the methods in various embodiments of this application.

[0584] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0585] Obviously, those skilled in the art should understand that the modules or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented here, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, this application is not limited to any particular combination of hardware and software.

[0586] The above are merely preferred embodiments of this application and are not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this application should be included within the protection scope of this application.

Claims

1. A migration method of application data, characterized by, include: In response to a migration request triggered by application data on a cloud platform, the target instruction set architecture indicated by the migration request is obtained, wherein the migration request is used to indicate the migration of the application data from a source node of the source instruction set architecture to a target node of the target instruction set architecture, and the cloud platform includes at least two nodes with different instruction set architectures. Obtain the performance profile associated with the application data on the source node, wherein the performance profile is used to indicate the first load data of the application data running on the source node under the first resource configuration associated with the source instruction set architecture; Based on the performance profile, an equivalent prediction is performed on the target node to obtain a second resource configuration associated with the target instruction set architecture, wherein the second load data of the target node running the application data on the second resource configuration corresponds to the first load data; Based on the second resource configuration, the target node is determined from multiple nodes of the cloud platform, and the application data is migrated from the source node to the target node; The method further includes, after migrating the application data from the source node to the target node, switching a first access traffic of a first traffic size from the source node to the target node at a first switching speed; and switching a second access traffic of a second traffic size from the source node to the target node at a second switching speed; wherein the first switching speed is less than the second switching speed, and the first traffic size is less than the second traffic size. The method further includes, during the process of switching the second access traffic of the second traffic size of the source node to the target node according to the second switching speed: If the response delay parameter of the target node is detected to be less than the reference delay parameter, and the delay difference between the response delay parameter and the reference delay parameter is greater than the reference delay difference, the delay difference is proportionally calculated according to a preset ratio parameter to obtain a first adjustment speed; based on the second switching speed, the second switching speed is increased according to the first adjustment speed to obtain an increased second switching speed; If it is detected that the response delay parameter of the target node is continuously greater than the reference delay parameter during a preset time period, the delay difference between the response delay parameter and the reference delay parameter is integrated according to a preset integration parameter to obtain a second adjustment speed; based on the improved second switching speed, the improved second switching speed is reduced according to the second adjustment speed to obtain a reduced improved second switching speed; If the rate of change of the response delay parameter of the target node is detected to be greater than the reference rate of change within a preset time period, the real-time change of the response delay parameter is differentially calculated according to the preset differential parameter to obtain a third adjustment speed; based on the reduced and improved second switching speed, the reduced and improved second switching speed is reduced again according to the third adjustment speed to obtain a further reduced second switching speed.

2. The method of claim 1, wherein, Based on the performance profile, an equivalent prediction is performed on the target node to obtain a second resource configuration associated with the target instruction set architecture, including: Obtain the number of transactions per second parameter of the application data running on the source node in the first resource configuration; The target application type and the target instruction set architecture corresponding to the application data are determined from multiple configuration prediction models, wherein one configuration prediction model corresponds to one application type and one instruction set architecture; The number of transactions per second parameter is input into the target configuration prediction model to obtain the second resource configuration predicted by the target configuration prediction model. The target configuration prediction model is used to predict and output the resource configuration required to achieve the number of transactions per second parameter when the application data of the target application type is run on the node of the target instruction set architecture.

3. The method of claim 2, wherein, In the process of migrating the application data from the source node to the target node, the method further includes: If the response latency parameter of the target node is detected to be greater than the reference latency parameter, the number of computing resources and the number of instance replicas indicated by the second resource configuration are obtained; The number of computing resources, the number of instance replicas, and the response latency parameter are input into the configuration prediction model to perform configuration adjustment operations, thereby obtaining the number of instance replicas after the response latency parameter is reduced by a first magnitude while keeping the number of computing resources unchanged, and the number of computing resources after the response latency parameter is reduced by a second magnitude while keeping the number of instance replicas unchanged. If the first magnitude is greater than or equal to the second magnitude, the number of computing resources and the adjusted number of instance replicas are determined as the adjusted second resource configuration; If the first magnitude is less than the second magnitude, the adjusted number of computing resources and the number of instance replicas are determined as the adjusted second resource configuration; Update the resource configuration of the target node according to the adjusted second resource configuration.

4. The method of claim 3, wherein, Before determining the target application type of the application data and the target configuration prediction model corresponding to the target instruction set architecture from multiple configuration prediction models, the method further includes: Using training samples, a corresponding configuration prediction model is trained for each combination of each application type and each instruction set architecture, resulting in the multiple configuration prediction models. After updating the resource configuration of the target node according to the adjusted second resource configuration, the method further includes: Based on the adjusted second resource configuration, the parameters of the target configuration prediction model are updated.

5. The method of claim 1, wherein, The target node is determined from multiple nodes of the cloud platform based on the second resource configuration, including: From the plurality of nodes, determine a plurality of candidate nodes whose resource configuration satisfies the second resource configuration; Based on the resource configuration and load status of the multiple candidate nodes, a migration evaluation is performed on the multiple candidate nodes to obtain a migration score for each candidate node; The candidate node with the highest migration score among the multiple candidate nodes is determined as the target node.

6. The method of claim 5, wherein, After determining multiple candidate nodes whose resource configurations satisfy the second resource configuration from the plurality of nodes, the method further includes: If the application type of the application data is a stateful application type, obtain the data storage location associated with the application data, and obtain the node location of the multiple candidate nodes; Among the plurality of candidate nodes, the candidate node whose node location is closest to the data storage location is determined as the target node; When the application type is a multi-service interaction type, obtain multiple network locations of multiple services associated with the application data; The candidate node whose location is closest to the average distance of the multiple candidate nodes in the network is determined as the target node.

7. The method according to claim 1, characterized in that, Before migrating the application data from the source node to the target node, the method further includes: Based on the historical traffic information of the application data, determine the traffic code path associated with the application data; A first simulation operation is performed on the target node, wherein the first simulation operation is used to instruct the overlay of the traffic code path, generate multiple codes, and compile a code queue; Obtain the hotspot data associated with the application data; A second simulation operation is performed on the target node, wherein the second simulation operation is used to instruct the caching of the hot data; Obtain multiple connection pools associated with the application data; A third simulation operation is performed on the target node, wherein the third simulation operation is used to instruct the establishment of multiple session connections between the multiple connection pools and the service objects associated with the application data.

8. The method according to claim 7, characterized in that, Before migrating the application data from the source node to the target node, the method further includes: Obtain a first simulation indicator after the first simulation operation is completed, wherein the first simulation indicator is used to indicate the generation time of the multiple code generation and the queue length of the compiled code queue; Obtain a second simulation metric after the second simulation operation is completed, wherein the second simulation metric is used to indicate the cache coverage of the hot data; Obtain a third simulation indicator after the third simulation operation is completed, wherein the third simulation indicator is used to indicate the number of idle session connections among the plurality of session connections; If the generation time is less than a preset time and the queue length is less than a preset length, the first simulation operation is determined to have passed the simulation verification. If the cache coverage is greater than a preset ratio, the second simulation operation is determined to have passed the simulation verification. If the number of connections is greater than a preset number, the third simulation operation is determined to have passed simulation verification. If the first simulation operation, the second simulation operation, and the third simulation operation all pass the simulation verification, the application data is allowed to migrate from the source node to the target node.

9. The method according to claim 1, characterized in that, The process of migrating the application data from the source node to the target node includes: Perform a snapshot operation on the application data to obtain a copy of the application data corresponding to the application data at the first time point, and copy the copy of the application data to the target node; If the replication of the application data is completed at the second time point, a freeze operation is performed on the application data of the source node, wherein the freeze operation is used to indicate that the application data is prohibited from being modified within a expected time period after the second time point; Obtain incremental application data obtained from the changes in the application data sent by the source node between the first time point and the second time point; Within the expected time period, the incremental application data will be copied to the target node.

10. The method according to claim 9, characterized in that, After migrating the application data from the source node to the target node, the method further includes: According to the first switching speed, the third access traffic of the third traffic size of the source node is switched to the target node; Wherein, the third traffic size is less than the second traffic size, and the sum of the first traffic size, the second traffic size and the third traffic size is the total traffic size of the source node.

11. The method according to any one of claims 1 to 10, characterized in that, The target instruction set architecture for obtaining the migration request indication includes: Parse the deployment description file corresponding to the application data to obtain the architecture tag of the container image of the application data; If an architecture image matching the architecture tag exists in the architecture image repository, the instruction set architecture indicated by the architecture tag is determined as the target instruction set architecture.

12. The method according to any one of claims 1 to 10, characterized in that, Before obtaining the target instruction set architecture indicated by the migration request in response to a migration request triggered by application data on the cloud platform, the method further includes: The cloud platform is load-predicted for a reference time period to obtain the predicted load parameters of the cloud platform for that reference time period. When the predicted load parameter is greater than the reference load parameter, multiple migration requests are triggered for multiple application data on the cloud platform. The multiple application data are application data on the nodes of the source instruction set architecture. The multiple migration requests are used to request the migration of the multiple application data to the nodes of the target instruction set architecture. The multiple application data includes the application data.

13. The method according to any one of claims 1 to 10, characterized in that, Before obtaining the target instruction set architecture indicated by the migration request in response to a migration request triggered by application data on the cloud platform, the method further includes: The load of the source node is detected to obtain the node load parameters of the source node; When the load parameter of the source node is greater than the load parameter of the reference node, the migration request is triggered on the application data of the source node. The migration request is used to request the migration of the application data to the target node, where the load parameter of the target node is less than or equal to the load parameter of the reference node.

14. An application data migration device, characterized in that, include: The first acquisition unit is used to acquire the target instruction set architecture indicated by the migration request in response to the migration request triggered by the application data of the cloud platform. The migration request is used to indicate that the application data is migrated from the source node of the source instruction set architecture to the target node of the target instruction set architecture. The cloud platform includes at least two nodes with different instruction set architectures. The second acquisition unit is used to acquire the performance profile of the application data associated with the source node, wherein the performance profile is used to indicate the first load data of the application data running on the first resource configuration associated with the source instruction set architecture on the source node. The prediction unit is used to perform equivalent prediction on the target node based on the performance profile to obtain the second resource configuration associated with the target instruction set architecture, wherein the second load data of the target node running application data on the second resource configuration corresponds to the first load data; The migration unit is used to determine the target node from multiple nodes on the cloud platform based on the second resource configuration, and to migrate application data from the source node to the target node; The migration unit is further configured to switch the first access traffic of the source node with a first traffic size to the target node according to a first switching speed; and to switch the second access traffic of the source node with a second traffic size to the target node according to a second switching speed; wherein the first switching speed is less than the second switching speed, and the first traffic size is less than the second traffic size; The migration unit is further configured to, when it detects that the response delay parameter of the target node is less than the reference delay parameter and the delay difference between the response delay parameter and the reference delay parameter is greater than the reference delay difference, perform a proportional calculation on the delay difference according to a preset proportional parameter to obtain a first adjustment speed; and increase the second switching speed according to the first adjustment speed based on the second switching speed to obtain an improved second switching speed. If it is detected that the response delay parameter of the target node is continuously greater than the reference delay parameter during a preset time period, the delay difference between the response delay parameter and the reference delay parameter is integrated according to a preset integration parameter to obtain a second adjustment speed; based on the improved second switching speed, the improved second switching speed is reduced according to the second adjustment speed to obtain a reduced improved second switching speed; If the rate of change of the response delay parameter of the target node is detected to be greater than the reference rate of change within a preset time period, the real-time change of the response delay parameter is differentially calculated according to the preset differential parameter to obtain a third adjustment speed; based on the reduced and improved second switching speed, the reduced and improved second switching speed is reduced again according to the third adjustment speed to obtain a further reduced second switching speed.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the method according to any one of claims 1 to 13.

16. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 13.

17. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 13.

Images