Atlas-based multi-cloud network resource operation method, system, device and medium

Abstract

This application provides a graph-based multi-cloud network resource operation method, system, device, and medium. The method includes the following steps: collecting network resource data from multiple heterogeneous cloud environments; parsing the data into general resource objects through mapping logic, constructing topological connection relationships and mapping runtime attributes to generate a global network resource graph; receiving business intent instructions and calculating the target network topology state on the graph based on resource constraints; performing difference analysis between the current graph and the target topology to generate a cross-cloud scheduling operation sequence; identifying the target cloud platform type, calling the driver to encapsulate native interface requests, and orchestrating execution according to dependencies. Implementing this application can shield underlying heterogeneous differences, utilize graph technology to achieve unified management and visualization of cross-cloud resources, and realize automated orchestration and precise scheduling based on business intents, significantly improving the efficiency and reliability of multi-cloud network operation.

Description

Technical Field

[0001] This application relates to the field of network resource management technology, and in particular to a graph-based multi-cloud network resource operation method, system, device and medium. Background Technology

[0002] As enterprises deepen their digital transformation, multi-cloud and hybrid cloud architectures have become the mainstream choice for IT infrastructure, and the scale of heterogeneous network resources distributed across public clouds, private clouds, and edge nodes continues to expand. How to uniformly manage, schedule across clouds, and govern compliance for these scattered IP addresses, bandwidth, firewalls, and load balancers has become a core requirement for ensuring business continuity and reducing operating costs.

[0003] In existing technologies, the management of multi-cloud network resources typically relies on independent management consoles or basic scripting tools provided by each cloud service provider. For example, operations and maintenance personnel need to log into the management systems of different cloud platforms such as AWS and Azure to manually configure routing tables, security groups, and load balancers, and record the allocation status of resources such as IP addresses through static spreadsheets. However, this decentralized management model makes it difficult to perceive the dynamic changes of heterogeneous network resources in real time, and cannot ensure the consistency and accuracy of network policy execution in cross-cloud environments. This leads to resource idleness and waste, delayed operation and maintenance response, and risks of business interruption due to human error and network security vulnerabilities due to incomplete compliance policy enforcement. Summary of the Invention

[0004] In view of this, this application provides a graph-based multi-cloud network resource operation method, system, device and medium to solve the above problems.

[0005] Firstly, a graph-based multi-cloud network resource operation method is provided, which includes:

[0006] Collect network resource data from multiple heterogeneous cloud environments. The network resource data includes resource configuration information and status information.

[0007] The network resource data is parsed into generic resource objects using a pre-defined field mapping logic. The topological connection relationship between generic resource objects is constructed based on the configuration information, and the status information is mapped into the runtime attributes of the generic resource objects.

[0008] Generate a global network resource graph based on common resource objects, topological connection relationships, and runtime attributes;

[0009] The system receives user input of business intent commands, which define resource constraints for the target business scenario. Based on these resource constraints, it performs extrapolation and calculation on the global network resource graph to determine the target network topology state that satisfies the business intent commands.

[0010] The current global network resource map is compared with the target network topology to generate a cross-cloud scheduling operation sequence.

[0011] Identify the target cloud platform type of the target operation in the cross-cloud scheduling operation sequence, call the interface adaptation driver corresponding to the target cloud platform type, encapsulate the abstract parameters in the target operation into a native interface call request corresponding to the target cloud platform type, and orchestrate and execute the native interface call request according to the dependencies between resources. The target operation is any operation in the cross-cloud scheduling operation sequence.

[0012] The above technical solutions, by collecting network resource data from multiple heterogeneous cloud environments and constructing a unified general resource object model, can achieve standardized representation of resource information from different cloud platforms; by establishing a global network resource map, the topology and operating status of multi-cloud resources can be presented in a unified view; by receiving business intents and deduce and calculate target topologies on the map, resource combinations that meet business needs can be automatically determined; by generating cross-cloud scheduling sequences through difference analysis and calling adaptation interfaces for orchestration and execution, resource creation, configuration, and adjustment can be automatically completed across different cloud platforms, thereby achieving automated operation and dynamic scheduling of network resources in a multi-cloud environment.

[0013] Optionally, network resource data can be parsed into generic resource objects using preset field mapping logic, and topological connections between generic resource objects can be constructed based on configuration information, specifically including:

[0014] Using preset field alignment rules, extract the resource unique identifier, network addressing parameters, and region label from the network resource data;

[0015] The field mapping logic is used to parse the unique resource identifier into a generic resource object;

[0016] Based on network addressing parameters, identify the network segment inclusion relationship and routing direction relationship between different general resource objects, generate logical connection edges based on the network segment inclusion relationship and routing direction relationship, and define the logical connection edge as the topological connection relationship.

[0017] The above technical solutions, by extracting resource identifiers, addressing parameters, and region labels using field alignment rules and generating general resource objects based on field mapping logic, can achieve unified parsing of multi-source heterogeneous network resource data. By identifying the network segment inclusion and routing relationship between resources based on addressing parameters and establishing logical connection edges, the actual connection structure of resources in the cloud network can be objectively reflected, providing accurate basic data for subsequent topology construction and path calculation.

[0018] Optionally, a global network resource graph can be generated based on common resource objects, topological connections, and runtime attributes, specifically including:

[0019] Use general resource objects as graph nodes and logical connection edges that serve as topological connections as graph edges;

[0020] The region label and runtime attributes are attached to the corresponding graph node to generate a global network resource graph.

[0021] The above technical solution, by defining general resource objects as graph nodes, topological connections as graph edges, and adding regional labels and runtime attributes, can form a global network resource graph that can simultaneously reflect resource structure and status information. This graph can intuitively express the distribution and interconnection of cross-cloud resources, providing graph data support for scheduling computation and health analysis.

[0022] Optionally, based on resource constraints, extrapolation and calculation are performed on the global network resource map to determine the target network topology state that satisfies the business intent instruction, specifically including:

[0023] The resource constraints are analyzed and transformed into attribute filtering rules for graph nodes and weight cost functions for graph edges.

[0024] In the global network resource graph, target graph nodes that do not meet the attribute filtering rules are removed, and the target graph edges corresponding to the target graph nodes are also removed. The passage cost value of the remaining graph edges after removing the target graph edges is calculated using the weight cost function.

[0025] A multi-objective path planning algorithm is adopted. Based on the passage cost value, the connected subgraph with the minimum total cost value is searched in the global network resource graph after removing the target graph nodes and edges. The network structure determined by the connected subgraph is marked as the target network topology state.

[0026] The above technical solution transforms business constraints into node filtering rules and edge weight cost functions, and performs multi-objective path planning based on the cost functions. It can filter out the optimal connection path that meets constraints such as performance, bandwidth or geographical location in the global graph. By eliminating non-compliant nodes and high-cost edges, a connected subgraph with the minimum total cost can be obtained, thereby accurately determining the target network topology that meets the business intent and realizing intelligent planning based on resource constraints.

[0027] Optionally, native API call requests can be orchestrated and executed based on resource dependencies, specifically including:

[0028] Analyze the input parameters required for each native API call request. If the input parameters reference the output results generated by different native API call requests at runtime, then establish a dynamic parameter dependency mapping.

[0029] Each native API call request is mapped to a graph node. Directed edges are established between graph nodes with parameter reference relationships based on the dynamic parameter dependency mapping, generating a directed acyclic graph. The native API call requests are then divided into several batches for serial execution based on the topological sorting of the directed acyclic graph.

[0030] The above technical solutions, by analyzing the parameter dependencies between native interface call requests and establishing dynamic dependency mapping, can identify the sequential constraints between different cloud operations; by mapping call requests as graph nodes and constructing a directed acyclic graph for topological sorting, complex cross-cloud operation processes can be automatically divided into serial batches, avoiding execution errors caused by ungenerated parameters or unmet dependencies, thereby improving the execution correctness and stability of multi-cloud scheduling.

[0031] Optionally, orchestrating and executing native API call requests based on resource dependencies also includes:

[0032] Establish a runtime context storage space for storing temporary state data, and start an asynchronous sending task for native interface call requests in the current batch;

[0033] Obtain the response data returned by the heterogeneous cloud environment, extract the runtime attribute values ​​generated by the native interface call request from the response data, and write the runtime attribute values ​​into the runtime context storage space;

[0034] Based on the dynamic parameter dependency mapping, the required runtime attribute values ​​are read from the runtime context storage space and injected into the input parameter fields of the next batch of native interface call requests.

[0035] The above technical solutions, by establishing a runtime context storage space to record intermediate results of batch execution, can collect returned data in real time after asynchronously executing various cloud interface calls; by extracting and writing runtime attribute values, and then injecting them into subsequent batch input parameters according to dependency mapping, cross-batch parameter transfer and dynamic data updates can be achieved, thereby ensuring closed-loop consistency and real-time performance of parameter dependencies in complex multi-cloud operation processes.

[0036] Optionally, the method also includes:

[0037] Collect feedback data after executing native interface call requests, and when it is detected that the feedback data does not meet the resource constraints defined in the business intent instruction, locate the fault edge or bottleneck node in the global network resource graph that causes the feedback data to not meet the resource constraints.

[0038] Add the travel cost of the faulty edge or bottleneck node in the global network resource graph to the preset penalty value, and rerun the inference calculation steps on the global network resource graph based on the updated travel cost to generate the corrected target network topology state.

[0039] Based on the difference between the corrected target network topology and the current global network resource map, an incremental correction operation command is generated to correct the deviation.

[0040] The above technical solutions, by collecting feedback data after interface execution and detecting whether it meets business intent constraints, can identify nodes and connections with degraded performance or abnormal resource configuration during the operation phase; by adding penalty weights to faulty edges or bottleneck nodes and re-executing topology deduction, new optimal topology states can be quickly generated; by comparing differences and generating incremental correction instructions, automatic correction and continuous optimization of multi-cloud network resources can be achieved, improving the system's adaptability and operational stability.

[0041] Secondly, a graph-based multi-cloud network resource operation system is provided, the system comprising:

[0042] The heterogeneous cloud acquisition module is configured to collect network resource data from multiple heterogeneous cloud environments. The network resource data includes resource configuration information and status information.

[0043] The field parsing module is configured to use preset field mapping logic to parse network resource data into generic resource objects, construct topological connection relationships between generic resource objects based on configuration information, and map state information into runtime attributes of generic resource objects.

[0044] The graph generation module is configured to generate a global network resource graph based on common resource objects, topological connections, and runtime attributes.

[0045] The intent deduction module is configured to receive business intent commands input by users. The business intent commands define resource constraints for the target business scenario. Based on the resource constraints, the module performs deduction calculations on the global network resource map to determine the target network topology state that satisfies the business intent commands.

[0046] The difference analysis module is configured to perform difference analysis between the current global network resource map and the target network topology state in order to generate a cross-cloud scheduling operation sequence.

[0047] The cross-cloud orchestration module is configured to identify the target cloud platform type of the target operation in the cross-cloud scheduling operation sequence, call the interface adaptation driver corresponding to the target cloud platform type, encapsulate the abstract parameters in the target operation into a native interface call request corresponding to the target cloud platform type, and orchestrate and execute the native interface call request according to the dependencies between resources. The target operation is any operation in the cross-cloud scheduling operation sequence.

[0048] Thirdly, an electronic device is provided, including a processor, a memory, a user interface, and a network interface, wherein the memory is used to store instructions, the user interface and the network interface are both used to communicate with other devices, and the processor is used to execute the instructions stored in the memory to cause the electronic device to perform the method as described in any of the above.

[0049] Fourthly, a computer-readable storage medium is provided, the computer-readable storage medium storing instructions that, when executed, perform the method as described in any of the preceding claims.

[0050] In summary, implementing one or more technical solutions provided in this application has at least the following technical effects or advantages:

[0051] Structured operation and event logs provide unified change traceability and compliance audit support, facilitating post-event analysis, billing, and liability determination; strategic and cost-aware scheduling capabilities reduce resource idleness and operational expenses, improving overall resource utilization; modular interface adaptation architecture simplifies the access process for new cloud or third-party network elements, enhancing system scalability and reducing vendor lock-in risks; real-time monitoring and automated correction loops shorten fault location and recovery time, improving service availability and SLA (Service Level Agreement) achievement rates; centralized configuration consistency checks and unified identity and access control reduce configuration errors and security risks; and support for offline simulation verification and incremental change deployment reduces online change risks and facilitates blue-green / canary releases, thereby improving overall operational efficiency and business continuity. Attached Figure Description

[0052] Figure 1 This is an exemplary system architecture diagram of a graph-based multi-cloud network resource operation method or a graph-based multi-cloud network resource operation system applied in this application;

[0053] Figure 2 This is a flowchart illustrating a graph-based multi-cloud network resource operation method disclosed in this application;

[0054] Figure 3 This is a schematic diagram of a graph-based multi-cloud network resource operation system disclosed in this application;

[0055] Figure 4 This is a schematic diagram of the structure of an electronic device disclosed in this application.

[0056] Figure reference numerals: 100, System architecture; 101, First terminal device; 102, Second terminal device; 103, Third terminal device; 104, Network; 105, Server; 301, Differential cloud acquisition module; 302, Field parsing module; 303, Map generation module; 304, Intent inference module; 305, Difference analysis module; 306, Cross-cloud orchestration module; 307, Feedback correction module; 401, Processor; 402, Communication bus; 403, User interface; 404, Network interface; 405, Memory. Detailed Implementation

[0057] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0058] In the description of the embodiments of this application, the words "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design that is described as "for example" or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design options. Rather, the use of the words "for example" or "for instance" is intended to present the relevant concepts in a specific manner.

[0059] In the description of the embodiments of this application, the term "multiple" means two or more. For example, multiple systems means two or more systems, and multiple screen terminals means two or more screen terminals. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0060] Figure 1 This paper illustrates an exemplary system architecture diagram of an embodiment of a graph-based multi-cloud network resource operation method or a graph-based multi-cloud network resource operation system to which this application can be applied.

[0061] like Figure 1 As shown, the system architecture 100 may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 is used as a medium to provide communication links between the terminal devices 101, 102, 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links or fiber optic cables, etc.

[0062] Users can use terminal devices 101, 102, and 103 to interact with server 105 via network 104 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 101, 102, and 103, such as model training applications, video recognition applications, web browser applications, social platform software, etc.

[0063] Terminal devices 101, 102, and 103 can be either hardware or software. When terminal devices 101, 102, and 103 are hardware, they can be various electronic devices with displays, including but not limited to smartphones, tablets, e-book readers, MP3 (Moving Picture Experts Group Audio Layer III) players, MP4 (Moving Picture Experts Group Audio Layer IV) players, laptops, and desktop computers, etc. When terminal devices 101, 102, and 103 are software, they can be installed in the aforementioned electronic devices. They can be implemented as multiple software programs or software modules (e.g., multiple software programs or software modules used to provide distributed services) or as a single software program or software module. No specific limitations are imposed here.

[0064] When terminals 101, 102, and 103 are hardware devices, video capture devices can also be installed on them. These video capture devices can be various devices capable of capturing video, such as cameras, sensors, etc. Users can use the video capture devices on terminals 101, 102, and 103 to capture video.

[0065] Server 105 can be a server that provides various services, such as a backend server for processing data displayed on terminal devices 101, 102, and 103. The backend server can analyze and process the received data and can feed back the processing results (such as recognition results) to the terminal devices.

[0066] It should be noted that a server can be either hardware or software. When the server is hardware, it can be implemented as a distributed server cluster consisting of multiple servers, or as a single server. When the server is software, it can be implemented as multiple software programs or software modules (e.g., multiple software programs or software modules used to provide distributed services), or as a single software program or software module. No specific limitations are made here.

[0067] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included. In particular, if the target data does not need to be obtained remotely, the above system architecture may exclude the network and include only terminal devices or servers.

[0068] Figure 2 This is a flowchart illustrating a graph-based multi-cloud network resource operation method according to an embodiment of this application. This method can be implemented using a computer program, a microcontroller, or run on a graph-based multi-cloud network resource operation system. The computer program can be integrated into an application or run as a standalone utility application. The specific steps of a graph-based multi-cloud network resource operation method are described in detail below.

[0069] S201: Collects network resource data from multiple heterogeneous cloud environments. The network resource data includes resource configuration information and status information.

[0070] In this application embodiment, network resource data refers to the information set used in the cloud computing architecture to describe various network facilities and their operation status. It is used to represent the logical definition and physical operation performance of network resources. For example, the data may include the network segment planning of Virtual Private Cloud (VPC), the routing table entries of virtual switches, the network card IP address of cloud hosts, and the current network throughput indicators, etc.

[0071] Specifically, since the heterogeneous cloud environments involved typically encompass public cloud platforms from different vendors (such as AWS, Azure, Alibaba Cloud, etc.) and private cloud platforms built internally by enterprises (such as OpenStack, VMware, etc.), and these platforms have different underlying architectures and interface specifications, it is necessary to pre-configure API (Application Programming Interface) adapters and access credentials corresponding to each cloud platform. Data is retrieved periodically or based on event triggers by calling the standard monitoring interfaces or resource management SDKs provided by each cloud platform. During the collection process, comprehensive resource configuration information is acquired, including static attributes set when the resource is created, such as the resource's unique ID, specifications, bound security group rules, subnet mask, gateway address, and bandwidth limit. Simultaneously, real-time resource status information is captured, covering dynamic metrics during resource operation, such as port on / off status (Link Up / Down), real-time CPU and memory utilization, round-trip time (RTT), packet loss rate, and the number of active connections of the load balancer. The raw data obtained from various dispersed cloud environments will be aggregated into a unified data acquisition buffer to ensure that subsequent processing steps can be analyzed based on full and timely data.

[0072] S202: Using preset field mapping logic, the network resource data is parsed into general resource objects, the topological connection relationship between general resource objects is constructed according to the configuration information, and the status information is mapped to the runtime attributes of general resource objects.

[0073] For example, the system uses a built-in multi-cloud adaptation layer to map semantically identical but differently expressed network elements (such as different vendors' differentiated naming of virtual networks and routing tables) in heterogeneous cloud platforms into unified standard resource entities. The system establishes the topological network between entities based on resource configuration associations (such as network interface card mounting and peer-to-peer connections) and synchronizes real-time monitoring metrics (such as network latency and packet loss rate) as runtime attributes of the entities. This eliminates the differences in the underlying architecture at the logical level and outputs a standardized network resource model with state information, providing a standardized and unified data foundation for subsequent construction of a comprehensive network graph.

[0074] In one possible implementation, network resource data is parsed into generic resource objects using a preset field mapping logic, and topological connection relationships between generic resource objects are constructed based on configuration information. Specifically, this includes: extracting resource unique identifiers, network addressing parameters, and region labels from network resource data using preset field alignment rules; parsing resource unique identifiers into generic resource objects using field mapping logic; identifying network segment inclusion relationships and routing pointing relationships between different generic resource objects based on network addressing parameters; generating logical connection edges based on network segment inclusion relationships and routing pointing relationships; and defining logical connection edges as topological connection relationships.

[0075] In the embodiments of this application, the general resource object refers to a standardized data model designed to shield the differences in the underlying heterogeneous cloud environment. It is used to represent the abstract entity of network resources from a unified management perspective. For example, EC2 instances in the AWS platform and ECS instances in the Alibaba Cloud platform are uniformly mapped to the same "compute node" object, so as to facilitate undifferentiated arrangement and deduction in the same graph.

[0076] Specifically, since the raw data formats (such as JSON or XML) and field naming conventions returned by different cloud vendors are different, the system loads the preset field alignment rules (such as establishing an equivalent mapping table between "instance_id" and "vmId") to standardize and parse the collected raw network resource data, and accurately extract the globally unique resource identifier, the network addressing parameters that determine the network communication capabilities (such as IP address, CIDR network segment, routing table entry), and the region label that identifies the physical deployment location.

[0077] Furthermore, to ensure both universality and scalability, the data structure of the general resource object adopts a standardized schema with a layered design. This schema includes a basic metadata layer, a network attribute layer, and a vendor extension layer. The basic metadata layer contains a globally unique resource UUID (Universally Unique Identifier, generated by platform prefix + original ID, such as aws-i-12345), resource lifecycle status (uniformly mapped to four standard states: Creating / Active / Deleting / Error), and the project tag to which it belongs. The network attribute layer normalizes heterogeneous network parameters. For example, for bandwidth parameters, AWS's "Mbps" unit and Alibaba Cloud's "Bit / s" unit are uniformly converted to "Kbps" integer values; for security policies, AWS's "Security Group Inbound Rules" and Azure's "NSG Inbound Rules" are uniformly abstracted into a "five-tuple access control list object," containing {Source_CIDR, Protocol, Port_Range, Action, Priority}. The vendor extension layer stores cloud platform-specific, non-normalizable fields (such as AWS's "Nitro Enclaves" attribute) in JSON Blob format, ensuring no information loss during the reverse engineering of native requests. Furthermore, if semantic conflicts arise during field mapping, the system employs a fallback strategy of "preserving the original semantics." For example, if an undefined enumeration value appears in a cloud platform's "Status" field, the system maps it to an "Unknown" status in a generic object and triggers an alert log, without discarding the resource object, thus ensuring the integrity of the graph.

[0078] Further, the field mapping logic is executed, instantiating a generic resource object with the resource unique identifier as the primary key, and populating the extracted attributes into the object. Based on this, network addressing parameters are parsed, and the hierarchy between different objects is determined using an IP address range matching algorithm. If the address range of one object is completely covered by another object (e.g., a subnet segment belongs to a VPC segment), a segment inclusion relationship is confirmed. Simultaneously, routing policies are parsed; if the traffic exit of one segment points to another gateway device, a routing relationship is confirmed. Based on these physical or logical relationships at the network layer, directed or undirected logical connections are generated between the corresponding generic resource objects, and these edges are established as the topological connections describing the communication paths and hierarchical structure between resources.

[0079] S203: Generate a global network resource graph based on common resource objects, topology connections, and runtime attributes.

[0080] For example, the system structurally reassembles discrete resource entities (such as AWS EC2 instances, Azure Virtual Networks (VNets), and VPN gateways connecting them) parsed from heterogeneous cloud environments. The system uses "vertices" from graph theory to represent specific network devices or logical units, and "edges" to represent network-level connectivity paths (such as next-hop routing or peer-to-peer connections), thus piecing together previously isolated and fragmented multi-cloud resource data into a logically connected mesh topology. This graph not only statically recreates the skeletal structure of the cross-cloud network but also incorporates the dynamic characteristics of resource runtime, providing a unified data foundation for subsequent global path optimization and root cause analysis.

[0081] In one possible implementation, a global network resource graph is generated based on general resource objects, topological connections, and runtime attributes. Specifically, this includes: using general resource objects as graph nodes and logical connection edges that serve as topological connections as graph edges; and attaching the region label and runtime attributes to the corresponding graph nodes to generate a global network resource graph.

[0082] In this application embodiment, the global network resource graph refers to a data structure based on graph theory model, used to panoramically display all network resources and their interrelated states in a multi-cloud environment, and used to represent complex network topology and real-time operating characteristics of resources. For example, the graph can be a knowledge graph stored in a graph database (such as Neo4j or JanusGraph), which includes virtual routers, firewalls, and physical links and logical routes between them across different cloud service providers.

[0083] Specifically, to construct a graph structure that can be directly traversed and analyzed by the algorithm, the system initializes the graph model in the graph database or in-memory graph computing engine. Each previously parsed general resource object (such as a specific cloud host, virtual switch, or gateway device) is instantiated as a graph node in the graph database and assigned a unique node ID. Simultaneously, based on the topology, logical connection edges describing the inclusion or routable reachability of network segments between resources are mapped to graph edges connecting two graph nodes, and the directionality (directed or undirected) of the edges is determined according to the routing direction. Further, to enrich the semantic information of the graph to support subsequent policy deduction, an attribute injection operation is performed. The physical deployment location of the resource, i.e., its region label (e.g., "East China - Availability Zone A"), and runtime attributes reflecting the current health status and load level of the resource (e.g., real-time bandwidth utilization, port status, link latency data) are used as attribute key-value pairs and directly appended to the corresponding graph nodes. Through the above node mapping, edge construction, and attribute enrichment processes, a global network resource graph containing all network elements and possessing a dynamic state view is finally generated.

[0084] S204: Receive the service intent instruction input by the user. The service intent instruction defines the resource constraints for the target service scenario. Based on the resource constraints, perform inference and calculation on the global network resource map to determine the target network topology state that satisfies the service intent instruction.

[0085] For example, a user inputs the business intent of "building a cross-regional financial data synchronization link," carrying resource constraints such as "end-to-end latency less than 30ms" and "having primary and backup redundant paths." Upon receiving this instruction, the system performs full-path simulation and optimization on a global network resource map covering multi-cloud leased lines, public VPNs, and cloud enterprise networks. Based on the real-time link quality and topology connectivity recorded in the map, the system deduces a combined architecture with a high-performance physical leased line as the primary link and an IPsec encrypted tunnel as the backup link. The final determined target network topology is this target network architecture configuration scheme, which includes specific gateway selection, routing, and failover logic. It structurally defines the resource connection form required to meet this high-reliability business scenario.

[0086] In one possible implementation, a deductive calculation is performed on the global network resource graph based on resource constraints to determine the target network topology state that satisfies the business intent instruction. Specifically, this includes: parsing the resource constraints and converting them into attribute filtering rules for graph nodes and weighted cost functions for graph edges; removing target graph nodes that do not satisfy the attribute filtering rules from the global network resource graph, and removing the target graph edges corresponding to the target graph nodes, and using the weighted cost function to calculate the travel cost of the remaining graph edges after removing the target graph edges; and using a multi-objective path planning algorithm to search for the connected subgraph with the minimum total cost value in the global network resource graph after removing the target graph nodes and target graph edges, based on the travel cost value, and marking the network structure determined by the connected subgraph as the target network topology state.

[0087] In this embodiment, the target network topology refers to the optimal network resource structure configuration scheme determined through algorithmic deduction that can meet specific business needs. It represents the theoretically best combination of resource connection paths and nodes under current resource conditions. For example, a dedicated communication link structure spanning AWS and Alibaba Cloud that meets the requirements of bandwidth greater than 1Gbps and latency less than 50ms. Resource constraints refer to the hard requirements of the business scenario on network performance, cost, or security. The weighted cost function is a mathematical calculation model used to quantify network link throughput or cost.

[0088] Specifically, in order to select the optimal structure that meets business expectations from the complex full graph, the system performs semantic parsing and mathematical quantification on the received resource constraints. The hard requirements for node attributes (such as "the region must be East China" and "the link status must be Active") are transformed into attribute filtering rules, and the optimization objectives for link quality (such as "lowest latency" and "lowest cost") are transformed into weight cost functions for calculating edge weights.

[0089] Specifically, the weighted cost function is constructed using a multi-factor weighted normalization model. Assume an edge in the graph... (If it is a directed edge, it specifically refers to the edge along the data flow direction) represents the link between two nodes, and its comprehensive travel cost. The calculation formula is as follows: .in: The measured latency of the link. This represents the remaining available bandwidth of the link. The unit price for using the link; The Min-Max normalization function maps physical indices of different dimensions to... The dimensionless interval is used to eliminate the influence of units, where the maximum and minimum values ​​required for normalization are taken from the statistical extreme values ​​of all similar edges in the global network resource graph; These are the weighting coefficients parsed from the business intent command, and For example, if the business intent is "cost priority", the parsing engine will automatically... Set to 0.8. and Set to 0.1; if the business intent is "high throughput priority", then... It is set to 0.8 (because the larger the bandwidth, the smaller the reciprocal, so the reciprocal needs to be used in the calculation).

[0090] Furthermore, the global network resource graph is traversed, automatically identifying all nodes whose attribute values ​​do not conform to the attribute filtering rules. These nodes are marked as target graph nodes and physically removed from the graph along with the target graph edges connected to them, thus narrowing the optimization space. Next, a predefined weighted cost function is used to traverse and calculate the remaining graph edges after removing the target graph edges, obtaining the travel cost value of each edge in the current business scenario (e.g., quantifying a 20ms delay as 20 cost values). A multi-objective path planning algorithm (such as constrained Dijkstra's algorithm or ant colony algorithm) is introduced to search within the pruned and weighted graph.

[0091] Furthermore, for multi-objective path planning, the system employs a Pareto optimal selection mechanism. When multiple paths satisfy hard constraints (such as "avoiding high-risk areas"), the algorithm does not directly return a single result, but instead outputs a set of non-dominated solutions, such as "Path A: delay 10ms / cost 100 yuan" and "Path B: delay 20ms / cost 50 yuan". Based on preset decision preferences (such as "budget cap"), the system automatically selects the final target network topology state and marks the combination structure of nodes and links determined by this connected subgraph as the target network topology state.

[0092] S205: Perform a difference analysis between the current global network resource map and the target network topology to generate a cross-cloud scheduling operation sequence.

[0093] In the embodiments of this application, the cross-cloud scheduling operation sequence refers to a set of ordered, executable atomic operation instructions generated in order to change the network environment from the current state to the ideal state. It is used to represent the specific execution steps required to realize cross-cloud network orchestration. For example, the sequence may include instructions that are strictly arranged in order, such as "Step 1: Create a VPC in AWS", "Step 2: Create a VPN gateway in Alibaba Cloud", and "Step 3: Establish an IPsec connection".

[0094] Specifically, in order to translate the theoretically optimal topology into practical implementation, the system performs a full comparison between the current global network resource graph, which reflects the real-time state of the existing network, and the target network topology derived by the algorithm. A graph traversal algorithm is used to detect the similarities and differences between the two in node composition and edge connections, identifying the discrepancies.

[0095] Furthermore, this difference analysis process is implemented based on the minimum graph edit distance algorithm. The system defines four basic graph editing operations: InsertNode, DeleteNode, UpdateAttribute, and RemapEdge. The algorithm first calculates the minimum operation cost path required to transform the current graph into the target graph. When generating the operation sequence, the system incorporates a cloud resource atomicity constraint library. For example, if the difference analysis results indicate that the CIDR Block attribute of a VPC needs to be modified, and the constraint library shows that this attribute is immutable after creation in the cloud, the system automatically upgrades the UpdateAttribute operation to a reconstruction sequence: that is, generating a combined instruction of Delete_Old_VPC→Create_New_VPC. Similarly, before generating the DeleteNode instruction, the system recursively checks the in-degree of the node in the current graph. If the node (such as a VPC) still has associated child nodes (such as a Subnet), the system automatically inserts deletion instructions for the child nodes before the deletion operation, ensuring that the operation sequence complies with the cloud platform's rule that non-empty resources cannot be deleted.

[0096] Furthermore, for these discrepancies, CRUD (Create, Read, Update, Delete) logic is applied to generate corresponding atomic actions: if a node exists in the target state but not in the current graph, a "Create Resource" operation is generated; if both exist but their attribute values ​​(such as bandwidth) are inconsistent, a "Modify Configuration" operation is generated; if a node exists in the current graph but is no longer needed in the target state, a "Release Resource" operation is generated. Based on the logical dependencies of resource creation (such as needing to create a VPC before creating a subnet), all generated atomic actions are logically sorted and their dependencies are analyzed, thereby generating a logically consistent cross-cloud scheduling operation sequence that can guide the underlying execution engine to complete environmental changes.

[0097] S206: Identify the target cloud platform type of the target operation in the cross-cloud scheduling operation sequence, call the interface adaptation driver corresponding to the target cloud platform type, encapsulate the abstract parameters in the target operation into a native interface call request corresponding to the target cloud platform type, and orchestrate and execute the native interface call request according to the dependencies between resources. The target operation is any operation in the cross-cloud scheduling operation sequence.

[0098] For example, suppose the cross-cloud scheduling operation sequence includes a "Create Virtual Private Cloud" operation for the Alibaba Cloud platform and a "Deploy Compute Instances" operation for the AWS platform. The system parses the metadata of the operation objects and identifies the target platform types as "AliCloud" and "AWS," respectively. Then, the system dynamically loads the interface adaptation drivers corresponding to these two platforms. These drivers perform protocol format conversion and interface adaptation functions, converting common resource descriptions in the graph (such as standard CIDR format and CPU core definitions) into JSON messages in the Alibaba Cloud OpenAPI specification and XML request bodies in the AWS SDK specification, respectively. For example, common creation instructions are encapsulated into Alibaba Cloud's CreateVpc interface request and AWS's RunInstances interface request, respectively. The execution engine schedules these native requests to the corresponding cloud API gateways in an orderly manner according to the logical order of resource creation (e.g., the network environment must be created first, and then instances are deployed in the network), thereby completing the automated delivery of cross-cloud resources without exposing underlying heterogeneous details.

[0099] In one possible implementation, native interface call requests are orchestrated and executed based on resource dependencies. Specifically, this includes: analyzing the input parameters required for each native interface call request; if the input parameters reference the output results generated by different native interface call requests at runtime, establishing a dynamic parameter dependency mapping; mapping each native interface call request to a graph node; establishing directed edges between graph nodes with parameter reference relationships based on the dynamic parameter dependency mapping; generating a directed acyclic graph; and dividing the native interface call requests into several batches for sequential execution based on the topological sorting of the directed acyclic graph.

[0100] In this embodiment, dynamic parameter dependency mapping refers to a logical table or data structure that records the data transfer relationship between different API requests. It is used to represent the dependency situation where the input parameter value of one request needs to be obtained from the execution result of another request. For example, the "VPC ID" parameter in the request to create a cloud server instance (Request B) must reference the "vpc-id" result returned by the request to create a virtual private cloud (Request A). This "Request B depends on Request A" relationship constitutes the mapping.

[0101] Specifically, to ensure cross-cloud operations are executed in the correct causal order, the system scans and analyzes the input parameters required for each native API call request, identifying fields that use placeholders or reference variables. When it is found that an input parameter references the output results generated by different native API call requests at runtime (e.g., a subnet creation request references the ID of a VPC creation request), the supply and demand relationship between the two requests is recorded in memory, thus establishing a dynamic parameter dependency mapping. Graph theory algorithms are introduced for visual modeling, mapping each native API call request to a graph node. Based on the upstream and downstream relationships recorded in the dynamic parameter dependency mapping, directed edges are established between graph nodes with parameter reference relationships, with the direction pointing from the dependent request to the dependent request (e.g., from the VPC creation node to the subnet creation node). In this way, all discrete requests are assembled into a directed acyclic graph that clearly expresses the execution order. The directed acyclic graph is traversed using a topological sorting algorithm. Nodes with an in-degree of 0 (i.e., no dependencies or dependencies already satisfied) are separated to form the first batch. After removing these nodes and their emanating edges, new nodes with an in-degree of 0 are searched to form the next batch. This process is repeated to divide the native interface call request into several batches that are executed serially, ensuring that the required dependency parameters for each batch of requests have already been generated in the previous batch.

[0102] In one possible implementation, orchestrating the execution of native interface call requests based on resource dependencies further includes: establishing a runtime context storage space for storing temporary state data and initiating an asynchronous sending task for native interface call requests in the current batch; obtaining response data returned by the heterogeneous cloud environment, extracting runtime attribute values ​​generated by the native interface call requests from the response data, and writing the runtime attribute values ​​into the runtime context storage space; reading the required runtime attribute values ​​from the runtime context storage space according to the dynamic parameter dependency mapping, and injecting the read runtime attribute values ​​into the input parameter fields of the next batch of native interface call requests.

[0103] In this embodiment, runtime context storage space refers to a temporary storage area specifically allocated during the automated orchestration process for caching and exchanging data between different task batches. It represents an intermediate medium for passing request parameters. For example, it can be a key-value pair container or a Redis cache instance residing in memory, specifically used to temporarily store dynamic data returned by the previous API call (such as the VPC ID created above) so that the next API call (such as creating a subnet under the VPC) can read and use this data.

[0104] Specifically, to achieve automatic data transfer and interaction between tasks across batches, the system establishes a runtime context storage space for storing temporary state data when the orchestration engine starts. Non-blocking I / O or multi-threading techniques are used to concurrently initiate asynchronous sending tasks for native interface call requests in the current batch to improve execution efficiency. After the cloud platform processes the request and returns the result, the system obtains the response data returned by the heterogeneous cloud environment and, based on preset parsing rules (such as JSON Path), accurately extracts the runtime attribute values ​​generated by the native interface call requests from the response data (i.e., dynamic information that is only generated after resource creation, such as instance ID or public IP). These extracted key data are then written into the runtime context storage space for storage. When preparing to execute subsequent dependent tasks, the previously built dependency table is queried, and the required runtime attribute values ​​are read from the runtime context storage space according to the dynamic parameter dependency mapping. These values ​​are then used to dynamically replace placeholders in subsequent request messages, thereby injecting the read runtime attribute values ​​into the input parameter fields of the next batch of native interface call requests, ensuring that subsequent requests are sent with correct and valid parameters.

[0105] Furthermore, in one possible implementation, to address execution anomalies in heterogeneous environments, a distributed transaction compensation mechanism based on the Saga pattern is introduced into the orchestration execution process. While generating a forward cross-cloud scheduling operation sequence, the system generates a corresponding reverse compensation operation for each write operation involving resource state changes. For example, if the forward operation is "AWS: RunInstance", the corresponding reverse operation is "AWS: TerminateInstance"; if the forward operation is "AliCloud: ModifyBandwidth (10M→20M)", the corresponding reverse operation is "AliCloud: ModifyBandwidth (20M→10M)". During the execution phase, if any critical request in a batch fails (e.g., due to insufficient quota), the system executes the following process: 1. Pause: The orchestration engine immediately pauses the issuance of all tasks in subsequent batches; 2. Circuit Breaker: The current changed task is marked as "Failed"; 3. Rollback: The system reads the successfully executed operation logs in reverse order, triggering the corresponding reverse compensation operation one by one, until the network resource state is rolled back to the initial consistent state before the change. This mechanism effectively prevents the loss of residual resources that are out of control due to partial success or partial failure, or the loss of traffic due to the unreachability of the next hop in the routing, thus ensuring data consistency and system stability in the operation of multi-cloud resources.

[0106] Optionally, the method further includes: collecting feedback data after executing the native interface call request, and when it is detected that the feedback data does not meet the resource constraints defined in the business intent instruction, locating the faulty edge or bottleneck node in the global network resource graph that causes the feedback data to not meet the resource constraints; adding the passage value of the faulty edge or bottleneck node in the global network resource graph to a preset penalty value, and re-running the inference calculation steps on the global network resource graph based on the updated passage value to generate a corrected target network topology state; and generating an incremental correction operation instruction to correct the deviation based on the difference between the corrected target network topology state and the current global network resource graph.

[0107] In this embodiment of the application, the incremental correction operation instruction refers to a supplementary operation command generated on the basis of the original scheduling execution in order to correct the deviation between the execution result and the expectation, and only adjusts the difference part. It is used to indicate remedial measures for fine-tuning the network architecture. For example, the instruction can be a specific action such as "modifying the priority of a specific routing policy" or "temporarily increasing the bandwidth quota for a link", which aims to bring the network state back to the compliance range with the least change cost.

[0108] Specifically, to build a self-healing closed-loop control system, after the initial orchestration and deployment of cross-cloud resources, feedback data after executing native interface call requests is continuously monitored and collected. This data includes, but is not limited to, measured RTT, actual throughput, packet loss rate, and port connectivity status. These measured data are rigorously compared with the resource constraints defined in the business intent instructions. When feedback data is detected as not meeting the resource constraints defined in the business intent instructions (e.g., measured latency exceeding the maximum allowed threshold), the correlation analysis capability of the network graph is used to locate the faulty edge or bottleneck node in the global network resource graph that causes the feedback data to fail to meet the resource constraints (i.e., those specific physical links whose performance does not meet expectations or gateway nodes with excessive load).

[0109] Furthermore, to achieve soft isolation of faulty resources, the preset penalty value is not a single fixed constant, but a weighted adjustment parameter set according to the severity of the fault. For blocking faults (such as port down, link interruption), the penalty value is set to the global maximum path cost (e.g., more than 10 times the sum of the weights of all normal edges in the graph), so that the path is only selected as a fallback option in the pathfinding algorithm when there are no other physically connected paths. For performance degradation faults (such as latency jitter exceeding a threshold, slight increase in packet loss rate), the penalty value is dynamically calculated using a linear or exponentially increasing function. For example, the calculation formula is... ,in As a punitive value, The degradation coefficient is... These are the measured index values. This is the threshold allowed by the business. Unlike directly deleting nodes from the graph, soft isolation is implemented by superimposing penalty values. This ensures that even in extreme network conditions (i.e., when all links deteriorate), the algorithm can still select the available path with the minimum cumulative cost based on the current network weight distribution, thus guaranteeing end-to-end network reachability despite link performance degradation.

[0110] Furthermore, based on the updated access cost, the deduction calculation steps are re-run on the global network resource graph, driving the pathfinding algorithm to replan the path to generate a corrected target network topology that satisfies business constraints and bypasses the faulty area. The state difference comparison logic is executed again. Based on the difference between the corrected target network topology and the current global network resource graph, the minimum set of atomic operations required to switch from the current state to the corrected state is precisely calculated. This generates incremental correction operation instructions to correct deviations, ensuring that the network service quality ultimately converges to business expectations.

[0111] Figure 3 This is a schematic diagram of a graph-based multi-cloud network resource operation system according to an embodiment of this application. This system can be implemented through software, hardware, or a combination of both, becoming all or part of the overall system. For example... Figure 3 As shown, the system includes:

[0112] The heterogeneous cloud acquisition module 301 is configured to collect network resource data from multiple heterogeneous cloud environments. The network resource data includes resource configuration information and status information.

[0113] The field parsing module 302 is configured to use preset field mapping logic to parse network resource data into general resource objects, construct topological connection relationships between general resource objects according to configuration information, and map state information into runtime attributes of general resource objects;

[0114] The graph generation module 303 is configured to generate a global network resource graph based on common resource objects, topological connection relationships and runtime attributes.

[0115] The intent deduction module 304 is configured to receive service intent instructions input by the user. The service intent instructions define resource constraints for the target service scenario. Based on the resource constraints, the module performs deduction calculations on the global network resource map to determine the target network topology state that satisfies the service intent instructions.

[0116] The difference analysis module 305 is configured to perform difference analysis between the current global network resource map and the target network topology state in order to generate a cross-cloud scheduling operation sequence.

[0117] The cross-cloud orchestration module 306 is configured to identify the target cloud platform type to which the target operation in the cross-cloud scheduling operation sequence belongs, call the interface adaptation driver corresponding to the target cloud platform type, encapsulate the abstract parameters in the target operation into a native interface call request corresponding to the target cloud platform type, and orchestrate and execute the native interface call request according to the dependencies between resources. The target operation is any operation in the cross-cloud scheduling operation sequence.

[0118] Based on the above embodiments, as an optional embodiment, the field parsing module 302 is specifically used to: extract the resource unique identifier, network addressing parameters and the area label from the network resource data using preset field alignment rules; parse the resource unique identifier into a general resource object using field mapping logic; identify the network segment inclusion relationship and routing pointing relationship between different general resource objects according to the network addressing parameters; generate logical connection edges based on the network segment inclusion relationship and routing pointing relationship; and define the logical connection edges as topological connection relationships.

[0119] Based on the above embodiments, as an optional embodiment, the graph generation module 303 is specifically used to: use general resource objects as graph nodes, use logical connection edges that are topological connection relationships as graph edges; attach the region label and runtime attributes to the corresponding graph nodes to generate a global network resource graph.

[0120] Based on the above embodiments, as an optional embodiment, the intent deduction module 304 is specifically used for: parsing resource constraints and converting them into attribute filtering rules for graph nodes and weight cost functions for graph edges; removing target graph nodes that do not meet the attribute filtering rules from the global network resource graph and removing the target graph edges corresponding to the target graph nodes, and calculating the passage cost value of the remaining graph edges after removing the target graph edges using the weight cost function; employing a multi-objective path planning algorithm, searching for the connected subgraph with the minimum total cost value in the global network resource graph after removing the target graph nodes and target graph edges based on the passage cost value, and marking the network structure determined by the connected subgraph as the target network topology state.

[0121] Based on the above embodiments, as an optional embodiment, the cross-cloud orchestration module 306 is specifically used to: analyze the input parameters required for each native interface call request; if the input parameters reference the output results generated by different native interface call requests at runtime, then establish a dynamic parameter dependency mapping; map each native interface call request as a graph node; establish directed edges between graph nodes with parameter reference relationships according to the dynamic parameter dependency mapping; generate a directed acyclic graph; and divide the native interface call request into several batches for serial execution according to the topological sorting of the directed acyclic graph.

[0122] Based on the above embodiments, as an optional embodiment, the cross-cloud orchestration module 306 is specifically used to: establish a runtime context storage space for storing temporary state data, and start an asynchronous sending task for native interface call requests in the current batch; obtain response data returned by the heterogeneous cloud environment, extract runtime attribute values ​​generated by the native interface call requests from the response data, and write the runtime attribute values ​​into the runtime context storage space; read the required runtime attribute values ​​from the runtime context storage space according to the dynamic parameter dependency mapping, and inject the read runtime attribute values ​​into the input parameter fields of the next batch of native interface call requests.

[0123] Based on the above embodiments, as an optional embodiment, the system further includes a feedback correction module 307, specifically used for: collecting feedback data after executing the native interface call request, and when it is detected that the feedback data does not meet the resource constraints defined in the business intent instruction, locating the faulty edge or bottleneck node in the global network resource graph that causes the feedback data to not meet the resource constraints; adding the passage value of the faulty edge or bottleneck node in the global network resource graph to a preset penalty value, and re-running the inference calculation steps on the global network resource graph based on the updated passage value to generate a corrected target network topology state; and generating an incremental correction operation instruction for correcting the deviation based on the difference between the corrected target network topology state and the current global network resource graph.

[0124] It should be noted that the system provided in the above embodiments is only illustrated by the division of the above functional modules. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the system and method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0125] This embodiment also discloses an electronic device, as shown in the reference. Figure 4 The electronic device may include: at least one processor 401, at least one communication bus 402, user interface 403, network interface 404, and at least one memory 405.

[0126] The communication bus 402 is used to enable communication between these components.

[0127] The user interface 403 may include a display screen and a camera. Optionally, the user interface 403 may also include a standard wired interface and a wireless interface.

[0128] The network interface 404 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0129] The processor 401 may include one or more processing cores. The processor 401 connects to various parts of the server using various interfaces and lines, and performs various server functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in memory 405, and by calling data stored in memory 405. Optionally, the processor 401 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 401 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content required for display; and the modem handles wireless communication. It is understood that the modem may also be implemented as a separate chip without being integrated into the processor 401.

[0130] The memory 405 may include random access memory (RAM) or read-only memory. Optionally, the memory 405 may include a non-transitory computer-readable storage medium. The memory 405 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 405 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 405 may also be at least one storage device located remotely from the aforementioned processor 401. Figure 4 As shown, the memory 405, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and an application program for a graph-based multi-cloud network resource operation method.

[0131] exist Figure 4 In the electronic device shown, the user interface 403 is mainly used to provide an input interface for the user and to obtain the user input data; while the processor 401 can be used to call an application stored in the memory 405 that is a graph-based multi-cloud network resource operation method. When executed by one or more processors 401, the electronic device executes one or more methods as described in the above embodiments.

[0132] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0133] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0134] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the shown or discussed mutual couplings or direct couplings or communication connections may be through some service interfaces; indirect couplings or communication connections between apparatuses or units may be electrical or other forms.

[0135] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0136] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0137] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory 405 and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory 405 includes various media capable of storing program code, such as a USB flash drive, external hard drive, magnetic disk, or optical disk.

[0138] The foregoing description is merely an exemplary embodiment of this disclosure and should not be construed as limiting the scope of this disclosure. Any equivalent changes and modifications made in accordance with the teachings of this disclosure shall still fall within the scope of this disclosure. Those skilled in the art will readily conceive of other embodiments of this disclosure upon considering the disclosure in this specification. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not described in this disclosure. The specification and embodiments are considered exemplary only, and the scope of this application is defined by the claims.

Claims

1. A graph-based multi-cloud network resource operation method, characterized in that, The method includes: Collect network resource data from multiple heterogeneous cloud environments, the network resource data including resource configuration information and status information; The network resource data is parsed into general resource objects using a preset field mapping logic, the topological connection relationship between the general resource objects is constructed according to the configuration information, and the status information is mapped into the runtime attributes of the general resource objects. A global network resource graph is generated based on the general resource object, the topological connection relationship, and the runtime attributes. The system receives a service intent instruction input by a user, which defines resource constraints for a target service scenario. Based on these resource constraints, the system performs calculations on the global network resource graph to determine the target network topology state that satisfies the service intent instruction. The current global network resource map is compared with the target network topology to generate a cross-cloud scheduling operation sequence. Identify the target cloud platform type to which the target operation in the cross-cloud scheduling operation sequence belongs, call the interface adaptation driver corresponding to the target cloud platform type, encapsulate the abstract parameters in the target operation into a native interface call request corresponding to the target cloud platform type, and orchestrate and execute the native interface call request according to the dependencies between resources. The target operation is any operation in the cross-cloud scheduling operation sequence.

2. The method according to claim 1, characterized in that, The step of parsing the network resource data into general resource objects using preset field mapping logic and constructing the topological connection relationship between the general resource objects based on the configuration information specifically includes: Using preset field alignment rules, extract the resource unique identifier, network addressing parameters, and region label from the network resource data; The field mapping logic is used to parse the resource unique identifier into the general resource object; Identify the network segment inclusion relationship and routing direction relationship between different general resource objects based on the network addressing parameters, generate logical connection edges based on the network segment inclusion relationship and the routing direction relationship, and define the logical connection edges as the topology connection relationship.

3. The method according to claim 2, characterized in that, The process of generating a global network resource graph based on the general resource object, the topological connection relationship, and the runtime attributes specifically includes: The general resource object is used as a graph node, and the logical connection edge that is the topological connection relationship is used as a graph edge; The region label and runtime attributes are attached to the corresponding graph node to generate the global network resource graph.

4. The method according to claim 3, characterized in that, The step of performing deduction and calculation on the global network resource map based on the resource constraints to determine the target network topology state that satisfies the business intent instruction specifically includes: The resource constraints are parsed and transformed into attribute filtering rules for the graph nodes and weight cost functions for the graph edges. In the global network resource graph, target graph nodes that do not meet the attribute filtering rules are removed, and the target graph edges corresponding to the target graph nodes are removed. The passage cost of the remaining graph edges after removing the target graph edges is calculated using the weight cost function. A multi-objective path planning algorithm is used to search for the connected subgraph with the minimum total value in the global network resource graph after removing the target graph nodes and edges, based on the passage cost value, and the network structure determined by the connected subgraph is marked as the target network topology state.

5. The method according to claim 1, characterized in that, The orchestration and execution of the native interface call requests based on resource dependencies specifically includes: Analyze the input parameters required for each native interface call request. If the input parameters reference the output results generated by different native interface call requests at runtime, then establish a dynamic parameter dependency mapping. Each native interface call request is mapped to a graph node. Directed edges are established between graph nodes with parameter reference relationships according to the dynamic parameter dependency mapping to generate a directed acyclic graph. The native interface call requests are divided into several batches to be executed serially according to the topological sorting of the directed acyclic graph.

6. The method according to claim 5, characterized in that, The orchestration and execution of the native interface call requests based on resource dependencies further includes: Establish a runtime context storage space for storing temporary state data, and start an asynchronous sending task for the native interface call requests in the current batch; Obtain the response data returned by the heterogeneous cloud environment, extract the runtime attribute values ​​generated by the native interface call request from the response data, and write the runtime attribute values ​​into the runtime context storage space; The required runtime attribute values ​​are read from the runtime context storage space according to the dynamic parameter dependency mapping, and the read runtime attribute values ​​are injected into the input parameter fields of the next batch of native interface call requests.

7. The method according to claim 1, characterized in that, The method further includes: Collect feedback data after executing the native interface call request, and when it is detected that the feedback data does not meet the resource constraints defined in the business intent instruction, locate the fault edge or bottleneck node in the global network resource graph that causes the feedback data to not meet the resource constraints. The passage value of the faulty edge or the bottleneck node in the global network resource graph is added to a preset penalty value, and the inference calculation steps are rerun on the global network resource graph based on the updated passage value to generate the corrected target network topology state. Based on the difference between the corrected target network topology and the current global network resource map, an incremental correction operation command is generated to correct the deviation.

8. A graph-based multi-cloud network resource operation system, characterized in that, The system includes: The heterogeneous cloud acquisition module is configured to collect network resource data from multiple heterogeneous cloud environments. The network resource data includes resource configuration information and status information. The field parsing module is configured to parse the network resource data into general resource objects using a preset field mapping logic, construct the topological connection relationship between the general resource objects according to the configuration information, and map the state information into the runtime attributes of the general resource objects. The graph generation module is configured to generate a global network resource graph based on the general resource object, the topological connection relationship, and the runtime attributes. The intent deduction module is configured to receive service intent commands input by the user. The service intent commands define resource constraints for the target service scenario. Based on the resource constraints, the module performs deduction calculations on the global network resource map to determine the target network topology state that satisfies the service intent commands. The difference analysis module is configured to perform difference analysis between the current global network resource map and the target network topology state in order to generate a cross-cloud scheduling operation sequence. The cross-cloud orchestration module is configured to identify the target cloud platform type to which the target operation in the cross-cloud scheduling operation sequence belongs, call the interface adaptation driver corresponding to the target cloud platform type, encapsulate the abstract parameters in the target operation into a native interface call request corresponding to the target cloud platform type, and orchestrate and execute the native interface call request according to the dependencies between resources. The target operation is any operation in the cross-cloud scheduling operation sequence.

9. An electronic device, characterized in that, The device includes a processor, a memory, a user interface, and a network interface. The memory is used to store instructions. The user interface and the network interface are both used to communicate with other devices. The processor is used to execute the instructions stored in the memory to cause the electronic device to perform the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed, perform the method as described in any one of claims 1-7.

Images