Micro-service updating method and device and medium

Abstract

The invention discloses a micro-service updating method and device and a medium. The method comprises the steps of obtaining topological information among multiple micro-services in an application system; the topological information comprises a service identifier and a dependency relationship; each micro-service comprises a plurality of patch modules; the dependency relationship is related to the patch module updating sequence; according to the topological information, constructing a relation graph formed by a plurality of micro-services and associated edges among a plurality of micro-service nodes; when a patch module updating request is received, if a plurality of patch modules to be updated exist, determining a target micro-service with the patch modules to be updated; when the plurality of target micro-services exist, searching a target dependency relationship among the plurality of target micro-services in the relationship graph; when the first target micro-service depends on the second target micro-service, the dependency level of the first target micro-service is higher than that of the second target micro-service; and determining an updating sequence of each target micro-service according to the target dependency relationship. And the updating efficiency and flexibility are improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a microservice update method, device, and medium. Background Art

[0002] With the in-depth development of enterprise informatization, the importance of application systems (such as ERP systems) as core tools for enterprise management has become increasingly prominent. In order to improve the flexibility and maintainability of application systems, many systems have adopted microservice architecture. Under the microservice architecture, the application system is divided into multiple independent service modules, which communicate with each other through API interfaces. Although this architecture improves the flexibility of the system, it also brings new challenges, especially in the update and deployment of microservices.

[0003] At present, the application system microservice update method usually uses a static dependency graph to guide the service update sequence. Although this method is simple and easy to implement, it has the following problems in actual application: as the number of microservices increases, the dependencies between services become more complex, and the static dependency graph is difficult to accurately reflect the actual dependencies and cannot adapt to the changes in the dependencies between services, resulting in inflexible update strategies. Summary of the invention

[0004] The embodiments of the present application provide a microservice update method, device, and medium, which are used to solve the problem of low efficiency and poor flexibility of microservice update.

[0005] The present application embodiment adopts the following technical solutions:

[0006] On the one hand, an embodiment of the present application provides a microservice update method, the method comprising: obtaining topology information between multiple microservices in an application system; the topology information comprises service identifiers and dependencies; each microservice comprises multiple patch modules; the dependencies are related to a preset patch module update order; based on the topology information, constructing a relationship graph consisting of multiple microservices and associated edges between the multiple microservice nodes; when receiving a patch module update request, if there are multiple patch modules to be updated, determining a target microservice with the patch module to be updated; when there are multiple target microservices, retrieving target dependencies between the multiple target microservices in the relationship graph; when a first target microservice depends on a second target microservice, the dependency level of the first target microservice is higher than the dependency level of the second target microservice; based on the target dependencies, determining the update order of each target microservice.

[0007] In one example, determining the update order of each target microservice according to the target dependency specifically includes: determining a first microservice group to be sorted in which no target dependency exists and a second microservice group to be sorted in which a target dependency exists; in the second microservice group to be sorted, sorting the target microservices in sequence according to the dependency to obtain a sorted microservice group; in the sorted microservice group, the dependency level increases in sequence; determining the position order of the target microservices in the sorted microservice group as the update order of the target microservices; and determining, according to the first microservice group to be sorted, the target microservices in the sorted service group that have a parallel update relationship.

[0008] In one example, determining the target microservices in the sorting service group that have a parallel update relationship based on the first microservice group to be sorted specifically includes: determining a microservice group in the same position order in the sorting microservice group; matching the microservices in the microservice group in the first microservice group to be sorted; if all matches are successful, determining that the target microservices in the microservice group have a parallel update relationship.

[0009] In one example, after determining the update order of each target microservice according to the target dependency, the method further includes: determining other microservices that have dependencies with the target microservice in the relationship graph; determining the target microservice to be updated first in the sorted service group; determining other target microservices with a dependency level higher than the target microservice to be updated first among other microservices; and generating a minimum set of stopped services based on the target microservice and the other target microservices.

[0010] In one example, after generating the minimum set of stopped services based on the target microservice and the target other microservices, the method further includes: stopping the service of the minimum set; updating the corresponding patch modules to be updated in each target microservice in turn according to the update order of each target microservice; and restarting the target microservice and the target other microservices in the minimum set after each target microservice is updated.

[0011] In one example, the obtaining of topology information between multiple microservices in an application system specifically includes: when a microservice of the application system is started, automatically sending first registration topology information to a registration center through the microservice; after obtaining the topology information between multiple microservices in the application system, the method also includes: searching for second registration topology information uploaded by the client to the registration center.

[0012] In one example, constructing a relationship graph consisting of multiple microservices and associated edges between the multiple microservice nodes based on the topology information specifically includes: constructing a graph structure of the relationship graph, each node of the graph structure represents a microservice, and each edge represents a dependency relationship between two microservices; when the update order of the patch module of the first microservice is earlier than the update order of the second microservice, the second microservice depends on the first microservice; initializing the graph structure according to the first registered topology information and the second registered topology information to obtain an initial relationship graph; judging whether there are isolated nodes in the initial relationship graph; the isolated nodes refer to nodes that have no dependency relationship with other nodes; when there are isolated nodes, deleting the isolated nodes to obtain the relationship graph.

[0013] In one example, constructing a relationship graph consisting of multiple microservices and associated edges between the multiple microservice nodes based on the topology information specifically includes: receiving updated topology information of the microservices; judging whether the dependency relationship between the microservices is updated based on the updated topology information; and if so, updating the updated dependency relationship in the relationship graph.

[0014] On the other hand, an embodiment of the present application provides a microservice update device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute a microservice update method described in any one of the above.

[0015] On the other hand, an embodiment of the present application provides a microservice update non-volatile computer storage medium storing computer executable instructions, wherein the computer executable instructions can execute any of the microservice update methods described above.

[0016] At least one of the above technical solutions adopted in the embodiments of the present application can achieve the following beneficial effects:

[0017] Determine the dependencies between multiple microservices, and build a relationship graph of the application system through the topological information between multiple microservices, thereby demonstrating dynamic dependencies. This can adapt to changes in dependencies between services, making the update strategy more flexible. Through the dependencies in the relationship graph, the update order of the microservices to be updated with the patch module is determined, and an update strategy is generated, thereby ensuring the consistency of dependencies during the service update process and reducing the risk of failure. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the technical solution of the present application, some embodiments of the present application will be described in detail below in conjunction with the accompanying drawings, in which:

[0019] Figure 1 A flowchart of a microservice update method provided in an embodiment of the present application;

[0020] Figure 2 A schematic diagram of the structure of a microservice update device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0021] In order to make the purpose, technical solution and advantages of the present application clearer, the technical solution of the present application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in the field without creative work are within the scope of protection of the present application.

[0022] Some embodiments of the present application are described in detail below with reference to the accompanying drawings.

[0023] Figure 1 A schematic diagram of a microservice update method provided in an embodiment of the present application. The method can be applied to different business fields, such as Internet financial business field, e-commerce business field, instant messaging business field, game business field, official business field, etc. Certain input parameters or intermediate results in the process allow manual intervention and adjustment to help improve accuracy.

[0024] The analysis method involved in the embodiments of the present application can be implemented by a terminal device or a server, and the present application does not impose any special restrictions on this. For the convenience of understanding and description, the following embodiments are described in detail by taking a server as an example.

[0025] It should be noted that the server may be a single device or a system consisting of multiple devices, that is, a distributed server, and this application does not make any specific limitation on this.

[0026] Figure 1 The process in includes the following steps:

[0027] S101: Acquire topology information between multiple microservices in an application system; the topology information includes service identifiers and dependencies; each microservice includes multiple patch modules; the dependencies are related to a preset patch module update sequence.

[0028] In some embodiments of the present application, the application system may be an ERP system, and the service identifier refers to an identifier used to uniquely identify a microservice instance. The service identifier may be in various forms, including a service name, an IP address, a port number, and the like.

[0029] It should be noted that the update order between patch modules needs to be defined in advance. For example, patch module a, patch module b, patch module c, patch module d, the update order can be: a, b, c, d, or a is earlier than b and c, and d is later than b and c.

[0030] It should be noted that when the earliest update order of the patch module in one microservice is later than the earliest update order of the patch module in another microservice, the microservice is considered to be dependent on the other microservice.

[0031] For example, when the update order is: a is earlier than b and c, and d is later than b and c, when microservice 1 includes patch module a and microservice 2 includes patch module b, microservice 2 depends on microservice 1. Alternatively, when microservice 1 includes patch modules a and b and microservice 2 includes patch module c, microservice 2 depends on microservice 1. Alternatively, microservice 1 includes patch modules a and b and microservice 2 includes patch modules b and c. At this time, since patch module a has the earliest update order, microservice 2 still depends on microservice 1. Alternatively, when microservice 1 includes patch modules a and b and microservice 2 includes patch module a, since patch module a has the earliest update order and both microservices have it, there is no dependency between microservice 1 and microservice 2. Alternatively, when microservice 1 includes patch module b and microservice 2 includes patch module c, there is no dependency between microservice 1 and microservice 2.

[0032] It should be noted that if microservice 1 includes patch modules a and b, and microservice 2 includes patch modules a and d, it is very likely that there is an error in the division of microservices during architecture.

[0033] It should be noted that microservices is an architectural style that advocates developing a single application as a set of small services, each of which runs in its own process and communicates with each other using lightweight mechanisms. In addition, a patch module refers to a small software package or update file used to repair or improve the functionality of a microservice, usually including code changes or configuration updates. A patch module can include application components (such as JAR packages, web scripts, etc.) and database changes (such as table structures, table data). Within a patch module, the dependencies between components can be in a linear order, that is, the previous component must be updated before the next component can be updated.

[0034] Based on this, the process of obtaining topology information between multiple microservices in the application system is as follows:

[0035] When the microservice of the application system is started, the first registered topology information is automatically sent to the registration center through the microservice. For example, each microservice of the ERP system automatically registers the topology information, including service identification, dependency, etc., to the central registration center when it is started.

[0036] It should be noted that users will also register the topology information of microservices through the client to avoid the situation where the microservice fails to automatically send the first registered topology information to the registration center. However, the second registered topology information is not necessarily the microservice of the current application system.

[0037] Therefore, the second registration topology information uploaded by the client to the registration center will also be searched.

[0038] S102: Constructing a relationship graph consisting of multiple microservices and associated edges between the multiple microservice nodes according to the topology information.

[0039] In some embodiments of the present application, the relationship graph is actually a dynamic dependency graph, which can be used to represent a data structure or a graphical representation of dynamically changing dependencies between microservices, and is used to track and manage interactions between microservices. The construction process is as follows:

[0040] First, a graph structure of the relationship graph is constructed, where each node of the graph structure represents a microservice, and each edge represents the dependency relationship between two microservices.

[0041] It should be noted that when the update order of the patch module of the first microservice is earlier than the update order of the second microservice, the second microservice depends on the first microservice.

[0042] It should be noted that when the first microservice and the second microservice have multiple patch modules, the patch modules with the earliest update order in the two microservices are compared.

[0043] Then, the graph structure is initialized according to the first registered topology information and the second registered topology information to obtain an initial relationship graph.

[0044] Determine whether there are isolated nodes in the initial relationship graph. An isolated node is one that has no dependency relationship with other nodes.

[0045] It should be noted that an isolated node actually refers to a microservice that is not part of the current application system, and therefore has no dependency on the microservices of the current application system.

[0046] Based on this, when there are isolated nodes, the isolated nodes are deleted to obtain a relationship graph, thereby removing irrelevant nodes and edges, simplifying the graph structure, and ensuring the validity of the graph.

[0047] In some embodiments of the present application, a scheduled task may be set to periodically update the relationship graph, or when the dependency between services changes, the update of the relationship graph may be triggered.

[0048] Based on this, when receiving the updated topology information of the microservice, it is determined whether the dependency relationship between the microservices is updated according to the updated topology information. If so, the updated dependency relationship is updated in the relationship graph.

[0049] S103: When receiving a patch module update request, if there are multiple patch modules to be updated, determine a target microservice having the patch module to be updated.

[0050] Among them, since each microservice may have multiple patch modules, for example, microservice 1 includes patch modules a and b, and microservice 2 includes patch modules b and c. Therefore, it is necessary to retrieve the target microservice with the patch modules to be updated. For example, the patch modules to be updated include patch module b and patch module e.

[0051] S104: When there are multiple target microservices, in the relationship graph, retrieve the target dependency relationship between the multiple target microservices; when a first target microservice depends on a second target microservice, the dependency level of the first target microservice is higher than the dependency level of the second target microservice.

[0052] It should be noted that when there is one target microservice, the target microservice can be directly updated.

[0053] S105: Determine an update order for each target microservice according to the target dependency relationship.

[0054] In some embodiments of the present application, when there are multiple target microservices, it is necessary to ensure the consistency of dependencies. It should be noted that there may be target microservices that do not have dependencies. For example, target microservice 1 has dependencies with target microservice 2 and target microservice 3 respectively, and target microservice 2 and target microservice 3 both have dependencies with target microservice 4. At this time, target microservice 2 and target microservice 3 do not have dependencies. At this time, target microservice 2 and target microservice 3 need to be updated in parallel to improve update efficiency and reduce the number of unnecessary service restarts.

[0055] Based on this, a first microservice group to be sorted without target dependency and a second microservice group to be sorted with target dependency are determined.

[0056] Then, in the second microservice group to be sorted, the target microservices are sorted in sequence according to the dependency relationship to obtain a sorted microservice group, wherein the dependency level increases in sequence in the sorted microservice group.

[0057] Then, the position order of the target microservices in the sorted microservice group is determined as the update order of the target microservices.

[0058] For example, the sorted microservice group includes target microservice 1, target microservice 2, target microservice 3, and target microservice 4, and the update order of the target microservices is 1, 2, 3, 4. The dependency levels from high to low are 1, 2, 3, 4. At this time, the update order for target microservices 2 and 3 is unknown.

[0059] Finally, according to the first microservice group to be sorted, the target microservices in the sorting service group that have a parallel update relationship are determined.

[0060] For example, if in the first microservice group to be sorted, it is confirmed that target microservices 2 and 3 have no dependency relationship, then target microservices 2 and 3 are determined to be updated in parallel.

[0061] Based on this, in the sorted microservice groups, microservice groups in the same position order are determined. In the first microservice group to be sorted, the microservices in the microservice group are matched. If all are matched successfully, the target microservices in the microservice group are determined to have a parallel update relationship.

[0062] It should be noted that after determining the update order of each target microservice, the patch module is updated at the microservice granularity, that is, after all the patch modules to be updated in one microservice are updated, the next microservice is updated.

[0063] In some embodiments of the present application, before updating the target microservice, the target microservice needs to be stopped, and microservices related to the target microservice also need to be stopped.

[0064] Based on this, in the relationship graph, determine other microservices that have dependencies with the target microservice. Then, in the sorted service group, determine the target microservice to be updated first. Then, among the other microservices, determine the target other microservices with a dependency level higher than the first updated target microservice. Finally, based on the target microservice and the target other microservices, generate the minimum set of stopped services. This can avoid unnecessary service restarts and improve update efficiency.

[0065] That is to say, the latest updated microservice among other target microservices depends on the first updated target microservice. That is, when the target microservice stops service, it will affect the operation of other target microservices, so it also needs to stop service.

[0066] Furthermore, the minimum set is stopped. According to the update order of each target microservice, the corresponding patch modules to be updated in each target microservice are updated in turn. After each target microservice is updated, the target microservice in the minimum set and other target microservices are restarted.

[0067] It should be noted that the updated patch module needs to verify integrity to ensure that the patch module can be applied normally. After the verification is passed, the updated patch module is used to update the patch module to be updated in the microservice. In addition, the patch module of the microservice is stored in the database.

[0068] To sum up, the construction of a dynamic dependency graph: collect the call relationships between microservices in real time at runtime and build a dynamic dependency graph.

[0069] Optimal update order calculation: Based on the dynamic dependency graph, calculate the optimal update order of microservices.

[0070] It should be noted that although the embodiments of the present application are based on Figure 1 Steps S101 to S105 are described in sequence, but this does not mean that steps S101 to S105 must be performed in a strict order. Figure 1 The order shown in the figure is to introduce and explain step S101 to step S105 in sequence, in order to facilitate those skilled in the art to understand the technical solution of the embodiment of the present application. In other words, in the embodiment of the present application, the order between step S101 to step S105 can be appropriately adjusted according to actual needs.

[0071] pass Figure 1 The method is used to determine the dependencies between multiple microservices, and the relationship graph of the application system is constructed through the topological information between multiple microservices, thereby showing dynamic dependencies. It can adapt to changes in the dependencies between services and make the update strategy more flexible. Through the dependencies in the relationship graph, the update order of the microservices to be updated with the patch module is determined, and the update strategy is generated, thereby ensuring the consistency of dependencies during the service update process and reducing the risk of failure.

[0072] Based on the same idea, some embodiments of the present application also provide devices and non-volatile computer storage media corresponding to the above methods.

[0073] Figure 2 A schematic diagram of the structure of a microservice update device provided in an embodiment of the present application includes:

[0074] at least one processor; and,

[0075] a memory communicatively connected to the at least one processor; wherein,

[0076] The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute any one of the microservice update methods described above.

[0077] Some embodiments of the present application provide a microservice update non-volatile computer storage medium storing computer executable instructions, wherein the computer executable instructions can execute any one of the microservice update methods described above.

[0078] Each embodiment in this application is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device and medium embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiments.

[0079] The devices and media provided in the embodiments of the present application correspond one-to-one to the methods. Therefore, the devices and media also have similar beneficial technical effects as the corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the devices and media will not be repeated here.

[0080] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, systems, or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0081] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0082] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1A function specified in one or more boxes.

[0083] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0084] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0085] The memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0086] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0087] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0088] The above is only an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the technical principle of the present application should all fall within the protection scope of the present application.

Claims

1. A microservice update method, characterized in that: The method comprises: Acquire topology information between multiple microservices in the application system; the topology information includes service identifiers and dependencies; each microservice includes multiple patch modules; the dependencies are related to a preset patch module update sequence; According to the topology information, a relationship graph consisting of multiple microservices and associated edges between the multiple microservice nodes is constructed; When receiving a patch module update request, if there are multiple patch modules to be updated, determine a target microservice having the patch module to be updated; When there are multiple target microservices, in the relationship graph, the target dependency relationship between the multiple target microservices is retrieved; when a first target microservice depends on a second target microservice, the dependency level of the first target microservice is higher than the dependency level of the second target microservice; According to the target dependencies, an update order of each target microservice is determined.

2. The method according to claim 1, characterized in that: Determining the update order of each target microservice according to the target dependency specifically includes: Determine a first microservice group to be sorted that does not have a target dependency relationship and a second microservice group to be sorted that has a target dependency relationship; In the second microservice group to be sorted, the target microservices are sorted in sequence according to the dependency relationship to obtain a sorted microservice group; in the sorted microservice group, the dependency level increases in sequence; The position order of the target microservices in the sorted microservice group is determined as the update order of the target microservices; According to the first microservice group to be sorted, a target microservice in the sorting service group having a parallel update relationship is determined.

3. The method according to claim 2, characterized in that The determining, according to the first microservice group to be sorted, a target microservice in the sorting service group that has a parallel update relationship specifically includes: In the sorted microservice groups, determining microservice groups in the same position order; In the first microservice group to be sorted, matching the microservices in the microservice group; If all matches are successful, the target microservices in the microservice group are determined to have a parallel update relationship.

4. The method according to claim 2, characterized in that: After determining the update order of each target microservice according to the target dependency, the method further includes: In the relationship graph, determine other microservices that have dependencies with the target microservice; In the sorting service group, determine the target microservice to be updated first; Among other microservices, identify the target other microservices with a dependency level higher than the first updated target microservice; A minimum set of stopped services is generated according to the target microservice and the other target microservices.

5. The method according to claim 4, characterized in that After generating the minimum set of stopped services according to the target microservice and the other target microservices, the method further includes: Stopping service for the minimum set; According to the update order of each target microservice, update the corresponding patch modules to be updated in each target microservice in turn; After each target microservice is updated, the target microservice and other target microservices in the minimum set are restarted.

6. The method according to claim 1, characterized in that The obtaining of topology information between multiple microservices in the application system specifically includes: When the microservice of the application system is started, the first registration topology information is automatically sent to the registration center through the microservice; After obtaining the topology information between the multiple microservices in the application system, the method further includes: Find the second registration topology information uploaded by the client to the registration center.

7. The method according to claim 6, characterized in that The step of constructing a relationship graph consisting of the multiple microservices and the associated edges between the multiple microservice nodes according to the topology information specifically includes: Constructing a graph structure of a relationship graph, wherein each node of the graph structure represents a microservice, and each edge represents a dependency relationship between two microservices; when the update order of the patch module of the first microservice is earlier than the update order of the second microservice, the second microservice depends on the first microservice; Initializing the graph structure according to the first registered topology information and the second registered topology information to obtain an initial relationship graph; Determine whether there is an isolated node in the initial relationship graph; the isolated node refers to a node that has no dependency relationship with other nodes; When there are isolated nodes, the isolated nodes are deleted to obtain the relationship graph.

8. The method according to claim 1, characterized in that The step of constructing a relationship graph consisting of multiple microservices and associated edges between the multiple microservice nodes according to the topology information specifically includes: Receiving updated topology information of the microservice; According to the updated topology information, determine whether the dependency relationship between microservices is updated; If so, the updated dependency is updated in the relationship graph.

9. A microservice update device, characterized in that: include: at least one processor; as well as, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute a microservice update method as described in any one of claims 1 to 8 above.

10. A microservice updating non-volatile computer storage medium storing computer executable instructions, characterized in that: The computer executable instructions can execute a microservice updating method as described in any one of claims 1 to 8 above.

Images