Method and apparatus for cooperative upgrading of multi-component system, storage medium and terminal

Abstract

The application provides a multi-component system cooperative upgrading method and device, a storage medium and a terminal, wherein the method comprises the following steps: constructing a directed acyclic graph based on component information of each component in a target system, and obtaining a target upgrading sequence by performing a topological sorting algorithm on the components in the directed acyclic graph; obtaining an atomic upgrading package based on the target upgrading sequence, wherein the atomic upgrading package comprises upgrading packages of all the components in the target upgrading sequence; and upgrading each component in the target system by using a distributed transactional upgrading mode based on the atomic upgrading package. The application provides a complete, high-reliability and automated solution for solving the general problem of software supply chain cooperative upgrading, realizes one-key cooperative upgrading, and guarantees the atomicity and rollback of the upgrading process.

Description

Technical Field

[0001] This invention relates to the field of cloud computing system operation and maintenance and software deployment technology, and in particular to a method and apparatus for collaborative upgrading of multi-component systems, storage medium and terminal. Background Technology

[0002] Modern cloud communication platforms typically consist of multiple independent service components, such as the cloud management platform, session border controller (SBC), SBC proxy, PBX hub, and specific PBX devices. These components have complex version dependencies; for example, a new version of the proxy may require a new version of the SBC to function correctly, and a new version of the cloud platform API may be incompatible with an older version of the PBX hub.

[0003] Currently, performing the above-mentioned types of system upgrades faces significant challenges. First, dependency management is complex: operations and maintenance personnel must manually consult documentation, memorize and understand dozens or even hundreds of version compatibility combinations, making the operation cumbersome and prone to errors; an incorrect upgrade sequence can lead to service call failures between components, or even paralyze the entire system. Second, the upgrade process is unreliable: traditional serial upgrade scripts lack fault tolerance mechanisms; if the Nth component in the upgrade sequence fails, the system will remain in a "semi-upgraded" inconsistent state, with some components being newer versions and others older versions. At this point, system behavior is undefined, and rollback is extremely difficult, often requiring manual intervention, leading to prolonged service interruption. Finally, upgrade material management is loose: upgrade packages are usually stored in a scattered manner, requiring separate downloads during upgrades; when the network is unstable or the repository is temporarily unavailable, it may lead to version mismatches in upgrade packages or missing files, resulting in unpredictable consequences.

[0004] Therefore, there is an urgent need in this field for an intelligent collaborative upgrade solution that can automatically calculate the upgrade path, ensure the atomicity of the upgrade operation (i.e., all succeed or all fail), and automatically handle failure rollback. Summary of the Invention

[0005] In view of the shortcomings of the prior art described above, the purpose of this application is to provide a method, apparatus, storage medium and terminal for collaborative upgrading of multi-component systems, in order to solve the problems of complex dependency management of existing multi-component systems that are prone to errors, unreliable upgrade process leading to upgrade lag, and loose upgrade material management and difficulty in obtaining complete upgrade files.

[0006] Firstly, this application provides a method for collaborative upgrading of a multi-component system, including: A directed acyclic graph is constructed based on the component information of each component in the target system. The components in the directed acyclic graph are sorted using a topological sorting algorithm to obtain the target upgrade sequence. Based on the target upgrade sequence, an atomic upgrade package is obtained, wherein the atomic upgrade package includes upgrade packages for all components in the target upgrade sequence; Based on the atomic upgrade package, the components in the target system are upgraded using a distributed transactional upgrade method.

[0007] In one embodiment of this application, the vertices in the directed acyclic graph represent upgrade operations of a single component, and the edges in the directed acyclic graph represent upgrade operation dependencies between two components.

[0008] In one embodiment of this application, the upgrade packages for all the components are digitally signed compressed packages.

[0009] In one embodiment of this application, upgrading components in the target system using a distributed transactional upgrade method includes: Upgrade each component sequentially according to the target upgrade sequence. If all components in the target upgrade sequence are successfully upgraded, an upgrade success operation is performed. If a component in the target upgrade sequence fails to upgrade, a compensation operation is performed on the current upgrade component and all components before the current upgrade component in the target upgrade sequence.

[0010] In one embodiment of this application, upgrading the component includes performing an upgrade operation on the component, and performing a health check on the component after the upgrade operation is completed. If the check is successful, the component upgrade is successful; if the check fails, the component upgrade fails.

[0011] In one embodiment of this application, the health check includes at least one of the following: whether the component process is active, whether the critical API port is responding, whether the current version number is the target upgrade version number, and whether there are upgrade-related fatal errors in the error log.

[0012] In one embodiment of this application, the compensation operation is to roll back the component to its pre-upgrade state based on the component's compensation operation log, wherein the compensation operation log includes the complete execution command for rolling back the component to the original version.

[0013] In one embodiment of this application, the component upgrade failure includes the component failing to perform the upgrade operation or the component failing the health check after the upgrade.

[0014] Secondly, this application provides a multi-component system collaborative upgrade device, including a target upgrade sequence acquisition module, an upgrade package acquisition module, and an upgrade module; The target upgrade sequence acquisition module is used to construct a directed acyclic graph based on the component information of each component in the target system, and to sort the components in the directed acyclic graph using a topological sorting algorithm to obtain the target upgrade sequence. The upgrade package acquisition module is used to acquire atomic upgrade packages based on the target upgrade sequence, wherein the atomic upgrade package includes upgrade packages for all components in the target upgrade sequence; The upgrade module is used to upgrade each component in the target system based on the atomic upgrade package using a distributed transactional upgrade method.

[0015] Thirdly, this application provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the aforementioned multi-component system collaborative upgrade method.

[0016] Fourthly, this application provides a terminal including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the multi-component system collaborative upgrade method described above.

[0017] Compared with the prior art, one or more embodiments of the above solutions may have the following advantages or beneficial effects: The multi-component system collaborative upgrade method provided in this invention constructs a directed acyclic graph (DAG) and obtains the target upgrade sequence from the DAG using a topological sorting algorithm, thereby automating and intelligently obtaining the optimal upgrade path for the multi-component system upgrade process. It introduces the concept of distributed transactional upgrades into the software upgrade process, ensuring eventual consistency of the system during the upgrade process through the setting of compensation operation logs and compensation operations. This significantly improves the success rate and security of complex system upgrades, achieving the atomic goal of either all upgrades or none at all. Digital signatures address the potential inconsistencies, incompleteness, or tampering of upgrade files in a distributed environment, laying a solid material foundation for reliable upgrades. These settings provide a complete and highly reliable automated solution for solving the common problem of collaborative upgrades in the software supply chain, enabling one-click collaborative upgrades and ensuring the atomicity and rollbackability of the upgrade process. Attached Figure Description

[0018] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with the embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1 The diagram shown is a flowchart illustrating the multi-component system collaborative upgrade method described in an embodiment of this application.

[0019] Figure 2 The diagram shown is a structural schematic of the multi-component system collaborative upgrade device described in this application embodiment.

[0020] Figure 3 The diagram shown is a structural schematic of the terminal described in an embodiment of this application. Detailed Implementation

[0021] The embodiments of the present invention will be described in detail below with reference to the accompanying drawings and examples, so that the process of how the present invention uses technical means to solve technical problems and achieve technical effects can be fully understood and implemented accordingly. It should be noted that, as long as there is no conflict, the various embodiments and features in the various embodiments of the present invention can be combined with each other, and the resulting technical solutions are all within the protection scope of the present invention.

[0022] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. Therefore, the drawings only show the components related to this application and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0023] The following embodiments of this application provide a method and apparatus for collaborative upgrading of multi-component systems, a storage medium and a terminal, which solve the problems of complex dependency management of existing multi-component systems, which are prone to errors, unreliable upgrade process leading to upgrade lag, and loose upgrade material management and difficulty in obtaining complete upgrade files.

[0024] The following will describe in detail, with reference to the accompanying drawings, the principles and implementation methods of a multi-component system collaborative upgrade method and apparatus, storage medium and terminal of this embodiment, so that those skilled in the art can understand the multi-component system collaborative upgrade method and apparatus, storage medium and terminal of this embodiment without creative effort.

[0025] This application's multi-component system collaborative upgrade method can be applied to the upgrade process of a distributed system composed of multiple microservices or components with version dependencies. For example, a cloud communication platform typically consists of multiple independent service components, such as a cloud management platform, session boundary controller (SBC), SBC proxy, PBX hub, and specific PBX devices. This application's multi-component system collaborative upgrade method can also be applied to other distributed systems, without imposing any fixed limitations.

[0026] like Figure 1 As shown in the figure, this embodiment provides a method for collaborative upgrading of a multi-component system, including the following steps.

[0027] Step S1: Construct a directed acyclic graph based on the component information of each component in the target system, and sort the components in the directed acyclic graph using a topological sorting algorithm to obtain the target upgrade sequence.

[0028] The component information includes the component's unique identifier and the target version number to which the component is planned to be upgraded. It also includes hard dependencies between upgrade operations, such as the fact that upgrade operation v_i must be completed successfully before operation v_j can begin.

[0029] Step S2: Obtain the atomic upgrade package based on the target upgrade sequence.

[0030] The atomic upgrade package includes upgrade packages for all components in the target upgrade sequence, ensuring that all documents required for the upgrade are treated as an indivisible whole, guaranteeing the consistency, integrity, and authenticity of the materials.

[0031] Step S3: Based on the atomic upgrade package, upgrade each component in the target system using a distributed transactional upgrade method.

[0032] The upgrade of each component is defined as a transactional step, which includes a forward operation and a compensation operation. The forward operation is used to execute the actual upgrade script of the component. The compensation operation is to roll back the component to the state before the upgrade when the upgrade fails, so as to ensure eventual consistency in the upgrade process and achieve the atomic goal of "either all upgrade or none upgrade".

[0033] The multi-component system collaborative upgrade method provided by the embodiments of the present invention offers a complete and highly reliable automated solution for solving the common problem of collaborative upgrades in the software supply chain, enabling one-click collaborative upgrades and ensuring the atomicity and rollback of the upgrade process.

[0034] The steps S101 to S102 of the multi-component system collaborative upgrade method in this embodiment will be described in detail below.

[0035] Step S1: Construct a directed acyclic graph based on the component information of each component in the target system, and sort the components in the directed acyclic graph using a topological sorting algorithm to obtain the target upgrade sequence.

[0036] The target system is defined as a multi-component system to be upgraded, comprising multiple components with specific version dependencies. A directed acyclic graph (DAG) is constructed based on the component information, including the component's unique identifier, the target version number to which the component is planned to be upgraded, and hard dependencies between upgrade operations. For example, upgrade operation v_i must be successfully completed before upgrade operation v_j can begin.

[0037] The constructed directed acyclic graph (DAG) consists of a vertex set and an edge set. Each vertex in the vertex set represents an upgrade operation for a single component. Vertices in the DAG can be identified using tuples. For example, the tuple (ComponentID, TargetVersion) represents the unique identifier of a component in the target system, and TargetVersion represents the target version number to which the component is planned to be upgraded, following semantic versioning rules. For instance, when the target system is a cloud communication platform, ComponentID could be "SBC", "Proxy", or "Platform", and TargetVersion could be "2.1.5". Therefore, a vertex in the DAG can be represented as ("SBC", "2.1.0"), which signifies the operation of "upgrading the SBC component to version 2.1.0".

[0038] Each edge in the edge set represents a hard dependency relationship, that is, the dependency relationship between two components in the directed acyclic graph (DAG). Specifically, operation B can only begin after operation A is completed. For example, when the target system is a cloud communication platform, the edge in the DAG pointing from ("Proxy", "1.5.0") to ("SBC", "2.1.0") means that ("Proxy", "1.5.0") depends on ("SBC", "2.1.0"). Furthermore, it also means that when constructing the DAG, an edge pointing from ("Proxy", "1.5.0") to ("SBC", "2.1.0") will be created for ("Proxy", "1.5.0") based on the current system state and the edge creation rules. In a directed acyclic graph (DAG), the two edges pointing from ("PBXHub", "3.0.0") to ("Platform", "5.2.0") and ("SBC", "2.0.0") indicate that ("PBXHub", "3.0.0") depends on ("Platform", "5.2.0") and ("SBC", "2.0.0"). Furthermore, this also means that when constructing the DAG, based on the current system state and edge creation rules, two edges pointing to ("Platform", "5.2.0") and ("SBC", "2.0.0") are created for ("PBXHub", "3.0.0") respectively. In a DAG, each edge defines the minimum version of the dependent components required by the corresponding component.

[0039] Furthermore, the dependencies of each component in the target system can be predefined and versioned into a "dependency rule base". Then, when constructing a directed acyclic graph, the system can directly build edge sets based on the "dependency rule base". The specific dependency rule base can be a YAML / JSON file.

[0040] Then, the components in the directed acyclic graph are sorted using a topological sorting algorithm to obtain the target upgrade sequence. The topological sorting algorithm can be Kahn's algorithm, or other reasonable algorithms; no fixed restrictions are imposed here.

[0041] The specific sorting objective is to obtain a linear sequence S = [v_σ(1), v_σ(2), ..., v_σ(n)] from a given DAG(V,E) such that all edges (v_i, v_j) ∈ E, where v_i always precedes v_j in S. Specifically, the parameter in_degree[v] of vertex v needs to be introduced. This parameter is an integer representing the number of edges pointing to vertex v, i.e., the number of prerequisite upgrade operations that must be executed before vertex v. Initially, in_degree[v] equals the number of edges directly pointing to v, where vertex v is any vertex in the directed acyclic graph. A first-in, first-out (FIFO) queue Q can also be set up to store all vertices with a current in-degree of 0.

[0042] Then, traverse all vertices in the directed acyclic graph (DAG), calculate the in-degree of each vertex (in_degree[v]), and add all vertices with in-degree (in_degree[v]) = 0 to queue Q. Initialize an empty list S to store the result sequence. Then, simulate the removal of an edge, simultaneously decrementing the in-degree of the corresponding vertex v by 1. Then check if the in-degree of vertex v becomes 0; if so, add it to list S, and repeat the simulation of removing an edge until all vertices are in list S. Finally, check if the length of list S is equal to the total number of vertices |V|. If so, the sorting is successful, and list S is the unique valid upgrade sequence, i.e., the target upgrade sequence. If the length of S is less than |V|, it indicates that a cycle exists in the DAG, which is an illegal and contradictory dependency relationship. The system will report an error and terminate the upgrade process.

[0043] Step S2: Obtain the atomic upgrade package based on the target upgrade sequence.

[0044] To avoid upgrade package mismatch or missing issues caused by scattered storage of upgrade packages, this embodiment constructs the upgrade packages of all components in the target upgrade sequence into atomic upgrade packages, that is, ensures that all files required for the upgrade are an indivisible whole, guaranteeing the consistency, integrity and authenticity of the materials.

[0045] Specifically, based on the target upgrade sequence output by topological sorting, all corresponding upgrade packages can be directly collected from the upgrade file repository. To ensure the integrity of the upgrade packages and address potential inconsistencies, incompleteness, or tampering in a distributed environment, each upgrade package in this embodiment is typically a digitally signed compressed file. Furthermore, the cryptographic hash value of each upgrade package needs to be calculated, and all upgrade packages and their corresponding hash values ​​are recorded in a file list. This file list can be a structured file, and the recorded hash values ​​can be represented as {(P_σ(1),Hash_σ(1)),(P_σ(2),Hash_σ(2)),...,(P_σ(n),Hash_σ(n))}, where P_σ(n) represents the upgrade package of the nth vertex in the target upgrade sequence, and Hash_σ(n) represents the hash value corresponding to upgrade package P_σ(n).

[0046] Then, all upgrade packages and file manifests are packaged together to generate `Atomic_Upgrade_Package.bundle`. The bundle file is then digitally signed using a preset private key to generate a signature file, `Signature`. The final atomic upgrade package contains `(Atomic_Upgrade_Package.bundle, Signature)`. Before the component executes the upgrade operation, the executor verifies the `Signature` using the public key and recalculates the hash values ​​of the files within the package, comparing them with the file manifest to ensure that the upgrade package has not been tampered with or corrupted during transmission.

[0047] Step S3: Based on the atomic upgrade package, upgrade each component in the target system using a distributed transactional upgrade method.

[0048] The executor upgrades each component sequentially according to the target upgrade sequence. If all components in the target upgrade sequence are upgraded successfully, an upgrade success operation is executed. If the upgrade of a component in the target upgrade sequence fails, a compensation operation is performed on the currently upgraded component and all components preceding it in the target upgrade sequence. Specifically, for each successfully executed upgrade operation of a component, the coordinator must persistently record the complete execution command of the rollback operation corresponding to that component in the compensation operation log. This record is an immutable Write-Ahead Log (WAL).

[0049] Furthermore, after each component upgrade operation is executed, a health check is performed on the component. This involves executing a predefined health check script, which returns the check results upon completion. A successful check indicates a successful component upgrade, while a failed check indicates a failed upgrade. Specific health check items include whether the component process is active, whether key API ports are responding, whether the current version number obtained via interfaces such as GET / version matches the target upgrade version number, and whether the error log contains at least one of the following upgrade-related fatal errors:

[0050] To enable automatic rollback to the original version after a component upgrade failure, this embodiment defines the upgrade process of each component as a transactional step, meaning each component's upgrade process includes a forward operation and a compensation operation. Specifically, the forward operation executes the component's actual upgrade script; the compensation operation is used to roll back the component to its pre-upgrade state when the upgrade fails. The instruction to roll back the component to its pre-upgrade state needs to be pre-set during system planning; for example, it can be directly set to execute the old version's installation script.

[0051] If all components in the target system are upgraded sequentially according to the target upgrade sequence, and all health checks are successful, then the upgrade is considered successful. For example, deleting the compensation log and updating the system's global version tag can be considered successful upgrade operations. However, if a component upgrade operation fails, or if the health check after the component upgrade fails, the abort process is immediately initiated. The coordinator reads the corresponding compensation operation log and, in a last-in-first-out (LIFO) order, performs compensation operations on the currently upgraded component (the failed upgrade component) and all components preceding it in the target upgrade sequence. This rolls all components back to their original versions. After the rollback, a health check is performed on the components to ensure they are back to a working old version. After the rollback is complete, the upgrade failure is reported to the user, and complete forward and reverse operation logs are retained for analysis.

[0052] The process of upgrading each component in the target system in this embodiment is a distributed Saga transaction.

[0053] This embodiment of the multi-component system collaborative upgrade method constructs a directed acyclic graph (DAG) and obtains the target upgrade sequence from the DAG using a topological sorting algorithm, thereby automating and intelligently acquiring the optimal upgrade path for the multi-component system upgrade process. It introduces the concept of distributed transactional upgrades into the software upgrade process, ensuring eventual consistency of the system during the upgrade process through the setting and operation of compensation logs, greatly improving the success rate and security of complex system upgrades, and achieving the atomic goal of either all upgrades or none at all. Digital signatures address the potential inconsistencies, incompleteness, or tampering of upgrade files in a distributed environment, laying a solid material foundation for reliable upgrades. These settings provide a complete and highly reliable automated solution for solving the common problem of collaborative upgrades in the software supply chain, enabling one-click collaborative upgrades and ensuring the atomicity and rollbackability of the upgrade process.

[0054] like Figure 2 As shown, this embodiment also provides a multi-component system collaborative upgrade device, including a target upgrade sequence acquisition module, an upgrade package acquisition module, and an upgrade module.

[0055] The target upgrade sequence acquisition module is used to construct a directed acyclic graph based on the component information of each component in the target system, and to obtain the target upgrade sequence by sorting the components in the directed acyclic graph using a topological sorting algorithm.

[0056] The upgrade package acquisition module is used to obtain atomic upgrade packages based on the target upgrade sequence. The atomic upgrade package includes upgrade packages for all components in the target upgrade sequence.

[0057] The upgrade module is used to upgrade various components in the target system based on atomic upgrade packages and through distributed transactional upgrade methods.

[0058] The multi-component system collaborative upgrade device in this embodiment can realize fully automatic and highly reliable batch upgrades of the system. It utilizes graph theory models, topology sorting algorithms, and distributed transaction management mechanisms to achieve one-click collaborative upgrades and ensure the atomicity and rollback of the upgrade process.

[0059] This application also provides a computer-readable storage medium. Those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing a processor. The program can be stored in a computer-readable storage medium, which is a non-transitory medium, such as random access memory, read-only memory, flash memory, hard disk, solid-state drive, magnetic tape, floppy disk, optical disk, and any combination thereof. The storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. This available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital video disc (DVD)), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0060] like Figure 3 As shown, this application provides a terminal.

[0061] The terminal in this embodiment includes a processor and a memory connected to each other; the memory is used to store computer programs, and the processor is used to execute the computer programs stored in the memory, so that the terminal can implement all or part of the steps in the method of the above embodiment when it is executed.

[0062] The beneficial effects of all or part of the steps of the above embodiments are the same as the beneficial effects obtained by the terminal provided by the embodiments of the present invention, and will not be described again here.

[0063] It should be noted that the memory may include random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage device. Similarly, the processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0064] While the embodiments disclosed in this invention are as described above, the content is merely for the purpose of facilitating understanding of the invention and is not intended to limit the invention. Any person skilled in the art to which this invention pertains may make any modifications and changes in form and detail of the implementation without departing from the spirit and scope disclosed herein; however, the scope of protection of this invention shall still be determined by the scope defined in the appended claims.

Claims

1. A method for collaborative upgrade of a multi-component system, comprising: A directed acyclic graph is constructed based on the component information of each component in the target system. The components in the directed acyclic graph are sorted using a topological sorting algorithm to obtain the target upgrade sequence. Based on the target upgrade sequence, an atomic upgrade package is obtained, wherein the atomic upgrade package includes upgrade packages for all components in the target upgrade sequence; Based on the atomic upgrade package, the components in the target system are upgraded using a distributed transactional upgrade method.

2. The multi-component system collaborative upgrade method according to claim 1, characterized in that, In the directed acyclic graph, vertices represent upgrade operations of a single component, and edges represent upgrade operation dependencies between two components.

3. The multi-component system collaborative upgrade method according to claim 1, characterized in that, All upgrade packages for the aforementioned components are digitally signed compressed files.

4. The multi-component system collaborative upgrade method according to claim 1, characterized in that, Upgrading the components of the target system using a distributed transactional upgrade method includes: Upgrade each component sequentially according to the target upgrade sequence. If all components in the target upgrade sequence are successfully upgraded, an upgrade success operation is performed. If a component in the target upgrade sequence fails to upgrade, a compensation operation is performed on the current upgrade component and all components before the current upgrade component in the target upgrade sequence.

5. The multi-component system collaborative upgrade method according to claim 4, characterized in that, Upgrading the component includes performing an upgrade operation on the component, and performing a health check on the component after the upgrade operation is completed. If the check is successful, the component upgrade is successful; if the check fails, the component upgrade fails. The health check includes at least one of the following: whether the component process is active, whether the critical API port is responding, whether the current version number is the target upgrade version number, and whether there are upgrade-related fatal errors in the error log.

6. The multi-component system collaborative upgrade method according to claim 4, characterized in that, The compensation operation involves rolling the component back to its pre-upgrade state based on the component's compensation operation log, which includes the complete execution commands for rolling the component back to its original version.

7. The multi-component system collaborative upgrade method according to claim 4, characterized in that, The component upgrade failure includes the component failing to perform the upgrade operation or the component failing the health check after the upgrade.

8. A multi-component system collaborative upgrade device, characterized in that, This includes a target upgrade sequence acquisition module, an upgrade package acquisition module, and an upgrade module; The target upgrade sequence acquisition module is used to construct a directed acyclic graph based on the component information of each component in the target system, and to sort the components in the directed acyclic graph using a topological sorting algorithm to obtain the target upgrade sequence. The upgrade package acquisition module is used to acquire atomic upgrade packages based on the target upgrade sequence, wherein the atomic upgrade package includes upgrade packages for all components in the target upgrade sequence; The upgrade module is used to upgrade each component in the target system based on the atomic upgrade package using a distributed transactional upgrade method.

9. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the multi-component system collaborative upgrade method according to any one of claims 1 to 7.

10. A terminal, comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the multi-component system collaborative upgrade method according to any one of claims 1 to 7.

Images