An artificial intelligence-based multi-cloud architecture automatic migration method

Abstract

The application discloses a kind of based on artificial intelligence's multi-cloud architecture automatic migration method, it is related to data processing technical field, the method includes: automatically identifying application system in source cloud environment, resource composition and component dependency information are collected, application architecture model is constructed, and using agent analysis model calculation migratable evaluation index of representation migration complexity and business influence;Dynamic strategy information is introduced, combined with application architecture model and migratable evaluation index, the migration strategy of generation stage is generated, and the migration implementation of application system in multi-cloud environment is guided.The application solves the technical problem that existing multi-cloud environment migration method relies on manual configuration, cannot handle complex dependency relationship, leads to low efficiency, high risk and poor adaptability in migration process, achieves based on artificial intelligence's multi-cloud architecture automatic migration, dynamically optimizes resource allocation and migration decision, improves migration efficiency and adaptability, and reduces migration risk technical effect.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and more specifically to an automatic migration method for multi-cloud architectures based on artificial intelligence. Background Technology

[0002] With the widespread adoption of cloud computing technology, more and more enterprises are deploying their application systems in cloud environments. Multi-cloud architectures, due to their high availability, flexibility, and disaster recovery capabilities, have become the primary choice for enterprise cloud deployment. However, migrating application systems between multi-cloud environments faces numerous challenges. Traditional migration methods often rely on manual configuration and adjustments, which are inefficient, risky, and unable to dynamically adapt to changes in resources and strategies. Furthermore, the migration process requires consideration of complex factors such as resource dependencies, migration costs, performance impact, and business continuity, all of which increase the difficulty of migration. Summary of the Invention

[0003] This application provides an AI-based automatic migration method for multi-cloud architectures to address the technical problems of existing multi-cloud environment migration methods that rely on manual configuration, cannot handle complex dependencies, and result in low efficiency, high risk, and poor adaptability during the migration process.

[0004] This application provides an AI-based automatic migration method for multi-cloud architectures. The method includes: automatically identifying application systems in the source cloud environment, collecting resource composition and component dependency information of the application systems, and constructing an application architecture model based on the collected results; analyzing migration objects in the application architecture model using an intelligent agent based on predefined migration strategy rules and historical migration data, and calculating a portability assessment index reflecting migration complexity and business impact; introducing dynamic strategy information representing the resource status and strategy constraints of the multi-cloud environment into the intelligent agent; and generating migration decision results to guide the application systems to migrate in a multi-cloud environment based on the application architecture model, the portability assessment index, and the dynamic strategy information. The migration decision results include a phased migration strategy, and specify a corresponding execution time window and rollback strategy for each migration phase.

[0005] One or more technical solutions provided in this application have at least the following technical effects or advantages: This application provides an AI-based automatic migration method for multi-cloud architectures, relating to the field of data processing technology. It constructs an application architecture model by automatically identifying the resources and dependencies of the application system, and uses an intelligent agent to assess migration complexity based on predefined rules and historical data. It dynamically introduces resource states and policy constraints of the multi-cloud environment to generate phased migration strategies and execution plans, supporting fine-grained migration and containerized adaptation. This method solves the technical problems of existing multi-cloud environment migration methods that rely on manual configuration, cannot handle complex dependencies, and result in low efficiency, high risk, and poor adaptability. It achieves AI-based automatic migration of multi-cloud architectures, dynamically optimizes resource allocation and migration decisions, improves migration efficiency and adaptability, and reduces migration risks. Attached Figure Description

[0006] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0007] Figure 1 A schematic diagram of an automatic migration method for multi-cloud architecture based on artificial intelligence is provided for an embodiment of this application; Figure 2 This is a flowchart illustrating the process of calculating a portability assessment index that reflects the complexity of migration and the degree of business impact in an AI-based automatic migration method for multi-cloud architectures, as provided in an embodiment of this application. Detailed Implementation

[0008] This application provides an AI-based automatic migration method for multi-cloud architectures to address the technical problems of existing multi-cloud environment migration methods that rely on manual configuration, cannot handle complex dependencies, and result in low efficiency, high risk, and poor adaptability during the migration process.

[0009] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0010] It should be noted that the terms "first," "second," etc., in the specification 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 "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server 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 modules not explicitly listed or inherent to such processes, methods, products, or devices.

[0011] Example 1, as Figure 1 As shown, this application provides an automatic migration method for multi-cloud architectures based on artificial intelligence, the method comprising: P10: Automatically identify application systems in the source cloud environment, collect the resource composition and component dependency information of the application systems, and build an application architecture model based on the collection results.

[0012] Furthermore, step P10 in this embodiment of the application also includes: P11: By parsing the resource list, orchestration configuration file, and runtime metadata of the source cloud environment, the set of application components constituting the application system is identified, and the computing resource information, storage resource information, and network configuration parameters corresponding to each application component are extracted; P12: The service discovery information, access logs, call chain data, or configuration reference relationships of the application component set are analyzed to generate dependency data representing the call relationships and resource dependencies between components; P13: The computing resource information, storage resource information, network configuration parameters, and dependency data are uniformly structured to construct the application architecture model, wherein the application architecture model includes at least component nodes, resource attributes, and inter-component dependency edges.

[0013] Optionally, by automatically identifying application systems in the source cloud environment, collecting their resource composition and component dependency information, and building an application architecture model based on the collection results, detailed support can be provided for subsequent migration decisions.

[0014] First, the resource inventory, orchestration configuration files, and runtime metadata in the source cloud environment are analyzed. This data is fundamental to understanding the application system architecture. The resource inventory typically contains information on all available resources in the cloud environment, such as compute instances, storage resources, and network interfaces. Orchestration configuration files describe how resources are combined and deployed, usually using formats like YAML or JSON to define resource coordination and dependencies. Runtime metadata contains dynamic status information about the application during actual operation, such as resource usage and load distribution. By analyzing this information, the various application components in the source cloud environment can be identified. These components include microservices, virtual machines, and containers. The composition of each application component and its dependencies can be initially understood through analyzing the resource inventory and configuration files.

[0015] This process further extracts detailed resource information for each application component, including computing resources, storage resources, and network configuration parameters. Computing resource information refers to the computing power required by the application component, such as CPU and memory; storage resource information involves the storage type and capacity used by the application component, which may include block storage, file storage, etc.; network configuration parameters include network bandwidth, subnet configuration, IP address, and other network settings. Through this resource information collection process, a more comprehensive understanding of the resource requirements of each application component can be obtained.

[0016] Subsequently, a deeper analysis of the application component set is conducted to generate dependency data representing the call relationships and resource dependencies between components. For example, this analysis can be achieved by parsing service discovery information, access logs, call chain data, and configuration reference relationships. First, service discovery information is obtained from the service discovery mechanism of the source cloud environment. For instance, in a microservice architecture, the service discovery registry records instance information, service ports, health status, etc., of each service component. This information can be obtained through API calls or direct access to the service discovery registry's database, and the dependencies between services can be analyzed. Simultaneously, access logs of the application components are collected. These logs record the interaction behavior between components. Therefore, key information such as the source IP address of the request, the target service name, and the request timestamp can be extracted from the logs using log parsing tools, and the call relationships between components can be analyzed based on this information.

[0017] Furthermore, call chain data is obtained through a distributed tracing system. This data details the call order and paths between components. Therefore, the call chain data is parsed to extract nodes and edges, and features such as call chain depth and branch count are analyzed to assess complex dependencies between components. Finally, the configuration files of application components are analyzed to extract configuration references. For example, the configuration file of service A may contain information such as the address and port of service B, indicating that service A needs to reference service B at runtime. By parsing the format of the configuration files and extracting these references, and by comprehensively analyzing service discovery information, access logs, call chain data, and configuration references, comprehensive dependency data can be generated. This data helps the system accurately depict the interdependencies between each application component and other components, thus providing necessary support for building the application architecture model.

[0018] Finally, the computational resource information, storage resource information, network configuration parameters, and dependency data extracted in the above steps are uniformly structured to construct an application architecture model. For example, a component node is created for each application component. This node contains basic information such as the component's unique identifier, name, and type. Computational resource information, storage resource information, and network configuration parameters are appended to the corresponding component node as resource attributes. Simultaneously, dependency edges are created between component nodes based on the dependency data, representing the call relationships and resource dependencies between components. Then, the call chains, service discovery information, access logs, and configuration references in the dependency data are analyzed to determine the dependency direction and strength between components, and appropriate weights are assigned to the dependency edges. Finally, all component nodes and dependency edges are integrated into a unified graph structure to form the application architecture model. During the integration process, the model is optimized, for example, by eliminating redundant dependency edges and merging component nodes with the same dependencies, to improve the model's simplicity and readability. This structured application architecture model enables the system to intuitively display the resource requirements of each application component and their dependencies, thus providing accurate data support for subsequent migration analysis.

[0019] Furthermore, in this embodiment of the application, step P10 further includes generating dependency data representing the call relationships and resource dependencies between components: P12-1: Determine the service call direction between application components based on the call chain data, and use the call frequency or call latency as a dependency weight to characterize the service dependency strength; P12-2: Determine the resource dependency relationship of the application components on middleware, database or storage resources according to the configuration reference relationship; P12-3: Integrate the service call direction, dependency weight and resource dependency relationship to generate a weighted dependency graph as the dependency relationship data, which is used to characterize the component dependency information of the application system.

[0020] Specifically, the process of generating dependency data can be further refined.

[0021] First, the service call direction between application components is determined based on call chain data. Call chain data records the propagation path of each request between different components, including the request initiator, receiver, and call order. By parsing this call chain data, the call direction between each component can be clearly identified, i.e., the call relationship from one component to another. For example, if a request originates from component A, passes through component B, and finally reaches component C, then the system can determine the service call direction: A calls B, and B calls C.

[0022] To more accurately characterize service dependency strength, call frequency or call latency is further used as dependency weights. Call frequency reflects the frequency of calls between components, while call latency reflects the response time of the call. Therefore, by statistically analyzing call chain data, the call frequency and average call latency of each call relationship are calculated, and these indicators are used as dependency weights to assign to the corresponding service call directions. For example, if component A calls component B frequently and with short call latency, then the call relationship from A to B can be assigned a high dependency weight, indicating that A's dependency on B is strong.

[0023] Next, the resource dependencies of application components on middleware, databases, or storage resources are determined based on configuration references. Configuration references refer to references made by components to other resources in their configuration files. For example, an application component might specify the database address to connect to, the middleware service port, and other information in its configuration file. Therefore, by parsing these configuration files, the dependencies of components on middleware, databases, or storage resources can be extracted. For example, if component A's configuration file contains connection information to database service D, then it can be determined that A has a resource dependency on D. By analyzing the format and content of the configuration files, all relevant resource dependency information can be extracted and integrated with service call direction and dependency weight.

[0024] Finally, the service call direction, dependency weights, and resource dependencies are integrated to generate a weighted dependency graph as dependency data. A weighted dependency graph is a graph structure where nodes represent application components, edges represent call relationships or resource dependencies between components, and the weights on the edges indicate the dependency strength. Therefore, by integrating the service call direction, dependency weights, and resource dependencies obtained from the above analysis into a single graph structure, a complete weighted dependency graph can be constructed. For example, a directed edge between node A and node B indicates that A calls B, and the weight of the edge is determined based on the call frequency or call latency. Simultaneously, if A depends on database D, there will also be an edge from A to D in the graph, representing a resource dependency. This weighted dependency graph can intuitively represent the component dependency information of the application system, providing important basis for subsequent migration analysis and decision-making. Especially in multi-cloud environments, this graph can help technical personnel identify key components and resource dependencies that may cause problems during the migration process, ensuring that the migration strategy fully considers these factors, thereby minimizing migration risks and optimizing the migration process.

[0025] P20: Based on predefined migration strategy rules and historical migration data, the agent analyzes the migration objects in the application architecture model and calculates a portability assessment index that reflects the migration complexity and the degree of business impact.

[0026] Furthermore, such as Figure 2 As shown, step P20 in this embodiment further includes: P21: Extract the technical complexity and dependency characteristics of the migration object based on the application architecture model; P22: Apply weight adjustments or threshold restrictions to the technical complexity and dependency characteristics according to predefined migration strategy rules to generate a strategy-constrained migration complexity assessment result; P23: Calculate the migration risk correction factor corresponding to the migration object characteristics based on historical migration data; P24: Apply the migration risk correction factor to the strategy-constrained migration complexity assessment result to obtain the portability assessment index, which reflects migration complexity, resource coupling, and business criticality.

[0027] It should be understood that the first step is to extract the technical complexity and dependency characteristics of the migration object based on the application architecture model. Technical complexity characteristics include the number of components in the migration object, the depth of calls between components, the type of middleware used, and the types of storage resources involved. For example, an application system containing multiple microservices with deep call depth has high technical complexity. Dependency characteristics mainly describe the resource coupling between components, call frequency, and the degree of mutual dependence between components, including the number of dependencies between components, dependency strength (such as call frequency and call latency), and the degree of dependence on critical resources. By extracting these characteristics, a comprehensive understanding of the technical complexity of each migration object and its dependencies on other components can be obtained.

[0028] Subsequently, based on predefined migration strategy rules, the weights of technical complexity features and dependency features are adjusted or thresholds are set. The core of this process is to appropriately adjust each feature according to the migration strategy rules to meet different migration scenarios or business needs. These predefined migration strategy rules are formulated based on actual business needs and migration goals. For example, for migration tasks with high business continuity requirements, features dependent on critical resources may be assigned higher weights. Therefore, the weights of each feature can be adjusted according to these rules; for example, the weight of database dependency features can be set to a higher value, while the weight of non-core component dependency features can be set to a lower value. Simultaneously, thresholds can be set; for example, when the call depth of a component exceeds a certain threshold, its technical complexity is directly assessed as high. Through these weight adjustments and threshold settings, a migration complexity assessment result constrained by the strategy is generated, ensuring that the assessment result meets business strategy requirements.

[0029] Next, migration risk correction factors corresponding to the characteristics of the migration target are calculated based on historical migration data. Historical migration data records information such as the success rate of past migration tasks, problems encountered, and solutions. By analyzing this historical data, historical cases similar to the characteristics of the current migration target can be identified, and corresponding migration risk correction factors can be calculated. For example, if a specific dependency or technical complexity characteristic has frequently led to migration failure or significant problems in past migrations, the corresponding risk correction factor can be increased to reflect the potential risks of these factors. The calculation of the correction factor can be based on statistical analysis methods, such as determining it by calculating the ratio of the migration success rate of similar characteristics in historical migration tasks to the average migration complexity.

[0030] Finally, the migration risk correction factor is applied to the strategy-constrained migration complexity assessment result to obtain the portability assessment index. The portability assessment index comprehensively reflects migration complexity, resource coupling, and business criticality. The final portability assessment index can be obtained by performing mathematical operations on the correction factor and the migration complexity assessment result, such as multiplication or weighted summation. For example, if the migration complexity assessment result indicates high complexity, but the migration risk correction factor indicates a low failure rate for similar historical migration tasks, then the final portability assessment index may be appropriately reduced to reflect the feasibility and risk of the actual migration.

[0031] This process enables precise assessment of the portability of the target object, providing detailed data support for migration decisions. This assessment not only considers technical complexities but also fully takes into account risk factors in historical migration data, ensuring that potential risks are effectively mitigated, resource allocation is optimized, and the success rate of migration is improved during the actual migration process.

[0032] Furthermore, step P21 in this embodiment of the application also includes: P21-1: Based on the application architecture model, obtain the component scale information, runtime environment configuration information, and resource consumption information corresponding to the migration object, which are used to characterize the technical implementation complexity of the migration object; P21-2: Based on the component dependency relationship in the application architecture model, obtain the number of call relationships, dependency direction, and dependency level between the migration object and other components, which are used to characterize the dependency characteristics of the migration object.

[0033] Optionally, the process of extracting the technical complexity and dependency characteristics of migration objects from the application architecture model is further refined.

[0034] First, based on the application architecture model, information on the component scale, runtime environment configuration, and resource consumption of the migration object is obtained. This data is used to characterize the technical implementation complexity of the migration object. Specifically, first, by analyzing the component nodes in the application architecture model, the component scale information of the migration object is extracted, including the number and type of components (such as microservices, containers, virtual machines, etc.), and scale indicators for each component, such as lines of code and number of modules. For example, for an application system based on a microservice architecture, the number of microservices included in the migration object and the number of lines of code for each microservice can be counted to assess the complexity of its technical implementation. Next, runtime environment configuration information is extracted, including parameters such as operating system version, middleware type and version, and runtime environment configuration. For example, it records whether the operating system running on the migration object is Linux or Windows, whether the middleware used is Apache or Nginx, and specific configuration parameters such as thread pool size and connection pool configuration. In addition, resource consumption information is obtained, including the usage of computing resources, storage resources, and network resources by the migration object during operation. For example, monitoring tools can be used to obtain information such as the average CPU usage, memory consumption, disk I / O read / write speed, and network bandwidth usage of the migrated object. This information collectively characterizes the technical complexity of the migrated object.

[0035] Next, based on the component dependencies in the application architecture model, the number of call relationships, dependency directions, and dependency levels between the migrated object and other components are obtained. These data are used to characterize the dependency characteristics of the migrated object. The number of call relationships indicates the frequency of interaction between the migrated object and other components; frequent call relationships usually mean a strong dependency between the migrated object and other components, requiring special attention to their impact during migration. The dependency direction reveals the dependency flow between components; understanding the dependency direction helps decision-makers avoid migration conflicts or resource contention caused by unidirectional dependencies. The dependency level reflects the depth and complexity of the dependencies between components; a higher dependency level usually means greater complexity and risk in the migration, as it requires handling more intermediate layers and complex dependency chains.

[0036] For example, the first step is to analyze the weighted dependency graph in the application architecture model to count the number of direct and indirect calls between the migrated object and other components. For instance, this involves calculating the number of components directly called by the migrated object and the number of times it is called by other components, thus obtaining the number of call relationships. Next, the dependency direction is determined, clarifying whether the migrated object calls other components (positive dependency), is called by other components (reverse dependency), or has a bidirectional call relationship. For example, by analyzing the call chain data, it can be determined that component A calls component B, and component C calls component A, thus clarifying the dependency direction. Furthermore, the dependency hierarchy needs to be evaluated to determine the migrated object's position in the dependency chain. For example, if the migrated object directly depends on component B, and component B depends on component C, then there is an indirect dependency between the migrated object and component C, and the system will record this dependency hierarchy. Through these analyses, the dependency characteristics of the migrated object can be comprehensively characterized, providing reliable data support for subsequent migration complexity assessment.

[0037] Furthermore, in the extraction of dependency features, step P21 of this embodiment also includes: P21-3: Based on the application architecture model, analyze the dependency information of the migration object on the source cloud platform's proprietary interfaces, proprietary services, or proprietary operating environment, identify the vendor lock-in characteristics in the migration object, and mark the vendor lock-in characteristics as part of the dependency characteristics or technical complexity characteristics for migration constraint marking, and use them as deduction items for the calculation of the portability evaluation index.

[0038] Optionally, when extracting the dependency characteristics of the migrated object, this application not only focuses on the calling relationships and resource dependencies between components, but also specifically analyzes the dependency information of the migrated object on the source cloud platform's proprietary interfaces, proprietary services, or proprietary runtime environment.

[0039] Specifically, the first step is to analyze the dependencies of the migrated object on the source cloud platform's proprietary interfaces, services, or runtime environments based on the application architecture model. The source cloud platform's proprietary interfaces and services are typically specific functions and resources provided by the platform vendor; for example, some cloud platforms may have their own storage interfaces, computing services, or load balancing mechanisms. These proprietary functions or services are often tightly integrated with a specific vendor's cloud environment, so compatibility issues or situations where they cannot be directly reused may arise when migrating to other cloud platforms. Proprietary runtime environments refer to the runtime environment configurations unique to certain cloud platforms, such as customized operating systems, cloud infrastructure configurations, and network settings. If the migrated object depends on these proprietary services and environments, the migration process will be more complex because equivalent services need to be found or reconfigured on the new cloud platform.

[0040] Analyzing this dependency information allows for the further identification of vendor lock-in characteristics in the migration object. Vendor lock-in refers to a deep dependency of the migration object on a specific cloud platform, which may lead to compatibility issues or increased migration costs. For example, if the migration object uses proprietary APIs of the source cloud platform for core functionality or depends on specific cloud service features, these characteristics will be considered vendor lock-in. By analyzing component configurations and dependencies in the application architecture model, these characteristics can be identified and recorded as part of the dependency characteristics or technical complexity characteristics.

[0041] To reflect the impact of vendor lock-in characteristics in migration assessments, identified vendor lock-in characteristics are marked as migration constraints. This means that vendor lock-in characteristics are considered a limiting factor in the migration process and require special consideration. For example, components using proprietary APIs of the source cloud platform can be marked as having high migration constraints, indicating that these components require special attention and handling during migration. Since vendor lock-in typically leads to increased migration costs and extended migration time, it will be used as a deduction item in subsequent migrationability assessment index calculations.

[0042] Finally, vendor lock-in characteristics are used as a deduction item in the calculation of the portability assessment index. When calculating the portability assessment index, the portability of the migration object can be deducted based on the severity and scope of the vendor lock-in characteristics. For example, if the migration object is highly dependent on proprietary services of the source cloud platform, and these services are unavailable on the target cloud platform or require extensive redevelopment, corresponding points are deducted from the portability assessment index to reflect the negative impact of this dependency on migration complexity and business impact.

[0043] Through the above process, this application can ensure that the migration object's dependence on the proprietary features of the source cloud platform is fully considered in the migration assessment, thereby more accurately assessing the feasibility and risks of migration and effectively avoiding migration problems caused by vendor lock-in.

[0044] P30: Introduce dynamic policy information that characterizes the resource status and policy constraints of the multi-cloud environment into the agent.

[0045] Furthermore, step P30 in this embodiment of the application also includes: P31: Collect resource status information of each cloud region in multiple target cloud environments, including computing resource availability, storage resource availability, and network performance indicators; P32: Collect policy constraint information related to the target cloud environment, including cost constraints, compliance constraints, or availability constraints; P33: Perform unified structured processing on the resource status information and the policy constraint information to generate dynamic policy information that characterizes the current operating status and policy conditions of the multi-cloud environment. Introduce the dynamic policy information into the agent to constrain or adjust the selection of the target cloud environment or the timing of migration during the migration decision-making process.

[0046] Specifically, dynamic policy information can be introduced to characterize the resource status and policy constraints of a multi-cloud environment, thereby enabling more precise adjustments and optimizations to migration decisions.

[0047] First, by interacting with the API interfaces of the target cloud environments, resource status information for each cloud region within multiple target cloud environments is collected. This resource status information includes the availability of computing resources, such as the number of CPU cores, memory capacity, and current utilization; the availability of storage resources, such as storage capacity, storage type, and I / O performance metrics; and network performance metrics, including network bandwidth, latency, and packet loss rate. By collecting this information, the resource carrying capacity of each target cloud environment can be understood in real time, providing basic data for migration decisions.

[0048] Next, policy constraint information related to the target cloud environment is collected. This policy constraint information mainly includes multi-dimensional constraints such as cost constraints, compliance constraints, and availability constraints. Cost constraints refer to the cost limits of cloud resources, such as budget caps and cost optimization strategies; compliance constraints include laws and regulations, industry standards, and compliance requirements, which may involve issues such as data privacy protection and data sovereignty; availability constraints refer to the availability requirements of services, such as the requirements for service uptime, fault tolerance, and high availability during the migration process. By collecting this policy constraint information, it is possible to ensure that migration decisions meet actual business needs and external constraints, avoiding potential risks caused by violations of constraints.

[0049] Then, the collected resource status information and policy constraint information undergo unified structural processing. This involves integrating the resource status and constraints of multiple cloud environments in a standardized form, facilitating analysis and use by the agent during decision-making. Specifically, this information can be organized and stored according to a predefined data structure to generate dynamic policy information characterizing the current operating state and policy conditions of the multi-cloud environment. For example, resource status information and policy constraint information can be integrated into a unified data model, where resource status information is organized by cloud region, and policy constraint information is categorized and stored according to categories such as cost, compliance, and availability. In this way, dynamic policy information can present the current state and constraints of the multi-cloud environment in a clear and standardized form, making it easier for the agent to access and process during migration decisions.

[0050] Finally, dynamic policy information is introduced into the agent. During migration decision-making, the agent can utilize this dynamic policy information to constrain or adjust the selection of the target cloud environment or the timing of migration. For example, when selecting a target cloud environment, the agent will assess the applicability of different cloud environments based on resource status and cost constraints in the dynamic policy information, prioritizing cloud regions with sufficient resources and lower costs. When determining the migration timing, the agent will consider network performance indicators and availability constraints, selecting a time period with good network conditions and minimal impact on business operations for migration. By introducing dynamic policy information, the agent can obtain the status and constraints of multiple cloud environments in real time, thereby making more reasonable migration decisions that meet business needs. For example, if computing resources are scarce in one cloud region while another region has abundant computing resources, the agent may tend to choose the latter for migration or adjust the migration timing to avoid migration during periods of resource scarcity. Guided by dynamic policy information, migration decisions become more flexible and efficient, helping to reduce risks during the migration process and improve business continuity and system stability.

[0051] P40: Based on the application architecture model, the portability assessment index, and the dynamic strategy information, generate migration decision results to guide the application system to migrate in a multi-cloud environment. The migration decision results include a phased migration strategy, and specify a corresponding execution time window and rollback strategy for each migration phase.

[0052] It should be understood that migration decisions are generated based on application architecture models, portability assessment indices, and dynamic policy information to guide application systems in migrating to multi-cloud environments. For example, with the goal of minimizing total migration cost and performance fluctuations, a phased, grouped dynamic migration plan is generated using a multi-objective optimization algorithm, specifying execution time windows and rollback strategies for each migration phase.

[0053] Specifically, the process first integrates application architecture models, portability assessment indices, and dynamic policy information, providing comprehensive input for migration decisions. The application architecture model details the component composition, dependencies, and resource requirements of the application system; the portability assessment indices reflect the complexity, resource coupling, and business criticality of each migration object; and the dynamic policy information provides the resource status and policy constraints of the multi-cloud environment, including cost constraints, compliance constraints, and availability constraints.

[0054] Based on these inputs, a multi-objective optimization algorithm is used to generate migration decisions. The goal of the multi-objective optimization algorithm is to minimize the total migration cost and performance jitter. The total migration cost includes resource usage costs, migration operation costs, and potential business interruption costs. Performance jitter refers to the impact on application performance during the migration process, such as increased response time or decreased throughput.

[0055] Next, a suitable multi-objective optimization algorithm is selected, such as a genetic algorithm, particle swarm optimization, or simulated annealing. These algorithms can simultaneously optimize multiple objectives and find the optimal balance between them. For example, a genetic algorithm can be chosen to simulate the process of natural selection, generating multiple possible migration plans. These plans are then gradually optimized through crossover, mutation, and selection operations to ultimately find the optimal solution that satisfies the objectives—the optimal migration plan. For instance, during the optimization process, a portability evaluation index is used as the weight for each migration object, prioritizing the migration of objects with higher portability. Simultaneously, the migration plan is adjusted based on the resource status and policy constraints in the dynamic policy information. For example, computing, storage, and network resources are rationally allocated based on the resource availability of the target cloud environment to ensure efficient resource utilization during the migration process. For cost constraints, lower-cost resource solutions are prioritized; for compliance constraints, the migration plan is ensured to meet relevant standards; and for availability constraints, migration is scheduled during off-peak business periods to minimize the impact on operations.

[0056] After the migration plan is generated, the entire migration process is broken down into multiple phases. Each phase targets a specific migration task or group of migration objects, and a grouping strategy is developed based on the portability assessment index, resource dependencies, and business priorities of the migration objects. For example, migration objects with higher portability assessment indices are grouped into a priority migration group and migrated first; migration objects with complex dependencies are scheduled for later phases to reduce dependency conflicts during the migration process. The dynamic migration plan also considers real-time feedback and adjustment mechanisms during the migration process, enabling real-time adjustments to the migration strategy based on dynamic changes in the multi-cloud environment, such as changes in resource status and fluctuations in network performance, to ensure a smooth migration process.

[0057] While generating the migration plan, an execution time window is specified for each migration stage. The determination of the execution time window can be based on factors such as network performance metrics, availability constraints, and off-peak business periods from dynamic policy information. For example, by analyzing the network performance metrics of the target cloud environment, a time period with sufficient network bandwidth and low latency can be selected as the migration time window. Simultaneously, considering business availability constraints, migration operations should be avoided during peak business periods to minimize the impact on business performance. Furthermore, the time window arrangement can be further refined based on the priority and dependencies of the migration objects. For example, high-priority migration objects can be scheduled for migration earlier in the time window to ensure rapid migration and recovery of critical business operations.

[0058] Simultaneously, to address potential failures or anomalies during the migration process, corresponding rollback strategies are developed for each migration stage. Rollback strategies are a crucial component of the migration safeguards. When developing rollback strategies, factors such as the resource dependencies of the migrated objects, the state of migrated components, and the resource recovery capabilities of the target cloud environment need to be considered. For example, if a component fails to migrate during the process, the system will, according to the rollback strategy, restore the migrated component to its original state in the source cloud environment, or perform necessary resource cleanup and reconfiguration in the target cloud environment. Rollback strategies should also include measures to protect business data, ensuring data integrity and consistency in the event of migration failure. For example, critical data can be backed up before migration, and the backup data can be used to restore the data state during the rollback process.

[0059] The final output of the migration decision includes a phased migration strategy, i.e., how to allocate migration tasks to different phases according to priority and complexity; the execution time window for each migration phase to ensure migration occurs at the appropriate time to optimize resource utilization and avoid performance issues; and a rollback strategy to ensure timely recovery and avoid further losses in case of problems during the migration process. Through this multi-dimensional, multi-phase migration plan, the system can achieve a more efficient and low-risk migration process in a multi-cloud environment.

[0060] Furthermore, after generating migration decision results to guide the application system in migrating to a multi-cloud environment, step P40 in this embodiment of the application further includes: P41: Based on the phased migration strategy, through a unified abstraction adaptation layer decoupled from the underlying cloud platform, computing resources, storage resources, and network resources are sequentially supplied and configured in the target cloud environment using a declarative interface. P42: Through the standardized data plane provided by the unified abstraction adaptation layer, bidirectional real-time synchronization of application component business data is maintained between the source cloud environment and the target cloud environment during the migration process. P43: Based on the phased migration strategy, migration execution operations of the migration objects are triggered stage by stage according to the corresponding execution time windows. P44: During the execution of each migration stage, the running status, resource usage, and business indicator information of the migration objects in the source cloud environment and the target cloud environment are collected in real time to monitor the execution effect of the current migration stage. Specifically, when the monitoring results meet the preset stage completion conditions, the current migration stage is confirmed as complete and the next migration stage is triggered. When the monitoring results do not meet the preset stage completion conditions, a migration rollback operation is automatically executed according to the rollback strategy corresponding to the migration decision results.

[0061] Optionally, after generating migration decision results to guide the application system to migrate in a multi-cloud environment, computing resources, storage resources and network resources can be supplied and configured sequentially in the target cloud environment in a declarative interface manner based on a phased migration strategy and a unified abstraction adaptation layer decoupled from the underlying cloud platform.

[0062] Specifically, the Unified Abstraction Adaptation Layer provides a standardized interface that allows systems to declaratively describe their resource requirements without directly interacting with the underlying cloud platform's specific APIs. For example, a resource configuration file can be defined to declare the computing resources required for each migration stage, such as the number of CPU cores and memory size; storage resources, such as storage capacity and performance requirements; and network resources, such as bandwidth and subnet configuration. Upon receiving these declarations, the Unified Abstraction Adaptation Layer automatically translates these requirements into instructions recognizable by the underlying cloud platform, thereby sequentially supplying and configuring the corresponding resources in the target cloud environment. This decoupling approach not only improves the flexibility of the migration process but also reduces dependence on specific cloud platforms.

[0063] Next, through the standardized data plane provided by the unified abstraction adaptation layer, bidirectional real-time synchronization of application component business data is maintained between the source and target cloud environments during the migration process. Data synchronization is a critical step in the migration process, ensuring that data in the source and target environments remains consistent throughout. Bidirectional real-time synchronization means that data transmission between the source and target cloud environments is continuous, updating almost in real time, while allowing data interaction and synchronization between the two sides. In other words, the standardized data plane provides a unified data transmission and synchronization mechanism, ensuring that business data between the source and target cloud environments can be synchronized in real time and accurately during the migration process. For example, data synchronization tools, such as database replication tools and file synchronization services, can be used to establish data channels between the source and target cloud environments to achieve bidirectional synchronization of business data. This near real-time synchronization mechanism ensures that data in the target cloud environment remains consistent with that in the source cloud environment during the migration process, thereby reducing the impact of the migration on business operations.

[0064] Then, based on the phased migration strategy, the migration execution operations of the objects to be migrated are triggered stage by stage according to the corresponding execution time windows. That is, before the start of each migration stage, the corresponding migration operation is automatically triggered according to the time window specified in the migration decision results. For example, if the migration decision results specify that the execution time window for a certain migration stage is from 8 pm to 10 pm, the system will automatically start the migration task for that stage at 8 pm. During the migration process, the execution progress of the migration tasks is monitored in real time, and dynamic adjustments are made as needed. This phased, sequentially triggered migration method can effectively reduce the risk of resource conflicts and business interruptions during the migration process.

[0065] Simultaneously, during each migration phase, the system collects real-time data on the operational status, resource usage, and business metrics of the migrated object in both the source and target cloud environments to monitor the effectiveness of the current migration phase. Specifically, monitoring tools, such as cloud platform monitoring services and custom monitoring scripts, are used to collect real-time data on the migration object's operational status (e.g., service status, log information), resource usage (e.g., CPU utilization, memory consumption), and business metrics (e.g., response time, throughput). The effectiveness of each migration phase is evaluated based on preset monitoring metrics and thresholds. For example, if monitoring results show that the migration object's response time in the target cloud environment meets expectations and resource usage is normal, the current migration phase is considered to be performing well. When the monitoring results meet preset phase completion conditions, the current migration phase is confirmed as complete, and the next migration phase is automatically triggered. For instance, if the completion condition for a migration phase is that the migration object runs stably in the target cloud environment for 10 minutes and business metrics are normal, then after these conditions are met, the current phase is confirmed as complete, and the next migration phase is initiated.

[0066] When monitoring results fail to meet preset stage completion conditions, a migration rollback operation can be automatically executed according to the corresponding rollback strategy in the migration decision results. The rollback strategy is a crucial component of the migration decision results, providing safeguards against failures or anomalies at each migration stage. For example, if monitoring results show abnormal resource usage of the migrated object in the target cloud environment, leading to a decline in business performance, the migrated object can be automatically rolled back from the target cloud environment to the source cloud environment according to the rollback strategy. The rollback operation includes restoring the configuration state of the migrated object, cleaning up resources in the target cloud environment, and restoring business data. By automatically executing the rollback operation, normal business operations can be quickly restored, reducing the impact of migration failures on business operations.

[0067] Furthermore, before providing and configuring computing, storage, and network resources sequentially in the target cloud environment through a unified abstraction adaptation layer decoupled from the underlying cloud platform using a declarative interface, step P41 of this application embodiment also includes: P41-1: Based on the resource requirement characteristics of the migration objects in the application architecture model, analyze the types and specifications of the migration objects' requirements for computing resources, storage resources, and network resources. P41-2: Map the migration objects to the available resource capabilities in the target cloud environment to generate cross-cloud resource mapping relationships. P41-3: Based on the cross-cloud resource mapping relationships, perform unified abstraction on the descriptions of resource types, resource specifications, and resource attributes in different cloud platforms to generate a unified resource abstraction model that is independent of specific cloud platforms. The unified resource abstraction model is used to support subsequent migration decision generation and migration execution based on the unified abstraction adaptation layer.

[0068] In one possible embodiment of this application, the key preparatory work prior to provisioning and configuring resources in the target cloud environment can be further refined.

[0069] Specifically, before supplying and configuring resources via a declarative interface through a unified abstraction adaptation layer decoupled from the underlying cloud platform, it is necessary to analyze the resource requirement characteristics of the migration objects in the application architecture model, and to analyze the types and specifications of their requirements for computing, storage, and network resources. For example, this can be achieved by parsing the component nodes and their resource attributes in the application architecture model, extracting the specific resource requirements for each migration object, including computing resources such as the number of CPU cores and memory size; storage resources such as storage capacity and storage type; and network resources such as bandwidth and network latency requirements. These requirements are then categorized and organized to form a detailed list of resource requirements, for example, identifying a migration object that requires a 4-core CPU, 8GB of memory, 100GB of SSD storage, and 100Mbps of network bandwidth.

[0070] Subsequently, the resource requirements of the migration target are mapped to the available resource capabilities in the target cloud environment. This involves matching the resource requirements in the source cloud environment with the corresponding resource capabilities in the target cloud environment to generate a cross-cloud resource mapping relationship. For example, firstly, resource status information for each cloud region in the target cloud environment is obtained through API interaction, including the availability of compute, storage, and network resources. Next, based on the resource requirement list of the migration target, resources that meet the requirements in the target cloud environment are matched. For example, a compute instance with 4 CPU cores and 8GB of memory, and 100GB of SSD storage resources, are found in the target cloud environment. Finally, the resource requirements of the migration target are mapped to the resource capabilities in the target cloud environment to generate a cross-cloud resource mapping relationship, ensuring that the migration target can find suitable resource support in the target cloud environment.

[0071] Next, based on cross-cloud resource mapping relationships, the descriptions of resource types, specifications, and attributes across different cloud platforms are uniformly abstracted to generate a unified resource abstraction model independent of specific cloud platforms. This involves defining a standardized resource description format to uniformly abstract resource types, specifications, and attributes across different cloud platforms. For example, computing resources across different cloud platforms are uniformly abstracted as the number of CPU cores and memory size; storage resources are uniformly abstracted as storage capacity and storage type; and network resources are uniformly abstracted as bandwidth and latency. Through this unified resource abstraction model, the system can describe computing, storage, and network resources in a unified way, thereby simplifying the complexity of cross-cloud migration and providing support for subsequent migration decision generation and migration execution.

[0072] To further ensure a smooth migration process, an adaptation layer based on a container orchestration platform can be introduced. This adaptation layer implements migration execution through a containerized unified abstraction adaptation layer. Specifically, the unified abstraction adaptation layer uses the standard interface of an open-source container orchestration platform (such as Kubernetes) as the control plane, encapsulating application components as containerized workloads. For example, a web service component can be encapsulated as a Docker container, and a Deployment object can be defined in Kubernetes to manage the container's lifecycle. Containerized workloads can be seamlessly migrated across different cloud platforms without directly calling the private APIs of different cloud service providers, reducing dependence on specific cloud platform interfaces and thus improving the flexibility and operability of migration.

[0073] During the migration process, migration operations are transformed into cross-cloud scheduling, replica scaling, and storage volume binding operations for containerized workloads. For example, the Kubernetes scheduler schedules container workloads to appropriate nodes in the target cloud environment and dynamically adjusts the number of replicas based on resource requirements. Cross-cloud scheduling ensures that containerized application components are scheduled to appropriate compute nodes in the target cloud environment according to resource needs; replica scaling ensures that application components can automatically scale according to load changes, maintaining application availability and performance; and storage volume binding ensures that data storage during the migration process is correctly bound to storage resources in the target cloud platform. This process avoids directly calling cloud service provider's private APIs, making the migration process more standardized, automated, and better adaptable to different cloud platform environments.

[0074] Through this series of steps, the resource requirements in the source cloud environment can be effectively mapped to the target cloud environment. At the same time, the migration process is simplified and the efficiency and flexibility of migration execution are improved by using a unified resource abstraction model and a containerized unified abstraction adaptation layer.

[0075] Furthermore, step P43 in this embodiment of the application also includes: P43-1: The migration execution operation supports component-level fine-grained migration. When the migration object is a monolithic application, the agent recognizes it as a whole component for migration. P43-2: When the migration object is a microservice architecture application, the agent uses a single microservice or a group of services with strong dependencies as the smallest migration unit, allowing different units to be planned and migrated to the target cloud environment independently.

[0076] Specifically, the flexibility and fine-grained control of migration execution operations can be further refined, especially when dealing with different architecture types, to ensure the flexibility and efficiency of migration.

[0077] First, the migration operation supports fine-grained component-level migration. When the object to be migrated is a monolithic application, the agent recognizes the application as a single component for migration. Monolithic applications typically refer to traditional applications that integrate all functional modules into a single application instance. In this case, the migration operation migrates the entire monolithic application as a whole, ensuring that all components, resources, and dependencies are migrated to the target cloud environment. Because monolithic applications have strong internal coupling, there is no need to split them during migration; the migration decision focuses on the resource configuration and deployment strategy of the entire application. For example, a traditional monolithic web application, including front-end, back-end, and database modules, will be migrated by the agent as a whole, ensuring that they can work together in the target cloud environment and maintain the normal operation of the application.

[0078] When migrating a microservices architecture application, the agent uses a single microservice or a group of services with strong dependencies as the smallest migration unit, allowing different units to be migrated to the target cloud environment independently. In other words, a microservices architecture decomposes the application into multiple independent services, each responsible for specific business functions and capable of independent deployment and scaling. In this case, the agent can identify the dependencies between microservices and use them as the smallest migration unit. For example, an e-commerce application might contain multiple microservices such as user services, order services, and payment services. If there are strong dependencies between them, the agent can migrate the user service as a separate migration unit, or migrate the order and payment services as a group of services. This fine-grained migration approach allows different units to be migrated independently to the target cloud environment, thus improving the flexibility and efficiency of the migration. For example, migration time windows can be scheduled based on the priority, resource requirements, and business impact of each microservice, thereby optimizing the entire migration process.

[0079] Through this process, this application can adopt different migration strategies based on application type, thereby providing a more flexible and efficient migration process. For monolithic applications, overall migration can ensure simplified decision-making and reduce the complexity of migration; while for microservice architectures, migration by service or service group can flexibly handle dependencies between application modules and reduce potential conflicts or dependency issues during migration.

[0080] In summary, the embodiments of this application have at least the following technical effects: This application automates and intelligently assesses migration complexity by automatically identifying application architecture and dependencies, reducing manual intervention and improving migration efficiency and accuracy. It introduces dynamic policy information to adapt to resource status and policy constraints in multi-cloud environments in real time, enhancing the flexibility and adaptability of the migration plan and ensuring a smooth migration process. It supports fine-grained migration of monolithic applications and microservice architectures, allowing for independent planning and execution of migration units, improving migration flexibility and resource utilization. Through multi-objective optimization algorithms, it balances migration costs and performance fluctuations, generating optimal migration strategies and effectively reducing migration costs and business risks. Finally, it utilizes containerization technology to standardize cross-cloud scheduling and resource management, reducing dependence on specific cloud platforms and improving the scalability and compatibility of migration.

[0081] It achieves the technical effect of automatic migration of multi-cloud architecture based on artificial intelligence, dynamically optimizing resource allocation and migration decisions, improving migration efficiency and adaptability, and reducing migration risks.

[0082] It should be noted that the order of the embodiments described above is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. Furthermore, the above description focuses on specific embodiments of this specification. Additionally, the processes depicted in the accompanying drawings do not necessarily require a specific or sequential order to achieve the desired results. In some implementations, multitasking and parallel processing are possible or may be advantageous.

[0083] The above description is only a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

[0084] This specification and accompanying drawings are merely illustrative examples of this application and are intended to cover any and all modifications, variations, combinations, or equivalents within the scope of this application. Clearly, those skilled in the art can make various alterations and modifications to this application without departing from its scope. Therefore, if such modifications and variations fall within the scope of this application and its equivalents, this application intends to include such modifications and variations.

Claims

1. An automatic migration method for multi-cloud architecture based on artificial intelligence, characterized in that, include: Automatically identify application systems in the source cloud environment, collect the resource composition and component dependency information of the application systems, and build an application architecture model based on the collection results; Based on predefined migration strategy rules and historical migration data, an intelligent agent is used to analyze the migration objects in the application architecture model and calculate a portability assessment index that reflects the migration complexity and the degree of business impact. Dynamic policy information representing the resource status and policy constraints of a multi-cloud environment is introduced into the intelligent agent; Based on the application architecture model, the portability assessment index, and the dynamic strategy information, a migration decision result is generated to guide the application system to migrate in a multi-cloud environment. The migration decision result includes a phased migration strategy, and specifies a corresponding execution time window and rollback strategy for each migration phase.

2. The automatic migration method for multi-cloud architecture based on artificial intelligence according to claim 1, characterized in that, Automatically identify application systems in the source cloud environment, collect resource composition and component dependency information of the application systems, and construct an application architecture model based on the collected results, including: By parsing the resource list, orchestration configuration file and runtime metadata of the source cloud environment, the set of application components that constitute the application system is identified, and the computing resource information, storage resource information and network configuration parameters corresponding to each application component are extracted. The service discovery information, access logs, call chain data, or configuration reference relationships of the application component set are analyzed to generate dependency data representing the call relationships and resource dependencies between components; The computing resource information, storage resource information, network configuration parameters, and dependency data are uniformly structured to construct the application architecture model, wherein the application architecture model includes at least component nodes, resource attributes, and inter-component dependency edges.

3. The automatic migration method for multi-cloud architecture based on artificial intelligence according to claim 2, characterized in that, Generate dependency data representing the call relationships and resource dependencies between components, including: Based on the call chain data, the service call direction between application components is determined, and the call frequency or call latency index is used as the dependency weight to characterize the service dependency strength. Determine the resource dependencies of application components on middleware, database, or storage resources based on configuration reference relationships; The service call direction, dependency weight, and resource dependency relationship are integrated to generate a weighted dependency graph as the dependency data, which is used to characterize the component dependency information of the application system.

4. The automatic migration method for multi-cloud architecture based on artificial intelligence according to claim 1, characterized in that, Based on predefined migration strategy rules and historical migration data, an intelligent agent analyzes the migration objects in the application architecture model and calculates a portability assessment index that reflects the complexity of migration and the degree of business impact, including: Based on the application architecture model, extract the technical complexity and dependency characteristics of the migration objects; According to predefined migration strategy rules, weight adjustments or threshold restrictions are applied to the technology complexity features and dependency features to generate a migration complexity evaluation result constrained by the strategy. Calculate migration risk correction factors corresponding to the characteristics of the migration object based on historical migration data; The migration risk correction factor is applied to the policy-constrained migration complexity assessment result to obtain the portability assessment index, which reflects migration complexity, resource coupling, and business criticality.

5. The automatic migration method for multi-cloud architecture based on artificial intelligence according to claim 4, characterized in that, Based on the application architecture model, the technical complexity and dependency characteristics of the migration objects are extracted, including: Based on the application architecture model, obtain the component scale information, runtime environment configuration information and resource consumption information corresponding to the migration object, which are used to characterize the technical implementation complexity of the migration object. Based on the component dependencies in the application architecture model, the number of call relationships, dependency directions, and dependency levels between the migrated object and other components are obtained to characterize the dependency features of the migrated object.

6. The automatic migration method for multi-cloud architecture based on artificial intelligence according to claim 5, characterized in that, Extracting dependency features also includes: Based on the application architecture model, the dependency information of the migration object on the source cloud platform's proprietary interfaces, proprietary services, or proprietary operating environment is analyzed, the vendor lock-in characteristics in the migration object are identified, and the vendor lock-in characteristics are marked as part of the dependency characteristics or technical complexity characteristics for migration constraint marking, and used as a deduction item for the calculation of the portability evaluation index.

7. The automatic migration method for multi-cloud architecture based on artificial intelligence according to claim 1, characterized in that, The agent incorporates dynamic policy information characterizing the resource state and policy constraints of a multi-cloud environment, including: Collect resource status information of each cloud region in multiple target cloud environments. The resource status information includes computing resource availability, storage resource availability, and network performance indicators. Collect policy constraint information related to the target cloud environment, including cost constraints, compliance constraints, or availability constraints. The resource status information and the policy constraint information are processed in a unified structure to generate dynamic policy information that characterizes the current operating status and policy conditions of the multi-cloud environment. The dynamic policy information is introduced into the agent to constrain or adjust the selection of the target cloud environment or the timing of migration of the migration object during the migration decision process.

8. The automatic migration method for multi-cloud architecture based on artificial intelligence according to claim 1, characterized in that, After generating migration decision results to guide application systems in migrating to a multi-cloud environment, the following are included: Based on the phased migration strategy, through a unified abstract adaptation layer decoupled from the underlying cloud platform, computing resources, storage resources and network resources are supplied and configured sequentially in the target cloud environment in a declarative interface manner. Through the standardized data plane provided by the unified abstraction adaptation layer, bidirectional real-time synchronization of application component business data between the source cloud environment and the target cloud environment is maintained during the migration process; Based on the phased migration strategy, the migration execution operation of the migration object is triggered in stages according to the corresponding execution time window. During the execution of each migration phase, the running status, resource usage, and business metrics of the migration object in the source cloud environment and the target cloud environment are collected in real time to monitor the execution effect of the current migration phase. When the monitoring results meet the preset phase completion conditions, the current migration phase is confirmed to be completed and the next migration phase is triggered. When the monitoring results do not meet the preset phase completion conditions, the migration rollback operation is automatically executed according to the rollback strategy corresponding to the migration decision results.

9. The automatic migration method for multi-cloud architecture based on artificial intelligence according to claim 8, characterized in that, Before providing and configuring computing, storage, and network resources sequentially in the target cloud environment via a unified abstraction adaptation layer decoupled from the underlying cloud platform and using a declarative interface, it also includes: Based on the resource requirement characteristics of the migration objects in the application architecture model, the types and specifications of the migration objects' requirements for computing resources, storage resources, and network resources are analyzed. The migration object is mapped to the available resource capabilities in the target cloud environment to generate a cross-cloud resource mapping relationship; Based on the cross-cloud resource mapping relationship, the descriptions of resource types, resource specifications and resource attributes in different cloud platforms are uniformly abstracted to generate a unified resource abstraction model that is independent of specific cloud platforms. The unified resource abstraction model is used to support the generation of subsequent migration decisions and the execution of migration based on the unified abstraction adaptation layer.

10. The automatic migration method for multi-cloud architecture based on artificial intelligence according to claim 8, characterized in that, The migration execution operation supports component-level fine-grained migration. When the migration object is a monolithic application, the agent recognizes it as a whole component for migration. When the migration target is a microservice architecture application, the agent uses a single microservice or a group of services with strong dependencies as the smallest migration unit, allowing different units to be planned and migrated to the target cloud environment independently.

Images