Component upgrading method and device, nonvolatile storage medium and electronic equipment

Abstract

The invention discloses a component upgrading method and device, a nonvolatile storage medium and electronic equipment. The method comprises the following steps: receiving an upgrading request; in the component relation database, attribute data of the target component is obtained, and the attribute data is converted into a bidirectional adjacency list topology model in a storage medium; traversing forward association mapping and reverse association mapping in the bidirectional adjacency list topology model to capture a complete topology structure of the target component, and generating an initial version snapshot; the method comprises the steps of determining a plurality of to-be-changed target bottom layer nodes indicated by an upgrading request, performing parallel updating on the plurality of target bottom layer nodes, integrating the updated target bottom layer nodes, generating an upgraded target version snapshot, and releasing the target version snapshot. According to the method and the device, the technical problems that the module upgrading efficiency is low and version dislocation is easily caused due to the fact that a related module upgrading method depends on manual operation are solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of software, in particular to a component upgrade method and device, a nonvolatile storage medium and an electronic device. BACKGROUND

[0002] In the current cloud network environment, especially in the cloud network product adopting the PSR design architecture (i.e., Product-Service-Resource architecture), iterative upgrade of components and services is crucial to meet the increasingly changing market demand. However, the related component upgrade method often relies on a tedious manual operation process, which not only consumes time and effort, but also easily causes inaccurate upgrade range positioning due to human factors, thereby causing version misalignment and other problems.

[0003] Currently, no effective solution has been proposed for the above problems. SUMMARY

[0004] The present application provides a component upgrade method, device, nonvolatile storage medium and electronic device to at least solve the technical problems of low component upgrade efficiency and easy version misalignment caused by the related component upgrade method relying on manual operation.

[0005] According to one aspect of the present application, a component upgrade method is provided, comprising: receiving an upgrade request, wherein the upgrade request at least includes component information of a target component to be upgraded; in a component relationship database, obtaining attribute data of the target component, converting the attribute data into a bidirectional adjacency list topology model in a storage medium, the bidirectional adjacency list topology model including: a forward association mapping and a reverse association mapping, the forward association mapping being used to record the mapping relationship of each component to the downstream component of the component, and the reverse association mapping being used to record the mapping relationship of each component to the upstream component of the component; traversing the forward association mapping and the reverse association mapping in the bidirectional adjacency list topology model to capture the complete topology structure of the target component, and generating an initial version snapshot according to the complete topology structure; determining a plurality of target bottom nodes to be changed indicated by the upgrade request, performing parallelized update on the plurality of target bottom nodes based on the initial version snapshot, integrating the updated target bottom nodes, generating a target version snapshot of completed upgrade according to the integration result, and publishing the target version snapshot.

[0006] Optionally, the forward association mapping and the reverse association mapping in the bidirectional adjacency list topology model are traversed to capture the complete topology structure of the target component, including: in the forward association mapping of the bidirectional adjacency list topology model, a direct downstream component set starting from the target component is obtained; the direct downstream component set is expanded layer by layer by recursive query of the forward association mapping to obtain all downstream components of the target component, and a downstream topology structure is obtained; in the reverse association mapping of the bidirectional adjacency list topology model, a direct upstream component set starting from the target component is obtained; the direct upstream component set is expanded layer by layer by recursive query of the reverse association mapping to obtain all upstream components of the target component, and an upstream topology structure is obtained; and the downstream topology structure and the upstream topology structure are integrated to obtain the complete topology structure, wherein the complete topology structure includes all associated components and associated relationships of the target component in the full dependency path.

[0007] Optionally, according to the complete topology structure, an initial version snapshot is generated, including: all component nodes in the complete topology structure are extracted to obtain a component node set; first attribute data of each component node in the component node set is read in the component relationship database to obtain an attribute data set, wherein the first attribute data includes at least one of the following: component identifier, version identifier and state identifier; a first copy of the forward association mapping and a second copy of the reverse association mapping are extracted in the bidirectional adjacency list topology model; timestamp information is obtained, and the attribute data set, the first copy and the second copy are combined and packaged with the timestamp information to obtain the initial version snapshot.

[0008] Optionally, the attribute data is converted into the bidirectional adjacency list topology model in the storage medium, including: an initial bidirectional adjacency list topology model is constructed based on the attribute data; a depth-first search algorithm is used to traverse the bidirectional adjacency list topology model, and whether there is a loop dependency is detected in the traversal process, wherein the loop dependency is used to represent that there is a circular reference in the dependency relationship, so that at least one group of nodes forms a closed path through direct or indirect dependency relationship; if it is detected that there is a loop dependency, a first error log is generated, the modeling process is stopped, and a first message indicating the loop dependency error is generated, wherein the first error log at least includes loop path information; after the traversal is completed, the in-degree of all nodes in the initial bidirectional adjacency list topology model is scanned, wherein the in-degree is obtained by querying the length of the dependent list of the corresponding node in the reverse association mapping, and the length of the dependent list is used to represent the number of direct dependencies of the node by other components; if it is found by scanning that there is a first node with an in-degree of zero and not being a root node, a second error log is generated, and the modeling process is stopped, wherein the second error log at least includes the node identifier of the first node; if no loop dependency is detected and the in-degree of all non-root nodes is greater than zero, it is confirmed that the initial bidirectional adjacency list topology model passes the verification, and a bidirectional adjacency list topology model is obtained.

[0009] Optionally, determining the plurality of target underlying nodes to be changed indicated by the upgrade request comprises: taking the target underlying node as a starting point, recursively querying the upper nodes directly dependent on the target underlying node through the reverse association mapping of the initial version snapshot until the root node is queried to obtain a complete dependency path from the target underlying node to the root node; generating an affected node chain of each target underlying node according to the complete dependency path; splitting the affected node chain into a plurality of independent node update tasks and distributing the plurality of independent node update tasks to the plurality of worker nodes through a message queue; and each worker node creating a new version snapshot for the allocated node update task and updating the dependency pointers in the forward association mapping and the reverse association mapping, wherein the dependency pointers are used to indicate the versioned dependency relationship between nodes, and the dependency pointers include the forward dependency relationship of the source node to the new version target node and the reverse association relationship that the new version target node is dependent on the source node.

[0010] Optionally, the component upgrade method further comprises: the worker node locking the index update operation through a distributed lock mechanism when executing the node update task, so that only one worker node is used to update the index information at the same time; the worker node checking whether the node update task corresponding to the worker node has been processed before executing the node update task by querying the execution state of the upgrade transaction identifier stored in the distributed storage; if the checking result indicates that the node update task is in an unexecuted state, executing the node update task and updating the execution state of the upgrade transaction identifier in the distributed storage after the node update task is completed; and if the node update task fails, re-putting the failed node update task into the message queue for retry processing, and stopping the retry and marking the node corresponding to the node update task as an isolated state if the number of retries is greater than a preset threshold.

[0011] Optionally, publishing the target version snapshot comprises: writing the target version snapshot into a database, wherein the target version snapshot includes at least one of the following: a snapshot identifier, a root node identifier, version information, a generation timestamp, and a snapshot state; after completing the database writing, inserting a version log record into a version log table, wherein the version log record includes at least one of the following: a log identifier, a change content, metadata, and a previous log identifier; the change content includes a mapping relationship from an old snapshot identifier to a new snapshot identifier, and the metadata includes at least one of the following: a trigger identifier, a timestamp, and a number of affected nodes, and the previous log identifier is used to associate the current version log record with a historical version log record to form a log chain; caching the full-stack topology data corresponding to the snapshot identifier to a distributed cache system, and sending an upgrade completion event to a cloud management platform through a message middleware, wherein the full-stack topology data is data including all node attributes and forward and reverse association mapping relationships between nodes, and the upgrade completion event includes at least the snapshot identifier.

[0012] Optionally, after publishing the target version snapshot, the component upgrade method further comprises: receiving a rollback request, wherein the rollback request comprises: a target version log identifier; querying the old snapshot identifier corresponding to the target version log identifier from the version log table; loading the old snapshot corresponding to the old snapshot identifier, and reconstructing the bidirectional adjacency list topology model according to the node attribute data and the inter-node association relationship data in the old snapshot; performing a cascading update operation on the reconstructed bidirectional adjacency list topology model, and replacing the dependency pointers of the reconstructed bidirectional adjacency list topology model with the dependency relationships in the old snapshot; persisting the system state after rollback as a new snapshot, and inserting a rollback log record into the version log table, wherein the rollback log record comprises: a rollback source field, the rollback source field referencing the target version log identifier, and being used to identify the version log record based on which the current rollback operation is performed.

[0013] According to still another aspect of the present application, a component upgrade apparatus is also provided, comprising: a receiving module configured to receive an upgrade request, wherein the upgrade request comprises at least: component information of a target component to be upgraded; a conversion module configured to acquire attribute data of the target component in a component relationship database, and convert the attribute data into a bidirectional adjacency list topology model in a storage medium, the bidirectional adjacency list topology model comprising: a forward association mapping and a reverse association mapping, the forward association mapping being used to record a mapping relationship of each component to a downstream component of the component, and the reverse association mapping being used to record a mapping relationship of each component to an upstream component of the component; a capturing module configured to traverse the forward association mapping and the reverse association mapping in the bidirectional adjacency list topology model to capture a complete topology structure of the target component, and generate an initial version snapshot according to the complete topology structure; a determining module configured to determine a plurality of target underlying nodes to be changed indicated by the upgrade request, perform parallelized update on the plurality of target underlying nodes based on the initial version snapshot, integrate the updated target underlying nodes, generate a target version snapshot after completion of upgrade according to an integration result, and publish the target version snapshot.

[0014] According to still another aspect of the present application, a non-volatile storage medium is also provided, comprising a stored program, wherein the program, when executed, controls a device where the storage medium is located to perform the above component upgrade method.

[0015] According to still another aspect of the present application, an electronic device is also provided, comprising: a memory and a processor, the processor being configured to execute a program stored in the memory, wherein the program, when executed, performs the above component upgrade method.

[0016] According to still another aspect of the present application, a computer program is also provided, wherein the computer program, when executed by a processor, implements the above component upgrade method.

[0017] According to still another aspect of the present application, a computer program product is also provided, which comprises a non-volatile computer readable storage medium, wherein the non-volatile computer readable storage medium stores a computer program, which, when executed by a processor, implements the above component upgrade method.

[0018] In the present application, a reception upgrade request is adopted, wherein the upgrade request at least comprises component information of a target component to be upgraded; in the component relationship database, attribute data of the target component is acquired, the attribute data is converted into a bidirectional adjacency list topology model in a storage medium, the bidirectional adjacency list topology model comprises a forward association mapping and a reverse association mapping, the forward association mapping is used to record a mapping relationship of each component to a downstream component of the component, and the reverse association mapping is used to record a mapping relationship of each component to an upstream component of the component; the forward association mapping and the reverse association mapping in the bidirectional adjacency list topology model are traversed to capture a complete topology structure of the target component, and an initial version snapshot is generated according to the complete topology structure; a plurality of target underlying nodes to be changed indicated by the upgrade request are determined, parallelization update is performed on the plurality of target underlying nodes based on the initial version snapshot, the updated target underlying nodes are integrated, a target version snapshot after completion of the upgrade is generated according to an integration result, and the target version snapshot is published, so that the purposes of automatic and precise upgrade of components are achieved through the bidirectional index mechanism and the topology-aware cascading upgrade strategy, technical effects of improving component upgrade efficiency and reducing the probability of version misplacement are achieved, and the technical problems of low component upgrade efficiency and easy version misplacement caused by the related component upgrade method depending on manual operation are solved. BRIEF DESCRIPTION OF DRAWINGS

[0019] The accompanying drawings, which are included to provide a further understanding of the present application, constitute a part of the present application and illustrate embodiments of the present application and its description, which serve to explain the present application, and do not constitute improper limitations on the present application. In the drawings:

[0020] Figure 1 is a flowchart of a component upgrade method according to an embodiment of the present application;

[0021] Figure 2 is a structural diagram of a component upgrade device according to an embodiment of the present application;

[0022] Figure 3 is a hardware structural block diagram of a computer terminal of a component upgrade method according to an embodiment of the present application. DETAILED DESCRIPTION

[0023] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

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

[0025] According to an embodiment of this application, a method embodiment for a component upgrade method is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0026] Figure 1 This is a flowchart of a component upgrade method according to an embodiment of this application, such as... Figure 1 As shown, the method includes the following steps:

[0027] Step S102: Receive an upgrade request, wherein the upgrade request includes at least: component information of the target component to be upgraded.

[0028] The upgrade request is sent by the front-end page, and the target component can be the component to be upgraded in the cloud network product under the PSR design architecture.

[0029] In step S102, an upgrade request for the target component can be received via a REST API. The component information of the target component to be upgraded includes, but is not limited to, the universally unique identifier (UUID) of the component to be upgraded and the expected version information.

[0030] Following step S102, the following steps can also be performed: The legality of the upgrade request is checked, including permission verification and component status confirmation, to ensure that the component is currently in an upgrade-allowed state. If the upgrade request passes verification, a globally unique upgrade transaction ID is automatically generated to control the idempotency of the upgrade operation throughout the process, preventing duplicate upgrades or operation conflicts.

[0031] Step S104: In the component relationship database, obtain the attribute data of the target component and convert the attribute data into a bidirectional adjacency list topology model in the storage medium. The bidirectional adjacency list topology model includes: forward association mapping and reverse association mapping. The forward association mapping is used to record the mapping relationship from each component to its downstream components, and the reverse association mapping is used to record the mapping relationship from each component to its upstream components.

[0032] In step S104, detailed attribute data can be extracted from the component relational database using the UUID of the target component. This attribute data includes, but is not limited to, component ID, version, status, and related dependency types and weight information. The attribute data is then transformed into part of a bidirectional adjacency list topology model. The forward association mapping (forward index) records the links from each component to its downstream components; for example, `CloudNetwork3.0@V1` points to `CFS_200@1.0` and `CFS_201@1.0`. The reverse association mapping (reverse index) records which upstream components each component depends on; for example, `CFS_200@1.0` is referenced by `CloudNetwork3.0@V1`. The bidirectional index structure uses a combination of hash tables and linked lists to ensure fast retrieval and efficient updates of dependency relationships.

[0033] It's important to note that upstream components refer to those that provide functionality, services, or resources. These upstream components are depended upon or invoked by other components. In a hierarchical relationship, upstream components are at higher levels, and changes to them can affect all lower-level components that depend on them. For example, in a cloud network architecture, when Cloud Private Network 3.0 depends on a specific version of the Customer Facing Service (CFS), CFS is an upstream component of Cloud Private Network 3.0. Downstream components, on the other hand, depend on upstream components to perform their functions or obtain necessary resources. Downstream components are at lower levels and need to adapt to or respond to changes in their upstream components. In the example above, Cloud Private Network 3.0 is a downstream component relative to CFS because it requires the functionality and services provided by CFS to function properly.

[0034] Step S106: Traverse the forward and reverse association mappings in the bidirectional adjacency list topology model to capture the complete topology of the target component, and generate an initial version snapshot based on the complete topology.

[0035] In step S106, the bidirectional adjacency list topology model constructed in step S104 is traversed. By analyzing the forward association mapping and the reverse association mapping, the position of the target component in the whole architecture and the relationship between the target component and its upstream and downstream components can be accurately identified.

[0036] Specifically, starting from the target component, a reverse dependency mapping is used to trace back to all upper-level components that directly depend on the target component. Then, through the forward dependency mapping of these upper-level components, the process gradually expands to all related components in the entire dependency chain. These related components include, but are not limited to, business services, network services (Resource Facing Service, RFS), and even physical resources (Resource, RES). After capturing the topology, an initial version snapshot is generated. This snapshot includes the current state of the target component and all its related components, specifically including version, attributes, and other key information, as well as complete forward and reverse dependency mapping relationships.

[0037] Step S108: Determine the multiple target underlying nodes to be changed as indicated by the upgrade request, perform parallel updates on the multiple target underlying nodes based on the initial version snapshot, integrate the updated target underlying nodes, generate a target version snapshot with completed upgrade based on the integration result, and publish the target version snapshot.

[0038] In step S108, the upgrade request is parsed to locate multiple underlying nodes to be changed, such as RFS_300 being upgraded from version 2.1 to 2.2. Using the reverse association mapping in the initial version snapshot, all upper-layer components directly affected by the underlying node changes are quickly identified. The update task is then distributed in parallel to multiple worker nodes via a message queue, such as Kafka. Each worker node is responsible for handling the version upgrade of its assigned component, i.e., creating a new version snapshot and updating dependency pointers. During this process, distributed locks, such as Redis, are used to ensure the atomicity of index updates and avoid concurrent conflicts. Once all underlying nodes and their associated upper-layer components have completed the update, these new version nodes are integrated to generate a target version snapshot that has completed the upgrade. This target version snapshot includes the updated bidirectional adjacency list topology model. Finally, the target version snapshot is published and the new snapshot is loaded via a message bus, such as RabbitMQ, completing the version upgrade release process.

[0039] Based on the above steps, the upgrade request is received, and the upgrade request includes at least: component information of the target component to be upgraded; in the component relationship database, the attribute data of the target component is obtained, and the attribute data is transformed into a bidirectional adjacency list topology model in the storage medium. The bidirectional adjacency list topology model includes: forward association mapping and reverse association mapping. The forward association mapping is used to record the mapping relationship from each component to its downstream components, and the reverse association mapping is used to record the mapping relationship from each component to its upstream components; the forward association mapping and reverse association mapping in the bidirectional adjacency list topology model are traversed to capture the complete topology structure of the target component, and an initial version snapshot is generated based on the complete topology structure; multiple target underlying nodes to be changed as indicated by the upgrade request are identified, and multiple target underlying nodes are updated in parallel based on the initial version snapshot; the updated target underlying nodes are integrated, and a target version snapshot of the completed upgrade is generated based on the integration result, and the target version snapshot is published. Through the bidirectional indexing mechanism and the topology-aware cascading upgrade strategy, the goal of automated and accurate component upgrade is achieved, thereby realizing the technical effect of improving component upgrade efficiency and reducing the probability of version misalignment.

[0040] The following are Figure 1 The steps shown are illustrated and explained by way of example.

[0041] According to some optional embodiments of this application, traversing the forward and reverse association mappings in the bidirectional adjacency list topology model to capture the complete topology structure of the target component can be achieved by the following method: In the forward association mapping of the bidirectional adjacency list topology model, obtain the set of direct downstream components starting from the target component; by recursively querying the forward association mapping, expand the set of direct downstream components layer by layer to obtain all downstream components of the target component, thus obtaining the downstream topology structure; In the reverse association mapping of the bidirectional adjacency list topology model, obtain the set of direct upstream components starting from the target component; by recursively querying the reverse association mapping, expand the set of direct upstream components layer by layer to obtain all upstream components of the target component, thus obtaining the upstream topology structure; Integrate the downstream and upstream topologies to obtain the complete topology structure, wherein the complete topology structure includes all associated components and association relationships of the target component in the full dependency path.

[0042] In this embodiment, firstly, in the forward index of the bidirectional adjacency list topology model, the set of direct downstream components of the target component is obtained by querying the item with the target component ID as the key. Specifically, the list of IDs of all lower-level nodes that directly depend on the target component is assigned as values ​​to the target component, forming the basis of the downstream topology structure. Then, a depth-first traversal is performed on this set of direct downstream components, continuously querying the dependencies of each component in the forward index, expanding the set of downstream components layer by layer until all possible lower-level nodes are covered, thereby obtaining all downstream components of the target component and constructing a complete downstream topology structure. Next, in the reverse index of the bidirectional adjacency list topology model, similarly, the set of upper-level components that directly depend on it is collected by querying the item with the target component ID as the key. Specifically, the list of IDs of all upper-level components is used as the basis for the upstream associations of the target component. A depth-first traversal is performed on the set of direct upstream components, continuously querying which components each upper-level component in the reverse index depends on, thus expanding upwards layer by layer until all upstream components of the target component are obtained, constructing a complete upstream topology structure. Finally, the downstream topology structure and the upstream topology structure are integrated. In other words, all related components in the downstream and upstream regions, as well as their dependencies, are aggregated to form a complete topology for the target component.

[0043] According to some alternative embodiments of this application, generating an initial version snapshot based on the complete topology can be achieved by the following method: extracting all component nodes in the complete topology to obtain a set of component nodes; reading the first attribute data of each component node in the component node set from the component relationship database to obtain an attribute data set, wherein the first attribute data includes at least one of the following: component identifier, version identifier, and status identifier; extracting a first copy of the forward association mapping and a second copy of the reverse association mapping from the bidirectional adjacency list topology model; obtaining timestamp information, and combining and encapsulating the attribute data set, the first copy, and the second copy with the timestamp information to obtain the initial version snapshot.

[0044] In this embodiment, firstly, all component nodes are extracted from the complete topology to construct a component node set. This set includes all layers under the PSR architecture, including but not limited to communication services / products, business services, network services, and physical resources. Then, a connection is established with the component relational database using Java Database Connection (JDBC), and the first attribute data of each component node in the component node set is read one by one to form an attribute data set. This first attribute data includes, but is not limited to, component identifier, version identifier, and status identifier, ensuring that the snapshot includes all necessary basic information. A first copy of the forward index and a second copy of the reverse index are generated from the bidirectional adjacency list topology model. Both copies fully preserve the dependencies between component nodes; the forward index records the lower-level nodes that each component depends on, and the reverse index records the upper-level nodes that depend on the current component. Next, the current precise timestamp information is obtained. This timestamp information identifies the specific time the snapshot was generated, facilitating subsequent version management and traceability. Finally, the attribute data set, the first copy (a copy of the forward index), the second copy (a copy of the reverse index), and the obtained timestamp information are combined and encapsulated to generate an initial version snapshot. The initial version snapshot includes the complete state and topology of the cloud private network product and all its associated nodes at a specific point in time, preparing an atomic baseline version for subsequent version upgrades and propagation.

[0045] In some optional embodiments of this application, the attribute data is transformed into a bidirectional adjacency list topology model in the storage medium, which can be achieved by the following method: constructing an initial bidirectional adjacency list topology model based on the attribute data; traversing the bidirectional adjacency list topology model using a depth-first search algorithm, detecting the existence of circular dependencies during the traversal process, wherein a circular dependency is used to indicate that there is a circular reference in the dependency relationship, such that at least one set of nodes forms a closed path through direct or indirect dependencies; if a circular dependency is detected, a first error log is generated, the modeling process is stopped, and a first message indicating the circular dependency error is generated, wherein the first error log contains at least This includes information on loop paths; after traversal, the in-degree of all nodes in the initial bidirectional adjacency list topology model is scanned. The in-degree is obtained by querying the length of the dependency list of the corresponding node in the reverse association mapping. The dependency list length is used to represent the number of nodes that are directly depended on by other components. If the scan finds a first node with an in-degree of zero that is not the root node, a second error log is generated, and the modeling process is stopped. The second error log includes at least the node identifier of the first node. If no loop dependencies are detected and the in-degree of all non-root nodes is greater than zero, the initial bidirectional adjacency list topology model is confirmed to have passed the verification, and the bidirectional adjacency list topology model is obtained.

[0046] In this embodiment, firstly, an initial bidirectional adjacency list topology model is constructed based on the attribute data set read from the component relational database. Component identifiers, version identifiers, and status identifiers are integrated into the model, and the structures of forward indexes and reverse indexes are established. The forward index is used to record the lower-level nodes that each component directly depends on, while the reverse index records the upper-level nodes that depend on each component.

[0047] Then, a depth-first search algorithm is used to traverse the constructed bidirectional adjacency list topology model. During the traversal, the existence of circular dependencies is checked, that is, whether any pair of nodes forms a closed path through direct or indirect dependencies. If a circular dependency is found, the specific circular path information is recorded in the first error log, and the subsequent modeling process is stopped. A first message indicating the circular dependency error is generated, indicating the existence of the circular dependency. Furthermore, after completing the traversal, the in-degree of all nodes in the initial bidirectional adjacency list topology model is scanned, that is, the length of the dependent list of the corresponding node in the reverse association mapping is queried to assess the number of nodes directly referenced by other components. If a non-root node with an in-degree of zero is found during the scan, it means that an isolated first node exists and cannot be referenced by other components. At this time, a second error log is generated, which includes the node identifier of the first node, and the modeling process is stopped. If no circular dependencies are detected during the traversal and the in-degree of all non-root nodes is greater than zero, the initial bidirectional adjacency list topology model is considered to have passed the validation.

[0048] As some optional embodiments of this application, determining multiple target underlying nodes to be changed as indicated by the upgrade request, and performing parallel updates on multiple target underlying nodes based on the initial version snapshot, can be achieved by the following method: starting from the target underlying node, recursively querying the upper-level nodes that directly depend on the target underlying node through the reverse association mapping of the initial version snapshot, until the root node is reached, to obtain the complete dependency path from the target underlying node to the root node; generating an affected node chain for each target underlying node based on the complete dependency path; splitting the affected node chain into multiple independent node update tasks, and distributing the multiple independent node update tasks to multiple worker nodes through a message queue; each worker node creating a new version snapshot for the assigned node update task, and updating the dependency pointers in the forward association mapping and reverse association mapping, wherein the dependency pointers are used to indicate the versioned dependency relationship between nodes, and the dependency pointers include the forward dependency relationship of the source node to the new version target node, and the reverse association relationship of the new version target node being depended on by the source node.

[0049] In this embodiment, firstly, a target bottom-level node is selected. Utilizing the reverse association mapping in the initial version snapshot, a recursive query is executed starting from this bottom-level node to locate all upper-level nodes that directly depend on it. This recursive query process continues until the root node is reached, thus forming a complete dependency path from the target bottom-level node to the root node's PSR. For example, for an upgrade of RFS_300@2.1, the inverted index identifies CFS_200@1.0, which directly depends on it. Then, the inverted index of CFS_200 identifies PSRs that depend on CFS_200, such as Cloud Private Network 3.0@V1, thus constructing a full-stack dependency path from RFS_300 to Cloud Private Network 3.0. Based on the established complete dependency path, an affected node chain is generated for each target bottom-level node. The affected node chain includes not only the target bottom-level node itself but also all upper-level nodes linked through dependency relationships, ensuring accurate definition of the full-stack upgrade scope.

[0050] The resulting chain of affected nodes is then further broken down into several independent node update tasks, each task performing an upgrade operation on a single node. These independent node update tasks are then evenly distributed to multiple pre-defined worker nodes using message queues such as Kafka, enabling parallel processing and significantly improving the efficiency of the full-stack upgrade.

[0051] Finally, after receiving the assigned node update task, each worker node creates a new version snapshot for the nodes in the update task. For example, it clones a new version of CFS_200, such as CFS_200@2.0, from the old version CFS_200@1.0. It also updates the dependency pointers in the forward and reverse association maps to ensure that the correct versioning dependencies between the old and new versions are reflected.

[0052] In some optional embodiments of this application, the component upgrade method may further include the following steps: when a worker node executes a node update task, it locks the index update operation through a distributed lock mechanism so that only one worker node can update the index information at the same time; before executing the node update task, the worker node checks whether the node update task corresponding to the worker node has been processed by querying the execution status of the upgrade transaction identifier stored in the distributed storage; if the check result indicates that the node update task is in an unexecuted state, the node update task is executed, and after the node update task is completed, the execution status of the upgrade transaction identifier in the distributed storage is updated; if the node update task fails, the failed node update task is put back into the message queue for retry processing, and if the number of retries exceeds a preset threshold, retries are stopped and the node corresponding to the node update task is marked as isolated.

[0053] In this embodiment, after receiving a node update task, the worker node first locks the bidirectional index update operation using a distributed lock mechanism to ensure that only one worker node can modify the index information at any given time, thereby avoiding data conflicts caused by concurrent updates. Before updating the index, the worker node queries distributed storage such as Redis to check the execution status of the upgrade transaction ID related to the current task to determine whether the task has been processed by other nodes. If the status shows "not executed," the worker node will start executing the node update task, which may include creating a new version snapshot and updating dependency pointers. After the node update task is successfully completed, the execution status of the upgrade transaction ID is updated to "completed" in a database such as Redis. If the node update task fails during execution, the worker node resubmits the failed task to the message queue, triggering a retry mechanism, and limiting the number of retries to no more than a preset threshold. When this threshold is reached or exceeded, further retries for the task are stopped, and the node corresponding to the failed task is placed in an isolated state to ensure that subsequent operations will not affect this unstable or unupgradeable component.

[0054] The aforementioned rigorous execution status checks and retry mechanisms can effectively ensure the idempotency and robustness of the component upgrade process, thereby improving component stability and upgrade success rate.

[0055] As some alternative embodiments of this application, publishing a target version snapshot can be achieved through the following methods: writing the target version snapshot to a database, wherein the target version snapshot includes at least one of the following: snapshot identifier, root node identifier, version information, generation timestamp, and snapshot status; after completing the database writing, inserting version log records into the version log table, wherein the version log records include at least one of the following: log identifier, change content, metadata, and preceding log identifier; the change content includes: the mapping relationship from the old snapshot identifier to the new snapshot identifier, the metadata includes at least one of the following: trigger identifier, timestamp, and number of affected nodes, and the preceding log identifier is used to associate the current version log record with the historical version log record to form a log chain; caching the full-stack topology data corresponding to the snapshot identifier to a distributed caching system, and sending an upgrade completion event to the cloud management platform through a message middleware, wherein the full-stack topology data includes data including all node attributes and the forward and reverse association mapping relationships between nodes, and the upgrade completion event includes at least the snapshot identifier.

[0056] In this embodiment, the target version snapshot information is first written to the database. The target version snapshot includes key elements such as snapshot identifier, root node identifier, version information, generation timestamp, and snapshot status. For example, the snapshot status is initially marked as "read-only" to support subsequent safe rollback operations. Next, a new version log record is inserted into the version log table. The new version log record records the log identifier of the current change, the specific content of the change, related metadata, and the preceding log identifier. The change content represents the mapping relationship from the old snapshot identifier to the new snapshot identifier. The metadata includes the trigger identifier, timestamp, and the number of affected nodes, providing contextual information for the change operation. The preceding log identifier connects the current log record with historical version log records, forming an ordered log chain, providing a basis for future version backtracking and auditing. Finally, full-stack topology data caching is performed. The full-stack topology data corresponding to the target version snapshot, including complete information such as all node attributes and the forward and reverse association mapping relationships between nodes, is cached in a distributed caching system such as a Redis cluster to accelerate the speed and efficiency of subsequent calls. At the same time, an upgrade completion event is sent to the cloud management platform through a message middleware such as RabbitMQ. The upgrade completion event carries the target snapshot identifier to promptly notify the cloud management platform of important information about the version change, so as to facilitate subsequent management and operation.

[0057] In some optional embodiments, after publishing the target version snapshot, the component upgrade method may further perform the following steps: receiving a rollback request, wherein the rollback request includes: a target version log identifier; querying the old snapshot identifier corresponding to the target version log identifier from the version log table; loading the old snapshot corresponding to the old snapshot identifier, and reconstructing the bidirectional adjacency list topology model based on the node attribute data and node association data in the old snapshot; performing a cascading update operation on the reconstructed bidirectional adjacency list topology model, and replacing the dependency pointers of the reconstructed bidirectional adjacency list topology model with the dependency relationships in the old snapshot; persisting the rolled-back system state as a new snapshot, and inserting a rollback log record into the version log table, wherein the rollback log record includes: a rollback source field, which references the target version log identifier and is used to identify the version log record on which this rollback operation is based.

[0058] In this embodiment, a rollback request is received, which includes a target version log identifier. This identifier is a record of a previous upgrade operation, used to locate the specific historical version state to which the rollback needs to be performed. Based on the received target version log identifier, the corresponding old snapshot identifier is retrieved from the version log table. Using the preceding log identifier in the log chain, the old snapshot can be quickly located, thus obtaining a snapshot of the system state before the upgrade. The old snapshot corresponding to the aforementioned old snapshot identifier is loaded. Receiving the rollback request not only reads the node attribute data from the old snapshot but also includes complete information on the forward and reverse association mapping relationships between nodes. Based on this, the data from the old snapshot is applied to the bidirectional adjacency list topology model constructed during the initialization phase, performing topology model reconstruction to ensure that the model accurately reflects the system state before the rollback.

[0059] Perform a cascading update operation on the reconstructed bidirectional adjacency list topology model. Specifically, assign the dependencies from the old snapshot to the dependency pointers of the reconstructed topology model, replacing the current pointers, ensuring that the system state is restored to the specified historical version state. Convert the rolled-back system state into a new snapshot and persist it. Simultaneously, insert a rollback log record into the version log table, recording the metadata of this rollback operation. This metadata includes, but is not limited to, timestamps, trigger identifiers, and the number of affected nodes. A rollback source field is specifically set, referencing the target version log identifier, accurately identifying the version log record on which this rollback operation is based, thus forming a complete rollback history.

[0060] This application also provides another component upgrade method, which specifically includes the following steps:

[0061] Step S1: The front-end page sends an upgrade request to the autonomous upgrade system via REST API. The upgrade request carries the unique identifier and version information of the target component. The legality of the request is uniformly verified (such as permission verification and whether the component status is "upgradeable"). After passing the verification, a globally unique upgrade transaction ID is generated (format: Upgrade-TX-{timestamp}-{SHA256(component UUID+version)}) for idempotency control throughout the process.

[0062] Step S2: Receive the upgrade transaction ID and target component information from Step S1; connect to the component relational database via JDBC, execute query SQL statements, and load the target component and all its associated P / CFS / RFS / RES nodes (including node attributes: ID, version, status; relational attributes: dependency type, weight) in one go.

[0063] Topology transformation: The pulled data is transformed into a bidirectional adjacency list topology model in memory: Forward index (hash table): key = node ID, value = list of directly dependent nodes (e.g., CloudNet3.0@V1→[CFS_200@1.0,CFS_201@1.0]); Reverse index (hash table): key = node ID, value = list of directly dependent upper-level nodes (e.g., CFS_200@1.0→[CloudNet3.0@V1]) (Both bidirectional indexes adopt the "hash table + linked list" structure, supporting O(1) complexity dependency retrieval and dynamic updates);

[0064] Topology logic verification: Loop detection: The topology is traversed using a depth-first search. If a node is found to be visited repeatedly during the traversal (e.g., CFS_A→RFS_B→CFS_A), an error log (containing the loop path) is generated, the modeling is terminated, and a "loop dependency error" is returned.

[0065] Orphan node verification: Scan the in-degree of all nodes (the number of times they are depended on in the inverted index). If there is an in-degree of 0 and it is not a root node (such as the detached RFS_999@1.0), generate an error log and terminate the modeling process.

[0066] Generate initial version snapshot: After verification, generate an atomic baseline snapshot (such as "Cloud Private Network 3.0@V1 Full Stack Topology") containing all dependency paths in memory. The snapshot includes: ID / version / attribute of all nodes, complete copies of forward / reverse indexes, and snapshot generation timestamp.

[0067] Step S3: Receive the initial snapshot and upgrade transaction ID from Step S2; parse the upgrade request, locate the underlying node that needs to be changed (e.g., “RFS_300@2.1→2.2”), and identify the directly dependent node (CFS_200@1.0) through the reverse index of the initial snapshot (RFS_300@2.1→[CFS_200@1.0]); recursively traverse the dependency chain: starting from CFS_200@1.0, recursively query the upper-level dependent nodes (e.g., CFS_200@1.0→Cloud Private Network 3.0@V1) through the reverse index, and generate the complete chain of affected nodes: RFS_300@2.1→CFS_200@1.0→Cloud Private Network 3.0@V1;

[0068] Parallelized snapshot cloning and pointer update: The affected node chain is split into independent tasks and distributed to multiple worker nodes via Kafka message queues (the number of concurrency is determined by the configuration parameters in step S1); each worker node creates a new version snapshot for the assigned node (e.g., CFS_200@2.0 is cloned from CFS_200@1.0) and updates the dependency pointers: forward index: CFS_200@2.0 → [RFS_300@2.2] (replacing the old version dependency);

[0069] Reverse index: RFS_300@2.2 → [CFS_200@2.0] (new association); worker nodes use Redis distributed locks to ensure the atomicity of index updates (avoiding concurrent conflicts); idempotency control and exception handling: each task carries an upgrade transaction ID, and the worker node checks the execution status of that ID in Redis (not executed / completed) before execution to avoid duplicate processing; if a task fails (e.g., network timeout), the task is put back into the queue (retry count ≤ 3), and if the threshold is exceeded, it is marked as "failed" and the node is isolated;

[0070] Generate a full-stack snapshot after the upgrade: After all nodes are updated, integrate all new version nodes and generate a snapshot of "Cloud Private Network 3.0@V2 Full-Stack Topology" (including the updated bidirectional index).

[0071] Step S4: Receive the upgraded snapshot and upgrade transaction ID from step S3;

[0072] Transactional persistence: Start a distributed transaction (based on TCC mode) and write the upgraded snapshot to the database: The main table component_snapshot stores the snapshot ID, root node ID, version, generation time, and snapshot status ("read-only").

[0073] Sub-table node_relation: Batch writes the ID / version / attribute and forward / reverse relationships of all nodes (using "batch INSERT + unique key constraint" to avoid duplicates);

[0074] Version log chain generation: After the transaction is committed, a log record is inserted into the version_log table, which includes: Log ID: Log-{upgrade transaction ID};

[0075] Changes: Snapshot-ID-1 → Snapshot-ID-2 (Old → New snapshot mapping); Metadata: Trigger ID, Timestamp, Number of Affected Nodes;

[0076] Logs are associated with the previous log entry through the prev_log_id field, forming an ordered linked list (log chain).

[0077] Snapshot caching and notification: Cache the full-stack topology corresponding to Snapshot-ID-2 to the Redis cluster (expiration time = 7 days), and send an "upgrade complete" event (carrying the snapshot ID) to the cloud management platform via RabbitMQ.

[0078] Step S5: The administrator initiates a rollback request via API (specifying the target version log ID); based on the target log ID, the administrator queries the corresponding old snapshot ID (e.g., Snapshot-ID-1) from the log chain; loads the old snapshot, and rebuilds the memory topology (reusing the bidirectional index structure of step S2);

[0079] Repeat the cascading update logic of step S3, replacing the dependency pointer with the relationship in the old snapshot (e.g., CFS_200@2.0→RFS_300@2.1); persist the rolled-back snapshot and add a new rollback log entry (marked with the rollback_from field).

[0080] Figure 2 This is a structural diagram of a component upgrade device according to an embodiment of this application, such as... Figure 2 As shown, the device includes:

[0081] The receiving module 22 is used to receive an upgrade request, wherein the upgrade request includes at least: component information of the target component to be upgraded.

[0082] The transformation module 24 is used to obtain the attribute data of the target component from the component relationship database and transform the attribute data into a bidirectional adjacency list topology model in the storage medium. The bidirectional adjacency list topology model includes: forward association mapping and reverse association mapping. The forward association mapping is used to record the mapping relationship from each component to its downstream components, and the reverse association mapping is used to record the mapping relationship from each component to its upstream components.

[0083] The capture module 26 is used to traverse the forward and reverse association mappings in the bidirectional adjacency list topology model to capture the complete topology structure of the target component and generate an initial version snapshot based on the complete topology structure.

[0084] The determination module 28 is used to determine the multiple target underlying nodes to be changed as indicated by the upgrade request, perform parallel updates on the multiple target underlying nodes based on the initial version snapshot, integrate the updated target underlying nodes, generate a target version snapshot with the completed upgrade based on the integration result, and publish the target version snapshot.

[0085] Optionally, traversing the forward and reverse association mappings in the bidirectional adjacency list topology model to capture the complete topology structure of the target component includes the following steps: In the forward association mapping of the bidirectional adjacency list topology model, obtain the set of direct downstream components starting from the target component; by recursively querying the forward association mapping, expand the set of direct downstream components layer by layer to obtain all downstream components of the target component, thus obtaining the downstream topology structure; In the reverse association mapping of the bidirectional adjacency list topology model, obtain the set of direct upstream components starting from the target component; by recursively querying the reverse association mapping, expand the set of direct upstream components layer by layer to obtain all upstream components of the target component, thus obtaining the upstream topology structure; Integrate the downstream and upstream topologies to obtain the complete topology structure, wherein the complete topology structure includes all associated components and relationships of the target component in the full dependency path.

[0086] Optionally, an initial version snapshot is generated based on the complete topology, specifically including the following steps: extracting all component nodes in the complete topology to obtain a set of component nodes; reading the first attribute data of each component node in the component node set from the component relationship database to obtain an attribute data set, wherein the first attribute data includes at least one of the following: component identifier, version identifier, and status identifier; extracting the first copy of the forward association mapping and the second copy of the reverse association mapping from the bidirectional adjacency list topology model; obtaining timestamp information, and combining and encapsulating the attribute data set, the first copy, and the second copy with the timestamp information to obtain the initial version snapshot.

[0087] Optionally, the attribute data is transformed into a bidirectional adjacency list topology model in the storage medium, specifically including the following steps: constructing an initial bidirectional adjacency list topology model based on the attribute data; traversing the bidirectional adjacency list topology model using a depth-first search algorithm, detecting the existence of circular dependencies during the traversal process, wherein a circular dependency is used to indicate that there is a circular reference in the dependency relationship, such that at least one set of nodes forms a closed path through direct or indirect dependencies; if a circular dependency is detected, a first error log is generated, the modeling process is stopped, and a first message indicating the circular dependency error is generated, wherein the first error log includes at least the circular path. Information; After traversal, scan the in-degree of all nodes in the initial bidirectional adjacency list topology model. The in-degree is obtained by querying the length of the dependency list of the corresponding node in the reverse association mapping. The dependency list length is used to represent the number of nodes that are directly depended on by other components. If the scan finds a first node with an in-degree of zero that is not the root node, generate a second error log and stop the modeling process. The second error log must include at least the node identifier of the first node. If no cyclic dependency is detected and the in-degree of all non-root nodes is greater than zero, the initial bidirectional adjacency list topology model is confirmed to have passed the verification, and the bidirectional adjacency list topology model is obtained.

[0088] Optionally, the multiple target underlying nodes to be changed as indicated by the upgrade request are identified, and the multiple target underlying nodes are updated in parallel based on the initial version snapshot. Specifically, this includes the following steps: starting from the target underlying node, recursively querying the upper-level nodes that directly depend on the target underlying node through the reverse association mapping of the initial version snapshot, until the root node is reached, to obtain the complete dependency path from the target underlying node to the root node; generating the affected node chain for each target underlying node based on the complete dependency path; splitting the affected node chain into multiple independent node update tasks, and distributing the multiple independent node update tasks to multiple worker nodes through a message queue; each worker node creates a new version snapshot for the assigned node update task and updates the dependency pointers in the forward association mapping and reverse association mapping, wherein the dependency pointer is used to indicate the versioned dependency relationship between nodes, and the dependency pointer includes the forward dependency relationship of the source node to the new version target node, and the reverse association relationship of the new version target node being depended on by the source node.

[0089] Optionally, the component upgrade device can also be used to perform the following steps: When a worker node executes a node update task, it locks the index update operation through a distributed lock mechanism so that only one worker node can update the index information at the same time; before executing the node update task, the worker node checks whether the node update task corresponding to the worker node has been processed by querying the execution status of the upgrade transaction identifier stored in the distributed storage; if the check result indicates that the node update task is in an unexecuted state, the node update task is executed, and after the node update task is completed, the execution status of the upgrade transaction identifier in the distributed storage is updated; if the node update task fails, the failed node update task is put back into the message queue for retry processing, and if the number of retries exceeds a preset threshold, retries are stopped and the node corresponding to the node update task is marked as isolated.

[0090] Optionally, publishing the target version snapshot includes the following steps: writing the target version snapshot to a database, wherein the target version snapshot includes at least one of the following: snapshot identifier, root node identifier, version information, generation timestamp, and snapshot status; after completing the database write, inserting version log records into the version log table, wherein the version log records include at least one of the following: log identifier, change content, metadata, and preceding log identifier; the change content includes: the mapping relationship from the old snapshot identifier to the new snapshot identifier, the metadata includes at least one of the following: trigger identifier, timestamp, and number of affected nodes, and the preceding log identifier is used to associate the current version log record with the historical version log record to form a log chain; caching the full-stack topology data corresponding to the snapshot identifier to a distributed cache system, and sending an upgrade completion event to the cloud management platform through a message middleware, wherein the full-stack topology data includes data including all node attributes and the forward and reverse association mapping relationships between nodes, and the upgrade completion event includes at least the snapshot identifier.

[0091] Optionally, after publishing the target version snapshot, the component upgrade device can further perform the following steps: receiving a rollback request, wherein the rollback request includes: a target version log identifier; querying the old snapshot identifier corresponding to the target version log identifier from the version log table; loading the old snapshot corresponding to the old snapshot identifier, and reconstructing the bidirectional adjacency list topology model based on the node attribute data and node association data in the old snapshot; performing a cascading update operation on the reconstructed bidirectional adjacency list topology model, and replacing the dependency pointers of the reconstructed bidirectional adjacency list topology model with the dependency relationships in the old snapshot; persisting the rolled-back system state as a new snapshot, and inserting a rollback log record into the version log table, wherein the rollback log record includes: a rollback source field, which references the target version log identifier and is used to identify the version log record on which this rollback operation is based.

[0092] It should be noted that the above Figure 2 The modules in can be program modules (e.g., a set of program instructions that implements a specific function) or hardware modules. For the latter, they can be represented in the following forms, but are not limited to these: each of the above modules is represented by a processor, or the functions of each of the above modules are implemented by a processor.

[0093] It should be noted that, Figure 2 Preferred embodiments of the shown examples can be found in [reference needed]. Figure 1 The relevant descriptions of the embodiments shown will not be repeated here.

[0094] This application also provides another component upgrade device, which specifically includes: a component dependency graph modeling engine module, a version upgrade propagation module, and a graph version management module.

[0095] The component depends on the graph modeling engine module to perform the following steps.

[0096] When the Cloud Private Network product 3.0 needs to be upgraded from V1 to V2, the component dependency graph modeling engine module first captures the upgrade request and initiates a full data query to the database. It then loads Cloud Private Network 3.0@V1 and all its associated nodes at once, including CFS_200@1.0 (carrying enterprise VPN services), CFS_201@1.0 (carrying cloud interconnection services), and underlying resource functions RFS_300@2.1 (IPRAN access) and RFS_301@2.0 (CN2 backbone network access), up to the physical resource RES_400@3.2 (100G port). The engine converts each record into a topology object in memory. The Cloud Private Network 3.0 node contains two outgoing edges pointing to CFS_200 and CFS_201, while the CFS_200 node is referenced by Cloud Private Network 3.0 through an incoming edge and its outgoing edge points to RFS_300. This bidirectional adjacency list structure allows searching for direct dependencies (e.g., Cloud Private Network 3.0 → CFS_200) or dependent relationships (e.g., RFS_300 ← CFS_200) of any node to only require O(1) time complexity. After initial loading, the engine initiates topology verification. If an unexpected loop error is found, the engine immediately terminates modeling and throws an "error message" to avoid logical deadlock. Isolated node verification involves scanning nodes with an in-degree of zero; if an isolated node is found, an "error message" is also thrown and modeling is terminated. After verification, the engine replicates the new Cloud Private Network@V2 node in memory, retaining references to the original versions CFS_200@1.0 and CFS_201@1.0, and simultaneously adding a new PSR_100@V2 reference record for these two CFS nodes in the inverted index. If an upgrade request for CFS_200 occurs at this point, the inverted index can instantly locate its dependency on PSR_100@V2. To accelerate subsequent queries, the engine caches the complete path (P→CFS→RFS→RES) from Cloud Private Network 3.0@V2 to the leaf node RES_400 in the Redis cluster, laying the foundation for subsequent calls. Finally, the engine writes the in-memory topology to the database in batches using distributed transactions. A "snapshot isolation" mechanism is used during the write: Cloud Private Network 3.0@V2 and its associated edges are first marked as read-only versions, and then all changes are atomically committed. For example, when writing to the RFS_300@2.1 node, its `depends_on` relationship attribute with CFS_200@1.0 is simultaneously persisted, ensuring that even if RFS_300 is subsequently upgraded to version 2.2, the historical snapshots still retain the accurate dependency state at the V2 time. After persistence is completed, the engine publishes an event through the message bus, carrying the version fingerprint (such as `PSR_Cloud Private Network 3.0-V2-SHA256`) to notify the configuration management system to load the new topology, thus completing the entire closed loop from dynamic modeling to static snapshots.

[0097] The version upgrade propagation module is used to perform the following steps.

[0098] After receiving notification of a version update for an underlying component or service component, the version upgrade propagation module initiates tracking and recursive updates to the entire dependency graph. Taking the upgrade of IPRANPW Access Service RFS from version 2.1 to 2.2 as an example, the version upgrade propagation module first retrieves all upper-layer service nodes (CFS) that directly depend on IPRANPW Access Service RFS 2.1 from the inverted index. Then, it clones a new version snapshot in memory for each affected node and updates the reference to IPRANPW Access Service RFS to 2.2 in the dependency list of the new snapshot. After updating the first-level CFS nodes, the version upgrade propagation module also queries the inverted index for the top-level product node pointing to CFS, creates a Cloud Private Network 3.0V2 version snapshot for it, replaces its dependency pointer from the old CFSV1.0 to the new CFSV2.2, and retains the reference to CFSV1.0. In its implementation, the version upgrade propagation module does not process all nodes sequentially in a single thread. Instead, it distributes the initial event to a dedicated upgrade queue via an asynchronous message bus. The consumer process retrieves tasks from the queue in parallel, performs a depth-first traversal on each reference chain, dynamically generates new node snapshots in memory, and maintains new forward and reverse indexes. Once a new snapshot is created and dependent pointers are updated, the version upgrade propagation module writes these snapshots to the underlying database in batches and marks them as "completed." If a task fails due to network or storage anomalies, the retry mechanism determines whether to skip or re-execute based on the task's unique transaction ID to ensure the idempotency of the entire cascading upgrade process. At the end of the entire propagation process, the system triggers a callback notification, enabling the immediate acquisition of new version node information to complete the design of subsequent PSR objects.

[0099] The map version management module is used to perform the following steps.

[0100] After all node snapshots are generated, the graph version management module takes over the persistence and auditing work. Taking Cloud Private Network V2 and its related CFS, RFS, and RES nodes as an example, the graph version management module first writes the nodes in memory and their dependencies to the database in a transactional manner, and inserts a version log in the same transaction, recording the trigger, timestamp, and pointer mapping before and after the change. Each log is stored in a dedicated log table in the form of an ordered linked list. When a rollback is needed, the system will traverse the linked list in reverse order and restore the reference pointers of each node in turn. In daily operation and maintenance, administrators can query the complete version history of any node through a unified REST interface. The graph version management module returns all snapshot records of Cloud Private Network 3.0 from V1 to V2 and details of their associated events. At this time, if it is necessary to restore the system to a version at a certain point in history, the graph version management module rebuilds the dependency pointers according to the log order and triggers the sub-process of the dependency graph modeling engine, synchronizing each layer of objects downwards layer by layer until all CFS, RFS, and RES nodes return to the specified V1 state, ensuring system consistency. It can also be combined with the monitoring system to generate complete version evolution reports, providing detailed evidence for compliance audits and problem investigation.

[0101] Figure 3 A hardware block diagram of a computer terminal for implementing a component upgrade method is shown. Figure 3 As shown, the computer terminal 30 may include one or more processors 302 (shown as 302a, 302b, ..., 302n in the figure) 302 (processor 302 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 304 for storing data, and a transmission module 306 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 3 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 30 may also include... Figure 3 The more or fewer components shown, or having the same Figure 3 The different configurations shown.

[0102] It should be noted that the aforementioned one or more processors 302 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 30. As involved in the embodiments of this application, the data processing circuits serve as processor control (e.g., selection of a variable resistor termination path connected to an interface).

[0103] The memory 304 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the component upgrade method in this embodiment. The processor 302 executes various functional applications and data processing by running the software programs and modules stored in the memory 304, thereby realizing the aforementioned component upgrade method. The memory 304 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 304 may further include memory remotely located relative to the processor 302, and these remote memories can be connected to the computer terminal 30 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

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

[0105] The display may be, for example, a touchscreen liquid crystal display (LCD) that allows the user to interact with the user interface of the computer terminal 30.

[0106] It should be noted here that, in some optional embodiments, the above... Figure 3 The computer terminal shown may include hardware elements (including circuitry), software elements (including computer code stored on a computer-readable medium), or a combination of both hardware and software elements. It should be noted that... Figure 3 This is only one instance of a specific particular instance, and is intended to illustrate the types of components that may exist in the aforementioned computer terminal.

[0107] It should be noted that, Figure 3 The computer terminal shown is used to execute Figure 1 The component upgrade method shown above is also applicable to this electronic device, and will not be repeated here.

[0108] This application also provides a non-volatile storage medium, which includes a stored program, wherein the program, when running, controls the device where the storage medium is located to execute the above-mentioned component upgrade method.

[0109] A non-volatile storage medium performs the following functions: receiving an upgrade request, wherein the upgrade request includes at least: component information of the target component to be upgraded; retrieving attribute data of the target component from a component relationship database, converting the attribute data into a bidirectional adjacency list topology model in the storage medium, the bidirectional adjacency list topology model including: forward association mapping and reverse association mapping, the forward association mapping being used to record the mapping relationship from each component to its downstream components, and the reverse association mapping being used to record the mapping relationship from each component to its upstream components; traversing the forward association mapping and reverse association mapping in the bidirectional adjacency list topology model to capture the complete topology structure of the target component, and generating an initial version snapshot based on the complete topology structure; determining multiple target underlying nodes to be changed as indicated by the upgrade request, updating the multiple target underlying nodes in parallel based on the initial version snapshot, integrating the updated target underlying nodes, generating a target version snapshot with the completed upgrade based on the integration result, and publishing the target version snapshot.

[0110] This application also provides an electronic device, including a memory and a processor, wherein the processor is used to run a program stored in the memory, wherein the program executes the above-described component upgrade method during runtime.

[0111] The processor runs a program that performs the following functions: receiving an upgrade request, wherein the upgrade request includes at least: component information of the target component to be upgraded; retrieving attribute data of the target component from the component relationship database, converting the attribute data into a bidirectional adjacency list topology model in the storage medium, the bidirectional adjacency list topology model including: forward association mapping and reverse association mapping, the forward association mapping being used to record the mapping relationship from each component to its downstream components, and the reverse association mapping being used to record the mapping relationship from each component to its upstream components; traversing the forward association mapping and reverse association mapping in the bidirectional adjacency list topology model to capture the complete topology structure of the target component, and generating an initial version snapshot based on the complete topology structure; determining multiple target underlying nodes to be changed as indicated by the upgrade request, updating the multiple target underlying nodes in parallel based on the initial version snapshot, integrating the updated target underlying nodes, generating a target version snapshot with the completed upgrade based on the integration result, and publishing the target version snapshot.

[0112] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

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

[0114] In the above embodiments of this application, the information collected is information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data all comply with relevant laws, regulations and standards, take necessary protective measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse.

[0115] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0116] 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 units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0117] 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.

[0118] 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 medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to related technologies, 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 storage medium 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 described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0119] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A component upgrade method, characterized in that, include: Receive an upgrade request, wherein the upgrade request includes at least: component information of the target component to be upgraded; In the component relationship database, the attribute data of the target component is obtained, and the attribute data is transformed into a bidirectional adjacency list topology model in the storage medium. The bidirectional adjacency list topology model includes: forward association mapping and reverse association mapping. The forward association mapping is used to record the mapping relationship from each component to its downstream components, and the reverse association mapping is used to record the mapping relationship from each component to its upstream components. Traverse the forward association mapping and the reverse association mapping in the bidirectional adjacency list topology model to capture the complete topology structure of the target component, and generate an initial version snapshot based on the complete topology structure; The upgrade request indicates that multiple target underlying nodes to be changed are identified. Based on the initial version snapshot, the multiple target underlying nodes are updated in parallel. The updated target underlying nodes are integrated. Based on the integration result, a target version snapshot of the completed upgrade is generated and the target version snapshot is published.

2. The method according to claim 1, characterized in that, Traversing the forward and reverse association mappings in the bidirectional adjacency list topology model to capture the complete topology of the target component includes: In the forward association mapping of the bidirectional adjacency list topology model, the set of direct downstream components starting from the target component is obtained; By recursively querying the positive association mapping, the set of direct downstream components is expanded layer by layer to obtain all downstream components of the target component, thus obtaining the downstream topology. In the reverse association mapping of the bidirectional adjacency list topology model, obtain the set of direct upstream components starting from the target component; By recursively querying the reverse association mapping, the set of direct upstream components is expanded layer by layer to obtain all upstream components of the target component, thus obtaining the upstream topology. The downstream topology and the upstream topology are integrated to obtain the complete topology, wherein the complete topology includes all associated components and relationships of the target component in the full dependency path.

3. The method according to claim 1 or 2, characterized in that, Based on the complete topology, an initial version snapshot is generated, including: Extract all component nodes from the complete topology to obtain a set of component nodes; In the component relationship database, the first attribute data of each component node in the component node set is read to obtain an attribute data set, wherein the first attribute data includes at least one of the following: component identifier, version identifier, and status identifier; Extract the first copy of the forward association mapping and the second copy of the reverse association mapping from the bidirectional adjacency list topology model; The timestamp information is obtained, and the attribute data set, the first copy, and the second copy are combined and encapsulated with the timestamp information to obtain the initial version snapshot.

4. The method according to claim 1, characterized in that, Transforming the attribute data into a bidirectional adjacency list topology model in the storage medium includes: An initial bidirectional adjacency list topology model is constructed based on the attribute data; The bidirectional adjacency list topology model is traversed using a depth-first search algorithm. During the traversal, the existence of circular dependencies is detected. Circular dependencies are used to indicate that there is a circular reference in the dependency relationship, such that at least one group of nodes forms a closed path through direct or indirect dependencies. If the loop dependency is detected, a first error log is generated, the modeling process is stopped, and a first message indicating the loop dependency error is generated, wherein the first error log includes at least loop path information; After traversal is completed, the in-degree of all nodes in the initial bidirectional adjacency list topology model is scanned. The in-degree is obtained by querying the length of the dependent list of the corresponding node in the reverse association mapping. The length of the dependent list is used to represent the number of nodes that are directly dependent on by other components. If the scan finds a first node with an in-degree of zero that is not the root node, a second error log is generated and the modeling process is stopped. The second error log includes at least the node identifier of the first node. If no loop dependency is detected and the in-degree of all non-root nodes is greater than zero, the initial bidirectional adjacency list topology model is verified, and the bidirectional adjacency list topology model is obtained.

5. The method according to claim 1, characterized in that, Identify multiple target underlying nodes to be modified as indicated by the upgrade request, and perform parallel updates on the multiple target underlying nodes based on the initial version snapshot, including: Starting from the target bottom node, the upper-level nodes that directly depend on the target bottom node are recursively queried through the reverse association mapping of the initial version snapshot until the root node is reached, thus obtaining the complete dependency path from the target bottom node to the root node. Based on the complete dependency path, generate the affected node chain for each target underlying node; The affected node chain is split into multiple independent node update tasks, and these multiple independent node update tasks are distributed to multiple worker nodes through a message queue; Each worker node creates a new version snapshot for the assigned node update task and updates the dependency pointers in the forward association map and the reverse association map, wherein the dependency pointers are used to indicate the versioned dependency relationship between nodes, and the dependency pointers include the forward dependency relationship of the source node to the new version target node, and the reverse association relationship of the new version target node being depended on by the source node.

6. The method according to claim 5, characterized in that, The method further includes: When a worker node executes a node update task, it locks the index update operation through a distributed lock mechanism so that only one worker node can update the index information at any given time. Before executing a node update task, the worker node checks whether the node update task corresponding to the worker node has been processed by querying the execution status of the upgrade transaction identifier stored in the distributed storage. If the check result indicates that the node update task is in an inactive state, execute the node update task, and update the execution status of the upgrade transaction identifier in the distributed storage after the node update task is completed; If the node update task fails, the failed node update task is put back into the message queue for retry processing. If the number of retries exceeds a preset threshold, retries are stopped and the node corresponding to the node update task is marked as isolated.

7. The method according to claim 1, characterized in that, Publishing the target version snapshot includes: Write the target version snapshot to the database, wherein the target version snapshot includes at least one of the following: snapshot identifier, root node identifier, version information, generation timestamp, and snapshot status; After the database write is completed, a version log record is inserted into the version log table. The version log record includes at least one of the following: log identifier, change content, metadata, and previous log identifier. The change content includes a mapping relationship from the old snapshot identifier to the new snapshot identifier. The metadata includes at least one of the following: trigger identifier, timestamp, and number of affected nodes. The previous log identifier is used to associate the current version log record with the historical version log record to form a log chain. The full-stack topology data corresponding to the snapshot identifier is cached in a distributed caching system, and an upgrade completion event is sent to the cloud management platform through a message middleware. The full-stack topology data includes all node attributes and the forward and reverse association mapping relationships between nodes, and the upgrade completion event includes at least the snapshot identifier.

8. The method according to claim 7, characterized in that, After publishing the target version snapshot, the method further includes: Receive a rollback request, wherein the rollback request includes: a target version log identifier; Retrieve the old snapshot identifier corresponding to the target version log identifier from the version log table; Load the old snapshot corresponding to the old snapshot identifier, and reconstruct the bidirectional adjacency list topology model based on the node attribute data and the relationship data between nodes in the old snapshot; Perform a cascading update operation on the reconstructed bidirectional adjacency list topology model, and replace the dependency pointers of the reconstructed bidirectional adjacency list topology model with the dependencies in the old snapshot; The rolled-back system state is persisted as a new snapshot, and a rollback log record is inserted into the version log table. The rollback log record includes a rollback source field, which references the target version log identifier and is used to identify the version log record on which this rollback operation is based.

9. A component upgrade device, characterized in that, include: A receiving module is used to receive an upgrade request, wherein the upgrade request includes at least: component information of the target component to be upgraded; The transformation module is used to obtain the attribute data of the target component from the component relationship database and transform the attribute data into a bidirectional adjacency list topology model in the storage medium. The bidirectional adjacency list topology model includes: forward association mapping and reverse association mapping. The forward association mapping is used to record the mapping relationship from each component to its downstream components, and the reverse association mapping is used to record the mapping relationship from each component to its upstream components. The capture module is used to traverse the forward association mapping and the reverse association mapping in the bidirectional adjacency list topology model to capture the complete topology structure of the target component, and generate an initial version snapshot based on the complete topology structure; The determination module is used to determine the multiple target underlying nodes to be changed as indicated by the upgrade request, perform parallel updates on the multiple target underlying nodes based on the initial version snapshot, integrate the updated target underlying nodes, generate a target version snapshot with the upgrade completed based on the integration result, and publish the target version snapshot.

10. A non-volatile storage medium, characterized in that, The non-volatile storage medium includes a stored program, wherein, when the program is executed, it controls the device containing the non-volatile storage medium to perform the component upgrade method according to any one of claims 1 to 8.

11. An electronic device, characterized in that, include: A memory and a processor, the processor being configured to run a program stored in the memory, wherein the program, when running, performs the component upgrade method according to any one of claims 1 to 8.

12. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the component upgrade method according to any one of claims 1 to 8.

Images