Methods, apparatus, electronic devices, and storage media for determining dependencies

Abstract

This disclosure provides a method, apparatus, electronic device, and storage medium for determining dependencies. The method includes: obtaining a source code file containing microservice code of a target microservice; and determining a dependency relationship between the target microservice and a called microservice based on the source code file, wherein the called microservice includes microservices called by the target microservice. By employing the above technical solution, this disclosure improves the accuracy, comprehensiveness, and speed of dependency determination.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more particularly to a method, apparatus, electronic device, and storage medium for determining dependencies. Background Technology

[0002] In a microservices system, each basic functionality is broken down into individual microservices, and the entire microservices system consists of many microservices. Because multiple microservices are involved, it is necessary to determine the strong and weak dependencies between them in order to control the microservices system in different business scenarios.

[0003] In existing technologies, the strong and weak dependencies between microservices in a microservice system are generally determined through manual annotation or runtime result tracking. However, neither manual annotation nor runtime result tracking can simultaneously ensure the speed of determining the dependencies between microservices in a microservice system and the comprehensiveness of the determination results. Summary of the Invention

[0004] This disclosure provides a method, apparatus, electronic device, and storage medium for determining dependencies, so as to quickly and comprehensively determine the dependencies between microservices in a microservice system.

[0005] In a first aspect, embodiments of this disclosure provide a method for determining dependencies, including:

[0006] Obtain the source code file, which contains the microservice code of the target microservice;

[0007] The dependency relationship between the target microservice and the called microservice is determined based on the source code file, wherein the called microservice includes the microservice called by the target microservice.

[0008] Secondly, embodiments of this disclosure also provide a dependency determination apparatus, comprising:

[0009] The file acquisition module is used to acquire source code files, which contain the microservice code of the target microservice.

[0010] The relationship determination module is used to determine the dependency relationship between the target microservice and the called microservice based on the source code file, wherein the called microservice includes the microservice called by the target microservice.

[0011] Thirdly, embodiments of this disclosure also provide an electronic device, including:

[0012] One or more processors;

[0013] Memory, used to store one or more programs.

[0014] When the one or more programs are executed by the one or more processors, the one or more processors implement the dependency determination method as described in the embodiments of this disclosure.

[0015] Fourthly, embodiments of this disclosure also provide a computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the dependency determination method as described in embodiments of this disclosure.

[0016] The methods, apparatus, electronic devices, and storage media for determining dependencies provided in this disclosure acquire source code files containing the code of a target microservice and determine the dependencies between the target microservice and the called microservices based on these source code files. By employing the above technical solution, this disclosure determines the dependencies between a target microservice and its called microservices based on the source code. This allows for the acquisition of dependencies between microservices in a microservice system before deployment, eliminating the need for manual annotation and post-deployment determination based on the operational data of each microservice. This improves the accuracy, comprehensiveness, and speed of dependency determination. Attached Figure Description

[0017] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.

[0018] Figure 1 A flowchart illustrating a method for determining dependencies provided in an embodiment of this disclosure;

[0019] Figure 2 This is a schematic diagram of the structure of a target dependency topology graph provided in an embodiment of the present disclosure;

[0020] Figure 3 A flowchart illustrating another method for determining dependencies provided in this embodiment of the disclosure;

[0021] Figure 4 A structural block diagram of a dependency determination device provided in an embodiment of this disclosure;

[0022] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0023] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0024] It should be understood that the steps described in the method embodiments of this disclosure may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this disclosure is not limited in this respect.

[0025] The term "comprising" and its variations as used herein are open-ended inclusions, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the description below.

[0026] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0027] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0028] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0029] Figure 1 This is a flowchart illustrating a method for determining dependencies according to an embodiment of this disclosure. The method can be executed by a dependency determination device, which can be implemented in software and / or hardware and is configurable in an electronic device, typically a computer device. The dependency determination method provided in this disclosure is applicable to scenarios where the dependencies between a microservice in a microservice system and other microservices in the same system are determined. Figure 1 As shown, the method for determining dependencies provided in this embodiment may include:

[0030] S101. Obtain the source code file, which contains the microservice code of the target microservice.

[0031] The target microservice can be any microservice whose dependencies need to be determined, such as the microservice whose dependencies on other microservices it calls need to be determined. This microservice can be the entry point microservice that the client can directly call. The microservice code of a specific microservice (such as the target microservice) can be the code of that microservice itself, and it can be recorded in a source code file. Correspondingly, the source code file can be a file containing the microservice code of the target microservice. This source code file can be a file containing only the microservice code of the target microservice, or it can be a file that further contains the microservice code of other microservices that the target microservice depends on, such as the source code file of the microservice system in which the target microservice resides.

[0032] Specifically, when determining the dependencies between a microservice and other microservices, the source code file containing the code of that microservice can be obtained. For example, the microservice whose dependencies need to be determined can be identified first according to a pre-set determination order, and designated as the target microservice; or, the microservice corresponding to the microservice identifier entered by the staff can be designated as the target microservice. Then, the source code file containing the code of the target microservice can be obtained, such as directly obtaining the source code file of the microservice system where the target microservice resides, or obtaining the microservice code of the target microservice based on the microservice identifier of the target microservice, to obtain a source code file containing only the code of the target microservice. This embodiment does not limit this.

[0033] To facilitate the subsequent determination of the dependencies between the target microservice and each of its invoked microservices, it is preferable to obtain the source code file of the microservice system in which the target microservice resides. This allows for the subsequent determination and analysis of the microservice code of each invoked microservice based on the source code file, avoiding the need to obtain the source code files of both the target microservice and each invoked microservice separately. This improves the speed of determining the dependencies of the target microservice. The following explanation uses this scenario as an example.

[0034] S102. Determine the dependency relationship between the target microservice and the called microservice based on the source code file, wherein the called microservice includes the microservice called by the target microservice.

[0035] In this context, the called microservice can be understood as the microservice called by the target microservice, that is, the microservice called by the target microservice. This can include microservices directly called by the target microservice, and can further include microservices indirectly called by the target microservice through other microservices. Dependency relationships can be understood as strong and weak dependencies, which can include strong dependencies and weak dependencies.

[0036] For example, based on the microservice code of the target microservice and the microservice code of each called microservice in the source code file, it can be determined whether an error in any called microservice will cause the target microservice to fail to provide services. The strong or weak dependency relationship between the target microservice and each called microservice can be determined based on this determination. For instance, if an error in a called microservice directly causes the target microservice to fail to provide services, then a strong dependency relationship can be determined between the target microservice and that called microservice. If an error in a called microservice still allows the target microservice to provide services normally, then a weak dependency relationship can be determined between the target microservice and that called microservice. Here, code analysis tools based on algorithms such as the Go SSA algorithm (e.g., golang.org / x / tools / go / ssa) and / or the Pointer algorithm (e.g., golang.org / x / tools / go / pointer) can be used to analyze the microservice code; this embodiment does not limit this approach.

[0037] In this embodiment, the strong and weak dependencies between the target microservice and the microservices it calls can be determined by analyzing the code of the target microservice and the code of each microservice it calls. This eliminates the need for manual annotation of these dependencies and avoids the need to determine them after deployment based on the runtime data of the target microservice and its callers. This overcomes the drawbacks of manual annotation, such as its large workload, susceptibility to human subjectivity, and susceptibility to errors. It also avoids the limitations of runtime result tracking, which only identifies dependencies of microservices that have generated runtime data, resulting in incomplete dependency determinations and an inability to promptly identify problems based on dependencies. Therefore, it enables rapid and comprehensive determination of the strong and weak dependencies between microservices in a microservice system.

[0038] In one implementation, determining the dependency relationship between the target microservice and the called microservice based on the source code file includes: constructing a target dependency topology graph of the target microservice based on the source code file, wherein the target dependency topology graph identifies the dependency relationships between microservices with direct calling relationships; and determining the dependency relationship between the target microservice and the called microservice based on the target dependency topology graph.

[0039] The target dependency topology graph can be understood as a topology graph used to identify the direct dependencies between the target microservice and each called microservice. This direct dependency can be understood as the dependency between two microservices that have a direct calling relationship. For example... Figure 2 As shown, the target dependency topology diagram can include the node corresponding to the target microservice (i.e., the root node) and the nodes corresponding to each called microservice. Two nodes with direct dependencies can be connected by a directional connection line. This connection line can point from the dependent node to the dependent node, that is, from the calling node to the called node. The strong and weak dependencies between the two nodes connected to each connection line can be marked.

[0040] In the above implementation, a target dependency topology graph can be constructed to record the dependencies between microservices (including the target microservice and each called microservice of the target microservice) that have direct calling relationships. Based on this target dependency topology graph, the strong and weak dependencies between the target microservice and each called microservice can be determined. For example, the target dependency topology graph of the target microservice can be constructed based on source code files. Based on this target dependency topology graph, it can be determined whether an error in any called microservice will cause the target microservice to fail to provide services, thereby determining the strong and weak dependencies between the target microservice and each called microservice.

[0041] Optionally, constructing the target dependency topology graph of the target microservice based on the source code file includes: determining the called microservice of the target microservice based on the source code file, and constructing the target dependency topology graph of the target microservice based on the dependency relationship between microservices with direct calling relationship, wherein the microservices with direct calling relationship include the target microservice and / or the called microservice.

[0042] Among them, the microservices with direct calling relationships mentioned above can be the target microservices and the microservices called by the target microservices that have direct calling relationships.

[0043] For example, based on the microservice code of the target microservice recorded in the source code file and the microservice code of each called microservice called by the target microservice, the strong and weak dependency relationships between microservices with direct calling relationships can be determined, and a dependency topology graph containing the node corresponding to the target microservice and the nodes corresponding to each called microservice of the target microservice can be constructed based on the strong and weak dependency relationships.

[0044] The dependency determination method provided in this embodiment obtains the source code file containing the code of the target microservice and determines the dependency relationship between the target microservice and the called microservices based on the source code file. By adopting the above technical solution, this embodiment determines the dependency relationship between the target microservice and each called microservice based on the source code. This allows for the acquisition of dependencies between microservices in the microservice system before deployment, eliminating the need for manual annotation and post-deployment determination based on the operational data of each microservice. This improves the accuracy, comprehensiveness, and speed of dependency determination.

[0045] Figure 3 This is a flowchart illustrating another method for determining dependencies provided in this embodiment. The solution in this embodiment can be combined with one or more optional solutions in the above embodiments. Optionally, the step of determining the called microservices of the target microservice based on the source code file and constructing a target dependency topology graph of the target microservice based on the dependency relationships between microservices with direct calling relationships includes: creating an original dependency topology graph containing the target microservice and a set of microservices containing the target microservice; retrieving a microservice from the set of microservices as the current microservice; determining whether the current microservice has a lower-level called microservice based on the current microservice code, wherein the current microservice code is the microservice code of the current microservice, and the lower-level called microservice is the microservice directly called by the current microservice; if yes, updating the original dependency topology graph based on the dependency relationship between the current microservice and the lower-level called microservice, adding the lower-level called microservice to the set of microservices, and returning to execute the operation of retrieving a microservice from the set of microservices as the current microservice; if no, returning to execute the operation of retrieving a microservice from the set of microservices as the current microservice, until the set of microservices is empty; and using the updated original dependency topology graph as the target dependency topology graph of the target microservice.

[0046] Optionally, before updating the original dependency topology graph based on the dependency relationship between the current microservice and the lower-level called microservice, the method further includes: parsing the remote call function in the current microservice code to obtain the microservice method function called by the remote call function, and determining the microservice corresponding to the microservice method function as the lower-level called microservice of the current microservice; and determining the dependency relationship between the current microservice and the lower-level called microservice based on the current microservice code.

[0047] Optionally, determining the dependency relationship between the target microservice and the called microservice based on the target dependency topology graph includes: for each called microservice, determining the dependency path between the target microservice and the called microservice based on the target dependency topology graph; if adjacent microservices in the dependency path have strong dependencies, then the target microservice and the called microservice are determined to have a strong dependency relationship; if there are adjacent microservices with weak dependencies in the dependency path, then the target microservice and the called microservice are determined to have a weak dependency relationship.

[0048] Correspondingly, such as Figure 3 As shown, the method for determining dependencies provided in this embodiment may include:

[0049] S201. Obtain the source code file, which contains the microservice code of the target microservice.

[0050] S202. Create the original dependency topology graph containing the target microservice and the set of microservices containing the target microservice.

[0051] The microservice set can be understood as a collection of microservices whose dependencies with their lower-level microservices still need to be analyzed. In other words, the microservice set can be used to store invoked microservices whose dependencies with their lower-level microservices have not yet been analyzed.

[0052] For example, a topology graph can be created to identify the dependencies between microservices. This could be a new dependency topology graph containing only the target microservice, used as the original dependency topology graph. An empty set can also be created to store the remaining microservices to be analyzed, such as a new set initially containing only the target microservice. Alternatively, if a dependency topology graph and microservice set for a previous microservice already exist, and the strong and weak dependencies between the previous microservice and its called microservices have been analyzed, then if the dependency topology graph contains the target microservice, it can be used as the original dependency topology graph, and the target microservice can be added to that microservice set. If the dependency topology graph does not contain the target microservice, it can be directly initialized to contain only the target microservice, and the initialized dependency topology graph can be used as the original dependency topology graph. The initialized microservice set can be used as the microservice set for the target microservice. This avoids the need to create multiple dependency topology graphs and microservice sets when sequentially determining the dependencies between multiple microservices and their called microservices, thus reducing memory usage.

[0053] S203. Select a microservice from the set of microservices as the current microservice.

[0054] The current microservice can be any microservice currently in the set of microservices, such as the target microservice or the microservice to which the target microservice is invoked.

[0055] Specifically, you can select a microservice from the set of microservices as the current microservice and remove it from the set of microservices.

[0056] It is understood that in this embodiment, instead of removing the current microservice from the microservice set, it can be marked as a determined state, thereby indicating that it has been used as the current microservice. In this case, a microservice that is not in a determined state can be obtained from the microservice set as the current microservice.

[0057] S204. Determine whether the current microservice has a lower-level called microservice based on the current microservice code. If yes, execute S205; otherwise, execute S208. Wherein, the current microservice code is the microservice code of the current microservice, and the lower-level called microservice is the microservice directly called by the current microservice.

[0058] Here, "current microservice code" refers to the code of the current microservice itself. "Lower-level called microservice" can be understood as the microservice directly called by the current microservice, excluding microservices indirectly called by the current microservice through other microservices.

[0059] In this embodiment, the dependency relationship between each microservice (including the target microservice and each called microservice of the target microservice) and the microservice it directly calls can be determined, and the dependency relationship between the target microservice and each called microservice can be determined based on the dependency relationship between the microservices that have a direct calling relationship.

[0060] Specifically, after identifying the current microservice that needs to have its dependencies analyzed with the microservices it directly calls, we can first determine whether the current microservice has any lower-level called microservices, that is, whether the current microservice calls other microservices. Thus, if it is determined that the current microservice does not have any lower-level called microservices, we can directly determine that the analysis of the current microservice is over, without performing subsequent operations to analyze its dependencies with the microservices it directly calls, thereby further improving the speed of determining the dependencies of the target microservice.

[0061] In this embodiment, the method for determining whether the current microservice has a lower-level called microservice can be flexibly set. For example, the current microservice code can be directly analyzed to determine the lower-level called microservice. If the lower-level called microservice of the current microservice is determined, it is determined that the current microservice has a lower-level called microservice; if the lower-level called microservice of the current microservice is not determined, it is determined that the current microservice does not have a lower-level called microservice.

[0062] Considering that microservices typically invoke other microservices via remote function calls, if a microservice has a subordinate microservice, then that microservice's code will contain the remote function. Therefore, when determining whether a microservice has a subordinate microservice being invoked, we can directly check if the microservice's code contains the remote function. For example, we can search for the remote function information (such as the name of the remote function) of the microservice system to which the microservice resides. If the remote function is found, then the microservice has a subordinate microservice being invoked; otherwise, the microservice does not. Preferably, determining whether a microservice has a subordinate microservice being invoked based on the microservice's code includes: if the microservice's code contains the remote function, then the microservice has a subordinate microservice being invoked; if the microservice's code does not contain the remote function, then the microservice does not have a subordinate microservice being invoked. Among them, the remote call function can be a remote procedure call (RPC) function, which is a function used to call other microservices via RPC.

[0063] S205. Parse the remote call function in the current microservice code to obtain the microservice method function called by the remote call function, and determine the microservice corresponding to the microservice method function as the lower-level called microservice of the current microservice.

[0064] In this context, a microservice method function can be understood as a method function of a microservice. A remote call function can invoke a microservice by calling a method function of that microservice.

[0065] In this embodiment, when it is determined that the current microservice has a lower-level called microservice, the lower-level called microservices of the current microservice can be further determined to facilitate subsequent analysis of the dependency relationship between the current microservice and each lower-level called microservice.

[0066] Specifically, the process can begin by retrieving the remote call function information of the microservice system in which the current microservice resides from the current microservice code, parsing the remote call function, and determining the microservice method function called by the remote call function. Then, based on the pre-defined correspondence between each microservice and each microservice method function, the microservice corresponding to the microservice method function called by the remote call function of the current microservice is determined, and it is identified as the lower-level called microservice directly called by the current microservice.

[0067] S206. Determine the dependency relationship between the current microservice and the underlying called microservice based on the current microservice code.

[0068] Specifically, by analyzing the current microservice code, we can determine whether the current microservice will return an error message to its upper-level node when an error occurs during the service provision process of a lower-level called microservice. In other words, whether this will cause the current microservice to fail in providing its service. If so, it can be determined that the current microservice has a strong dependency relationship with the lower-level called microservice. If not, it can be determined that the current microservice has a weak dependency relationship with the lower-level called microservice.

[0069] In one implementation, determining the dependency relationship between the current microservice and the lower-level called microservice based on the current microservice code includes: obtaining the result return function of the current microservice from the current microservice code; and determining the dependency relationship between the current microservice and the lower-level called microservice based on the result return function.

[0070] The result return function can be a function that returns the call result (such as the calculation result) of the current microservice to its upper-level node. That is, when the current microservice is called by its upper-level node, the current microservice can return the call result generated by the current microservice in response to the call of the current microservice through the result return function.

[0071] Specifically, the result return function in the current microservice code can be obtained. Based on the result return function, it can be determined whether the current microservice will return error information to its upper-level node when an error occurs in each lower-level called microservice. The lower-level called microservices that the current microservice will return error information to the upper-level node when an error occurs are identified as lower-level called microservices with strong dependencies, while the lower-level called microservices that the current microservice will not return error information to the upper-level node when an error occurs are identified as lower-level called microservices with weak dependencies.

[0072] In the above implementation, optionally, determining the dependency relationship between the current microservice and the lower-level microservice based on the result return function includes: for each lower-level called microservice, determining, based on the result return function, whether the current microservice returns a second error message to the upper-level node when it receives a first error message sent by the lower-level called microservice, wherein the upper-level node is a called microservice or client that directly calls the current microservice; if yes, then it is determined that there is a strong dependency relationship between the current microservice and the lower-level called microservice; if no, then it is determined that there is a weak dependency relationship between the current microservice and the lower-level called microservice.

[0073] The first error message can be an error message received by the current microservice and sent by its lower-level called microservice. It can be generated and sent to the current microservice when an error occurs during the service provision process of the corresponding lower-level called microservice. The second error message can be an error message generated and returned to its generating node when an error occurs during the service provision process of the current microservice, such as when it cannot obtain the correct running result returned by one or more lower-level called microservices, or when it receives error messages sent by one or more lower-level called microservices. This upper-level node can be understood as the node that directly calls the current microservice. For example, when the current microservice is the target microservice, the upper-level node can be the client; when the current microservice is a called microservice of the target microservice, the upper-level node can be the microservice that directly calls the current microservice.

[0074] In this embodiment, the result return function can be parsed to determine the lower-level called microservices that the current microservice will return error information to the upper-level node when an error occurs. The dependency relationship between the current microservice and the determined lower-level called microservices is determined as a strong dependency relationship, and the dependency relationship between the current microservice and other lower-level called microservices other than the determined target lower-level called microservices is determined as a weak dependency relationship.

[0075] For example, for each lower-level called microservice of the current microservice, based on the result return function of the current microservice, it is determined whether the current microservice will also return an error message (i.e., the second error message) to its upper-level node when the lower-level called microservice returns an error message to the current microservice (i.e., the first error message). In other words, it is determined whether the return of an error message by the current microservice will cause the current microservice to return an error message to its upper-level node. If yes, it is determined that there is a strong dependency between the current microservice and the lower-level called microservice; if not, it is determined that there is a weak dependency between the current microservice and the lower-level called microservice.

[0076] S207. Update the original dependency topology graph according to the dependency relationship between the current microservice and the lower-level called microservice, add the lower-level called microservice to the microservice set, and return to execute S203.

[0077] For example, nodes corresponding to each lower-level called microservice of the current microservice can be added to the dependency topology graph. After the nodes are added, connecting lines originating from the node corresponding to the current microservice are used to connect the node corresponding to the current microservice to the node corresponding to each lower-level microservice. The dependency relationship between the current microservice and each lower-level called microservice is marked on the connecting lines. For example, the dependency relationship between the current microservice and each lower-level called microservice can be marked with text on the corresponding connecting lines (e.g., ...). Figure 2 (As shown), or, different display states can be used to display the connection lines between the current microservice and the lower-level called microservice with strong dependencies, as well as the connection lines between the current microservice and the lower-level called microservice with weak dependencies.

[0078] In addition, before, after, or simultaneously with updating the original dependency topology, the identified lower-level called microservices can be added to the microservice set. For example, the microservice identifier information of the identified lower-level called microservices can be added to the microservice set to facilitate further determination of the dependency relationship between each microservice in the microservice set and the microservices it directly calls.

[0079] S208. Determine whether the microservice set is empty. If yes, execute S209; otherwise, return to execute S203.

[0080] Specifically, when the current microservice has lower-level called microservices, the original dependency topology can be updated first based on the dependency relationship between the current microservice and its lower-level called microservices. Then, the lower-level called microservices are added to the microservice set as microservices to be analyzed, and execution returns to step S203 to retrieve a microservice from the microservice set as the current microservice, and the dependency relationship between the newly retrieved microservice and its directly called functions is determined. When the current microservice does not have lower-level called microservices, the analysis of the current microservice is considered complete. The microservice set is then checked for non-emptiness, i.e., whether there are unanalyzed microservices in the set. If so, execution returns to step S203 to retrieve a microservice from the set as the current microservice, and the dependency relationship between the newly retrieved microservice and its directly called functions is determined. If not, the dependency relationships between the microservices with direct calling relationships (including the target microservice and the called microservices of the target microservice) are determined, and execution continues to step S209.

[0081] In this embodiment, the method of selecting a microservice from the microservice set as the current microservice can be configured as needed. For example, a microservice can be randomly selected from the microservice set, or the microservice with the highest priority can be selected from the microservice set according to a pre-set priority. The priority of each microservice can be configured as needed. For example, the priority can be set according to the depth-first traversal order, meaning the priority of each microservice in the microservice set is proportional to the traversal order when traversing the nodes corresponding to each microservice in the dependency topology graph using depth-first traversal; or the priority can be set according to the breadth-first traversal order, meaning the priority of each microservice in the microservice set is proportional to the traversal order when traversing the nodes corresponding to each microservice in the dependency topology graph using breadth-first traversal. This embodiment does not impose any restrictions on this.

[0082] S209. Use the updated original dependency topology graph as the target dependency topology graph of the target microservice.

[0083] Specifically, once the analysis of each called microservice of the target microservice is completed, the target dependency topology graph of the target microservice can be obtained.

[0084] S210. For each called microservice, determine the dependency path between the target microservice and the called microservice based on the target dependency topology graph, and execute S211 or S212, wherein the called microservice includes the microservice called by the target microservice.

[0085] S211. If there are strong dependencies between adjacent microservices in the dependency path, then it is determined that there is a strong dependency between the target microservice and the called microservice.

[0086] S212. If there are adjacent microservices with weak dependencies in the dependency path, then it is determined that there is a weak dependency between the target microservice and the called microservice.

[0087] In this context, the dependency path between a called microservice and the target microservice can be a path in the dependency topology graph with the node corresponding to the called microservice and the node corresponding to the target microservice as the two endpoints.

[0088] Specifically, once the target dependency topology graph of the target microservice is obtained, the dependency paths between each called microservice and the target microservice can be determined based on this graph. For each called microservice, it is determined whether the dependencies between microservices with direct dependencies along the dependency path between the called and target microservices are all strong dependencies. If so, the dependency paths between the target microservice and the called microservice (e.g., ...) can be determined. Figure 2 If there is a strong dependency between the target microservice corresponding to node A and the called microservice corresponding to node D, then it can be determined that the target microservice and the called microservice (e.g., ...) have a strong dependency relationship. Figure 2 There is a weak dependency between the target microservice corresponding to node A and the called microservice corresponding to node E.

[0089] It should be noted that if there are multiple dependency paths between a called microservice and the target microservice, the dependency relationship between the target microservice and the called microservice can be initially determined based on each dependency path. If it is initially determined based on each dependency path that there is a weak dependency relationship between the target microservice and the called microservice, then it can be finally determined that there is a weak dependency relationship between the target microservice and the called microservice. If it is initially determined based on at least one dependency path that there is a strong dependency relationship between the target microservice and the called microservice, then it can be finally determined that there is a strong dependency relationship between the target microservice and the called microservice.

[0090] In this embodiment, the remote call function information / result return function information of the microservice system (including the target microservice and each called microservice of the target microservice) can be determined based on the architecture information of the microservice system in which each microservice resides. Based on this remote call function information / result return function information, the remote call functions / result return functions in the code of each microservice are obtained, and the dependency relationships between the target microservice and each called microservice are analyzed based on these remote call functions / result return functions. Preferably, the dependency determination method provided in this embodiment further includes: determining the function information of the microservice system in which the target microservice resides based on the architecture information of the target microservice. The function information includes remote call function information and / or result return function information. Here, function information can be understood as function identification information, such as the function name. Taking the function name as an example, the remote call functions / result return functions of different microservice systems can have different names, which can be set by the developers as needed.

[0091] The dependency determination method provided in this embodiment can pre-analyze the dependency relationship between the target microservice and each called microservice based on the microservice code of the target microservice and the microservice code of each called microservice of the target microservice before going online, thereby improving the comprehensiveness and accuracy of the dependency determination results.

[0092] Figure 4 This is a structural block diagram of a dependency determination apparatus provided in an embodiment of the present disclosure. The apparatus can be implemented in software and / or hardware, and can be configured in an electronic device, typically a computer device. It can determine the dependencies between a microservice and the microservices it calls by executing a dependency determination method. Figure 4 As shown, the dependency determination device provided in this embodiment may include: a file acquisition module 401 and a dependency determination module 402, wherein,

[0093] The file acquisition module 401 is used to acquire source code files, wherein the source code files contain the microservice code of the target microservice.

[0094] The relationship determination module 402 is used to determine the dependency relationship between the target microservice and the called microservice based on the source code file, wherein the called microservice includes the microservice called by the target microservice.

[0095] The dependency determination apparatus provided in this embodiment obtains the source code file containing the microservice code of the target microservice through a file acquisition module, and determines the dependency relationship between the target microservice and the called microservices based on the source code file through a relationship determination module. By adopting the above technical solution, this embodiment determines the dependency relationship between the target microservice and its called microservices based on the source code. This allows for the acquisition of dependencies between microservices in the microservice system before deployment, eliminating the need for manual annotation and post-deployment determination based on the operational data of each microservice. This improves the accuracy, comprehensiveness, and speed of dependency determination.

[0096] In the above scheme, the relationship determination module 402 may include: a topology graph construction unit, used to construct a target dependency relationship topology graph of the target microservice based on the source code file, wherein the target dependency relationship topology graph identifies the dependency relationships between microservices with direct calling relationships; and a relationship determination unit, used to determine the dependency relationship between the target microservice and the called microservice based on the target dependency relationship topology graph.

[0097] In the above scheme, the topology graph construction unit can be used to: determine the called microservice of the target microservice based on the source code file, and construct the target dependency topology graph of the target microservice based on the dependency relationship between microservices with direct calling relationship, wherein the microservices with direct calling relationship include the target microservice and / or the called microservice.

[0098] In the above scheme, the topology graph construction unit may include: a creation subunit, used to create an original dependency relationship topology graph containing the target microservice and a microservice set containing the target microservice; an acquisition subunit, used to extract a microservice from the microservice set as the current microservice; a judgment subunit, used to determine whether the current microservice has a lower-level called microservice based on the current microservice code, wherein the current microservice code is the microservice code of the current microservice, and the lower-level called microservice is the microservice directly called by the current microservice; if yes, then update the original dependency relationship topology graph according to the dependency relationship between the current microservice and the lower-level called microservice, add the lower-level called microservice to the microservice set, and return to execute the operation of extracting a microservice from the microservice set as the current microservice; if no, then return to execute the operation of extracting a microservice from the microservice set as the current microservice, until the microservice set is empty; and a determination subunit, used to use the updated original dependency relationship topology graph as the target dependency relationship topology graph of the target microservice.

[0099] In the above scheme, the judgment subunit can be used to: determine that the current microservice has a lower-level called microservice when there is a remote call function in the current microservice code; and determine that the current microservice does not have a lower-level called microservice when there is no remote call function in the current microservice code.

[0100] In the above scheme, the judgment subunit can also be used to: before updating the original dependency topology graph based on the dependency relationship between the current microservice and the lower-level called microservice, parse the remote call function in the current microservice code to obtain the microservice method function called by the remote call function, and determine the microservice corresponding to the microservice method function as the lower-level called microservice of the current microservice; determine the dependency relationship between the current microservice and the lower-level called microservice based on the current microservice code.

[0101] In the above scheme, the judgment subunit can be used to: obtain the result return function of the current microservice from the current microservice code; and determine the dependency relationship between the current microservice and the lower-level called microservice based on the result return function.

[0102] In the above scheme, the judgment subunit can be used to: for each lower-level called microservice, determine in the result return function whether the current microservice returns a second error message to the upper-level node when it receives the first error message sent by the lower-level called microservice, where the upper-level node is the called microservice or client that directly calls the current microservice; if yes, then it is determined that there is a strong dependency between the current microservice and the lower-level called microservice; if no, then it is determined that there is a weak dependency between the current microservice and the lower-level called microservice.

[0103] In the above scheme, the relationship determination unit can be used to: for each called microservice, determine the dependency path between the target microservice and the called microservice based on the target dependency relationship topology graph; if there are strong dependencies between adjacent microservices in the dependency path, then it is determined that there is a strong dependency between the target microservice and the called microservice; if there are adjacent microservices with weak dependencies in the dependency path, then it is determined that there is a weak dependency between the target microservice and the called microservice.

[0104] The dependency determination apparatus provided in this disclosure can execute the dependency determination method provided in any embodiment of this disclosure, and has the corresponding functional modules and beneficial effects for executing the dependency determination method. Technical details not described in detail in this embodiment can be found in the dependency determination method provided in any embodiment of this disclosure.

[0105] The following is for reference. Figure 5 This illustration shows a structural diagram of an electronic device (e.g., a computer device) 500 suitable for implementing embodiments of the present disclosure. The terminal devices in the embodiments of the present disclosure may include, but are not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0106] like Figure 5 As shown, the electronic device 500 may include a processing unit (e.g., a central processing unit, a graphics processor, etc.) 501, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 502 or a program loaded from a storage device 508 into a random access memory (RAM) 503. The RAM 503 also stores various programs and data required for the operation of the electronic device 500. The processing unit 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0107] Typically, the following devices can be connected to I / O interface 505: input devices 506 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 507 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 508 including, for example, magnetic tapes, hard disks, etc.; and communication devices 509. Communication device 509 allows electronic device 500 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 5 An electronic device 500 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0108] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 509, or installed from a storage device 508, or installed from a ROM 502. When the computer program is executed by the processing device 501, it performs the functions defined in the methods of embodiments of this disclosure.

[0109] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0110] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0111] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0112] The aforementioned computer-readable medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to: acquire a source code file containing microservice code of a target microservice; and determine the dependency relationship between the target microservice and a called microservice based on the source code file, wherein the called microservice includes the microservice called by the target microservice.

[0113] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including but not limited to object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0114] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0115] The units described in the embodiments of this disclosure can be implemented in software or hardware. The names of modules do not, in some cases, constitute a limitation on the unit itself.

[0116] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application Standard Products (ASSPs), System-on-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), and so on.

[0117] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0118] According to one or more embodiments of this disclosure, Example 1 provides a method for determining dependencies, including:

[0119] Obtain the source code file, which contains the microservice code of the target microservice;

[0120] The dependency relationship between the target microservice and the called microservice is determined based on the source code file, wherein the called microservice includes the microservice called by the target microservice.

[0121] According to one or more embodiments of this disclosure, Example 2, based on the method described in Example 1, includes determining the dependency relationship between the target microservice and the invoked microservice based on the source code file, comprising:

[0122] Construct a target dependency topology graph of the target microservice based on the source code file, wherein the target dependency topology graph identifies the dependency relationships between microservices that have direct calling relationships;

[0123] The dependency relationship between the target microservice and the called microservice is determined based on the target dependency topology graph.

[0124] According to one or more embodiments of this disclosure, Example 3, based on the method described in Example 2, includes constructing the target dependency topology graph of the target microservice based on the source code file, comprising:

[0125] The called microservices of the target microservice are determined based on the source code file, and a target dependency topology graph of the target microservice is constructed based on the dependency relationships between microservices with direct calling relationships, wherein the microservices with direct calling relationships include the target microservice and / or the called microservices.

[0126] According to one or more embodiments of this disclosure, Example 4 describes the method described in Example 3, wherein determining the invoked microservices of the target microservice based on the source code file and constructing a target dependency topology graph of the target microservice based on the dependencies between microservices with direct invocation relationships includes:

[0127] Create the original dependency topology graph containing the target microservice and the set of microservices containing the target microservice;

[0128] Select one microservice from the set of microservices as the current microservice;

[0129] Determine whether the current microservice has a lower-level called microservice based on the current microservice code, wherein the current microservice code is the microservice code of the current microservice, and the lower-level called microservice is the microservice directly called by the current microservice;

[0130] If so, the original dependency topology graph is updated according to the dependency relationship between the current microservice and the lower-level called microservice, the lower-level called microservice is added to the microservice set, and the operation of retrieving a microservice from the microservice set as the current microservice is returned.

[0131] If not, then return to the operation of taking a microservice from the set of microservices as the current microservice, until the set of microservices is empty;

[0132] The updated original dependency topology graph is used as the target dependency topology graph of the target microservice.

[0133] According to one or more embodiments of this disclosure, Example 5 describes the method described in Example 3, wherein determining whether the current microservice has a lower-level called microservice based on the current microservice code includes:

[0134] If a remote call function exists in the current microservice code, then it is determined that the current microservice has a lower-level called microservice.

[0135] If there is no remote call function in the current microservice code, then it is determined that the current microservice does not have a lower-level called microservice.

[0136] According to one or more embodiments of this disclosure, Example 6, based on the method of Example 4, further includes, before updating the original dependency topology graph according to the dependency relationship between the current microservice and the underlying invoked microservice:

[0137] The remote call function in the current microservice code is parsed to obtain the microservice method function called by the remote call function, and the microservice corresponding to the microservice method function is determined as the lower-level called microservice of the current microservice.

[0138] The dependency relationship between the current microservice and the underlying called microservice is determined based on the current microservice code.

[0139] According to one or more embodiments of this disclosure, Example 7 describes the method described in Example 6, wherein determining the dependency relationship between the current microservice and the underlying invoked microservice based on the current microservice code includes:

[0140] The result return function of the current microservice is obtained from the current microservice code;

[0141] The result returns a function that determines the dependency relationship between the current microservice and the underlying called microservice.

[0142] According to one or more embodiments of this disclosure, Example 8 describes the method described in Example 7, wherein determining the dependency relationship between the current microservice and the lower-level microservice based on the result return function includes:

[0143] For each lower-level called microservice, based on the result return function, it is determined whether the current microservice returns a second error message to the upper-level node when it receives the first error message sent by the lower-level called microservice. The upper-level node is the called microservice or client that directly calls the current microservice.

[0144] If so, it is determined that there is a strong dependency between the current microservice and the underlying microservice being called;

[0145] If not, then it is determined that there is a weak dependency between the current microservice and the underlying microservice being called.

[0146] According to one or more embodiments of this disclosure, Example 9 describes the method described in Example 2, wherein determining the dependency relationship between the target microservice and the invoked microservice based on the target dependency topology graph includes:

[0147] For each called microservice, the dependency path between the target microservice and the called microservice is determined based on the target dependency topology graph;

[0148] If adjacent microservices in the dependency path have strong dependencies on each other, then it is determined that there is a strong dependency between the target microservice and the called microservice.

[0149] If there are adjacent microservices with weak dependencies in the dependency path, then it is determined that there is a weak dependency between the target microservice and the called microservice.

[0150] According to one or more embodiments of this disclosure, Example 10 provides a dependency determination apparatus, comprising:

[0151] The file acquisition module is used to acquire source code files, which contain the microservice code of the target microservice.

[0152] The relationship determination module is used to determine the dependency relationship between the target microservice and the called microservice based on the source code file, wherein the called microservice includes the microservice called by the target microservice.

[0153] According to one or more embodiments of this disclosure, Example 11 provides an electronic device, including:

[0154] One or more processors;

[0155] Memory, used to store one or more programs.

[0156] When the one or more programs are executed by the one or more processors, the one or more processors implement the dependency determination method as described in any of Examples 1-9.

[0157] According to one or more embodiments of the present disclosure, Example 12 provides a computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements a method for determining dependencies as described in any of Examples 1-9.

[0158] According to one or more embodiments of this disclosure, Example 13 provides a computer program product that, when executed by a computer, causes the computer to implement a dependency determination method as described in any of Examples 1-9.

[0159] The above description is merely a preferred embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features disclosed in this disclosure that have similar functions.

[0160] Furthermore, while the operations are described in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order. In certain environments, multitasking and parallel processing may be advantageous. Similarly, while several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0161] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative examples of implementing the claims.

Claims

1. A method of determining a dependency relationship, characterized by, The method comprises the following steps: obtaining a source code file, wherein the source code file records microservice code of a target microservice; determining a dependency relationship between the target microservice and a called microservice according to the source code file, wherein the called microservice comprises a microservice indirectly called by the target microservice, the dependency relationship comprises a strong dependency relationship and a weak dependency relationship, and the dependency relationship between the target microservice and the called microservice is determined by analyzing a result return function in microservice code of at least part of microservices, including the target microservice, to determine whether the target microservice fails to provide services when the called microservice has an error, without running the target microservice and the called microservice; the step of determining the dependency relationship between the target microservice and the called microservice according to the source code file comprises: in response to the existence of multiple calling paths between the target microservice and the called microservice, and at least part of the calling paths indicating that the target microservice and the called microservice have a strong dependency relationship, determining that the target microservice and the called microservice have a strong dependency relationship; in response to the existence of multiple calling paths between the target microservice and the called microservice, and all the multiple calling paths indicating that the target microservice and the called microservice have a weak dependency relationship, determining that the target microservice and the called microservice have a weak dependency relationship.

2. The method of claim 1, wherein, the step of determining the dependency relationship between the target microservice and the called microservice according to the source code file comprises: constructing a target dependency relationship topology graph of the target microservice according to the source code file, wherein the target dependency relationship topology graph identifies the dependency relationship between each microservice having a direct calling relationship; determining the dependency relationship between the target microservice and the called microservice according to the target dependency relationship topology graph.

3. The method of claim 2, wherein, the step of constructing the target dependency relationship topology graph of the target microservice according to the source code file comprises: determining a called microservice of the target microservice according to the source code file, and constructing a target dependency relationship topology graph of the target microservice according to the dependency relationship between microservices having a direct calling relationship, wherein the microservices having a direct calling relationship comprise the target microservice and / or the called microservice.

4. The method of claim 3, wherein, the step of determining the called microservice of the target microservice according to the source code file, and constructing the target dependency relationship topology graph of the target microservice according to the dependency relationship between microservices having a direct calling relationship comprises: creating an original dependency relationship topology graph containing the target microservice and a microservice set containing the target microservice; taking one microservice from the microservice set as a current microservice; determining whether the current microservice has a lower layer called microservice according to current microservice code, wherein the current microservice code is microservice code of the current microservice, and the lower layer called microservice is a microservice directly called by the current microservice; If yes, updating the original dependency topology graph according to a dependency relationship between the current microservice and the lower-layer called microservice, adding the lower-layer called microservice to the microservice set, and returning an operation of taking one microservice from the microservice set as the current microservice; If no, returning the operation of taking one microservice from the microservice set as the current microservice until the microservice set is empty; Taking the updated original dependency topology graph as a target dependency topology graph of the target microservice.

5. The method of claim 4, wherein, The operation of determining whether the current microservice exists the lower-layer called microservice according to the current microservice code comprises: If the current microservice code exists a remote calling function, determining that the current microservice exists the lower-layer called microservice; If the current microservice code does not exist the remote calling function, determining that the current microservice does not exist the lower-layer called microservice.

6. The method of claim 4, wherein, Before the operation of updating the original dependency topology graph according to the dependency relationship between the current microservice and the lower-layer called microservice, further comprising: parsing the remote calling function in the current microservice code to obtain a microservice method function called by the remote calling function, and determining a microservice corresponding to the microservice method function as the lower-layer called microservice of the current microservice; determining the dependency relationship between the current microservice and the lower-layer called microservice according to the current microservice code.

7. The method of claim 6, wherein, The operation of determining the dependency relationship between the current microservice and the lower-layer called microservice according to the current microservice code comprises: obtaining a result returning function of the current microservice from the current microservice code; determining the dependency relationship between the current microservice and the lower-layer called microservice according to the result returning function.

8. The method of claim 7, wherein, The operation of determining the dependency relationship between the current microservice and the lower-layer called microservice according to the result returning function comprises: for each lower-layer called microservice, judging, based on the result returning function, whether the current microservice returns second error information to an upper-layer node when receiving first error information sent by the lower-layer called microservice, the upper-layer node being a called microservice directly calling the current microservice or a client; if yes, determining that the current microservice and the lower-layer called microservice have a strong dependency relationship; if no, determining that the current microservice and the lower-layer called microservice have a weak dependency relationship.

9. The method of claim 2, wherein, The operation of determining the dependency relationship between the target microservice and the called microservice according to the target dependency topology graph comprises: for each called microservice, determining a dependency path between the target microservice and the called microservice according to the target dependency topology graph; if adjacent microservices in the dependency path all have a strong dependency relationship, determining that the target microservice and the called microservice have a strong dependency relationship; If there are adjacent microservices with weak dependency relationships in the dependency path, it is determined that the target microservice and the called microservice have a weak dependency relationship.

10. A device for determining dependencies, characterized in that, The method comprises the steps of: a file acquisition module is configured to acquire a source code file, wherein the source code file records microservice code of a target microservice; a relationship determination module is configured to determine a dependency relationship between the target microservice and a called microservice according to the source code file, wherein the called microservice comprises a microservice indirectly called by the target microservice, the dependency relationship comprises a strong dependency relationship and a weak dependency relationship, and the dependency relationship between the target microservice and the called microservice is determined by analyzing a result return function in microservice code of at least part of microservices, including the target microservice, to determine whether the target microservice fails to provide services when the called microservice has an error, without running the target microservice and the called microservice; the relationship determination module is specifically configured to: in response to the existence of multiple calling paths between the target microservice and the called microservice, and at least part of the calling paths indicating that the target microservice and the called microservice have a strong dependency relationship, it is determined that the target microservice and the called microservice have a strong dependency relationship; in response to the existence of multiple calling paths between the target microservice and the called microservice, and the multiple calling paths all indicating that the target microservice and the called microservice have a weak dependency relationship, it is determined that the target microservice and the called microservice have a weak dependency relationship.

11. An electronic device, comprising: The method comprises the steps of: one or more processors; a memory for storing one or more programs, when the one or more programs are executed by the one or more processors, the one or more processors implement the dependency relationship determination method of any one of claims 1-9.

12. A computer readable storage medium having stored thereon a computer program, characterized in that, The program is executed by the processor to implement the dependency relationship determination method of any one of claims 1-9.

13. A computer program product, characterised in that, When the computer program product is executed by the computer, the computer implements the dependency relationship determination method of any one of claims 1-9.

Images