Method and device for analyzing function call relationship under microservice architecture

Abstract

The present disclosure provides a method and device for analyzing function call relationship under micro-service architecture, and relates to the technical field of computer, in particular to the field of static program analysis. The specific implementation scheme is as follows: a plurality of functions are obtained as static pointer analysis starting points; static program analysis is performed on a target code library according to the static pointer analysis starting points, and a function call graph is generated according to an analysis result, the function call graph including a plurality of call edges determined based on the static pointer analysis starting points, the call edges being used to represent function call relationship of function calls performed by the static pointer analysis starting points as caller nodes; a plurality of call edges included in the function call graph are traversed to obtain target call edges stored in a graph database.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the technical field of computer, and particularly relates to the field of static program analysis. BACKGROUND

[0002] Static program analysis refers to a method of analyzing the semantics and behavior of code without actually executing the program. With the rapid development of Go language in recent years, static program analysis technology is also widely used in Go function call relationship and coding specification checking.

[0003] However, the current static program analysis tools usually only support taking the main function as the starting point of pointer analysis. For some programs that rely on dynamic call processing requests (such as HTTP Server), the static analysis with the main function as the starting point of pointer analysis will lose a large amount of function call relationship analysis results due to the unreachable problem of dynamic call edges. SUMMARY

[0004] The present disclosure provides a method and device for analyzing function call relationship under microservice architecture.

[0005] According to an aspect of the present disclosure, a method for analyzing function call relationship under microservice architecture is provided, comprising: obtaining a plurality of functions as static pointer analysis starting points; performing static program analysis on a target code library according to the static pointer analysis starting points, and generating a function call graph according to the analysis result, the function call graph including a plurality of call edges determined based on the static pointer analysis starting points, the call edges being used to represent function call relationship of function calls with the static pointer analysis starting points as caller nodes; traversing the plurality of call edges included in the function call graph to obtain target call edges stored in a graph database.

[0006] According to another aspect of the present disclosure, a device for analyzing function call relationship under microservice architecture is provided, comprising: an obtaining module configured to obtain a plurality of functions as static pointer analysis starting points; an analysis module configured to perform static program analysis on a target code library according to the static pointer analysis starting points, and generate a function call graph according to the analysis result, the function call graph including a plurality of call edges determined based on the static pointer analysis starting points, the call edges being used to represent function call relationship of function calls with the static pointer analysis starting points as caller nodes; and a processing module configured to traverse the plurality of call edges included in the function call graph to obtain target call edges stored in a graph database.

[0007] According to another aspect of the present disclosure, an electronic device is provided, comprising: at least one processor; and a memory connected in communication with 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 to enable the at least one processor to perform the method described above.

[0008] According to another aspect of the present disclosure, a non-transitory computer-readable storage medium storing computer instructions is provided, wherein the computer instructions are used to cause a computer to perform the method described above.

[0009] According to another aspect of the present disclosure, a computer program product is provided, comprising a computer program which, when executed by a processor, implements the method described above.

[0010] The method for analyzing function call relationship under microservice architecture provided by the present disclosure can obtain more comprehensive function call relationship, generate more comprehensive function call graph, and the analysis result based on the function call graph is also more accurate.

[0011] It should be understood that the content described in this part is not intended to identify key or important features of the embodiments of the present disclosure, nor to limit the scope of the present disclosure. Other features of the present disclosure will become apparent from the following description. BRIEF DESCRIPTION OF DRAWINGS

[0012] The accompanying drawings are used to better understand the present scheme, and do not constitute a limitation on the present disclosure. Among them:

[0013] Figure 1 is a method flowchart for analyzing function call relationship under microservice architecture according to an embodiment of the present disclosure;

[0014] Figure 2 is a method flowchart for analyzing function call relationship under microservice architecture according to another embodiment of the present disclosure;

[0015] Figure 3 is a method flowchart for analyzing function call relationship under microservice architecture according to another embodiment of the present disclosure;

[0016] Figure 4 is a method flowchart for analyzing function call relationship under microservice architecture according to another embodiment of the present disclosure;

[0017] Figure 5 is a block diagram of an apparatus for analyzing function call relationship under microservice architecture according to an embodiment of the present disclosure;

[0018] Figure 6is a block diagram of an electronic device for implementing a method of analyzing function call relationships in a microservice architecture according to an embodiment of the disclosure. DETAILED DESCRIPTION

[0019] Exemplary embodiments of the disclosure are described herein with reference to the accompanying drawings, in which various details of the disclosure are set forth to facilitate an understanding. However, it will be appreciated that various changes in the details can be made without departing from the scope and spirit of the disclosure. Also, the disclosure will be described with reference to the accompanying drawings, in which like reference numerals denote like elements throughout the several figures. In addition, the description of the disclosure is not intended to limit the scope of the disclosure, and the description should not be interpreted as limiting the scope of the disclosure.

[0020] Static program analysis refers to a method of analyzing the semantics and behavior of code without actually executing the program. In recent years, with the rapid development of the Go language, static program analysis techniques are also widely used in Go function call relationship and coding specification checking. However, the current static program analysis tools usually only support taking the func main() function as the starting point of pointer analysis. For some programs that rely on dynamic call processing requests (such as HTTP Server), the static analysis with the func main() function as the starting point of pointer analysis will lose a large amount of function call relationship analysis results due to the unreachable problem of dynamic call edges. On the other hand, the current static program analysis tools cannot parse the cross-service call relationship in the microservice architecture based on the HTTP Server, resulting in inaccurate function call relationship results.

[0021] For example, the official Go module golang.org / x / tools implements Andersen's pointer analysis algorithm and provides basic function call graph generation capabilities. However, the official Go library only supports taking func init() and func main() in package main as the starting point of pointer analysis, which is fatal for programs that rely on dynamic call processing requests such as Web Server, because it means that static program analysis is unreachable and will inevitably lose a large amount of analysis results.

[0022] As a specific example, to avoid excessive expansion of router configuration, Go Web Server often uses reflect to establish dynamic routing. For static program analysis, if only func main() can be specified as the starting point, the functions under the controller are unreachable.

[0023] Based on this, the embodiment of the disclosure provides a method for analyzing function call relationship under a microservice architecture. A plurality of functions are taken as static pointer analysis starting points to perform static program analysis on a target code library, so that a more comprehensive function call relationship can be obtained and a more comprehensive function call graph can be generated, and thus an analysis result of the comprehensive function call relationship can be obtained based on the function call graph.

[0024] Figure 1 is a flow chart of a method for analyzing function call relationship under a microservice architecture according to an example embodiment of the disclosure. The method comprises the following steps:

[0025] In step S101, a plurality of functions are obtained as static pointer analysis starting points.

[0026] The static pointer analysis starting points are used to analyze the function call relationship in the code library when performing static program analysis starting from the static pointer analysis starting points.

[0027] Optionally, a user can customize a plurality of functions as static pointer analysis starting points. By modifying the official library, the plurality of functions are transmitted into the official library. When the program is initialized, the user-defined configuration is read from the official library to obtain the static pointer analysis starting points of each code library.

[0028] Specifically, the pointer.Config module is used to manage the analysis starting points of each code library. Before the official library is modified, the pointer.Config module transmits the main package of the ssa.Package type by default. After the func main() and the func init() are obtained from the main package and converted into CGNode, the static program analysis is started.

[0029] The embodiment of the disclosure modifies the official library and adds a field in the pointer.Config module. The non-main function customized by the user can be transmitted as the starting point. The non-main function customized by the user can be any named function. When the static program analysis is needed, the configuration of the non-main function customized by the user is read. The non-main function customized by the user and the init function corresponding to the package are converted into CGNode and used as the static pointer analysis starting point.

[0030] In step S102, the target code library is analyzed according to the static pointer analysis starting points, and a function call graph is generated according to the analysis result.

[0031] The nodes in the function call relationship graph are a set of all functions in the program, and the edges in the graph, also referred to as call edges, represent the call relationship between functions. If there is a call relationship between functions, the nodes are connected by a directed arc, which points from the caller node to the callee node. If there is a loop in the call relationship graph, it indicates that there is a recursive call in the program.

[0032] In the embodiments of the present disclosure, the function call graph includes a plurality of call edges determined based on the static pointer analysis starting points, and the call edges are used to represent the function call relationship of the function call performed by the static pointer analysis starting point as the caller node.

[0033] For example, the static pointer analysis starting points of the target code library are 3, which are the main function, the C function, and the F function. The function call relationship of the target code library obtained by static program analysis is main->A->B, C->D, and F->I. Then, main->A->B represents the call edge determined by taking the main function as the static pointer analysis starting point, the main function is the caller node (caller), and the B function is the callee node (callee). Similarly, C->D and F->I represent the call edges determined by taking the C function and the F function as the static pointer analysis starting point, respectively, and the C function and the F function are the caller nodes, and the D function and the I function are the callee nodes.

[0034] In step S103, the plurality of call edges included in the function call graph are traversed to obtain the target call edge stored in the graph database.

[0035] Optionally, the caller node and the callee node of each call edge in the plurality of call edges are first converted into normalized data for operation and storage, and then the plurality of call edges are traversed to shorten the traversal time.

[0036] In the embodiments of the present disclosure, a plurality of functions are taken as the static pointer analysis starting points, and the function call graph generated by the static program analysis of the target code library based on the static pointer analysis starting points can more comprehensively reflect the function call relationship in the target code library, and then the target call edge stored in the graph database based on the function call graph is more comprehensive and accurate.

[0037] Figure 2 is a flowchart of the method for traversing the plurality of call edges included in the function call graph to obtain the target call edge stored in the graph database according to the embodiments of the present disclosure. Referring to Figure 2 The method includes the following steps.

[0038] In step S201, the plurality of call edges included in the function call graph are traversed, and the call type of each call edge in the plurality of call edges is determined.

[0039] The call type includes an intra-service call or an inter-service call.

[0040] Optionally, the intra-service call indicates that the caller node and the callee node belong to functions in the same module, that is, the service names of the caller node and the callee node are the same. The inter-service call indicates that the caller node and the callee node belong to functions in different modules, that is, the service names of the caller node and the callee node are different.

[0041] For example, user information and a user nickname are stored in a user module, and user permissions are stored in a perm module. When we need to obtain user information, we first need to obtain a user nickname, and then find corresponding user information according to the user nickname. At this time, the call relationship is user module->user module, which belongs to the same module, that is, an intra-service call. When we need to obtain user permissions, we need to first obtain a user nickname, and then find corresponding user permissions according to the user nickname. At this time, the call relationship is perm module->user module, which belongs to different modules, that is, an inter-service call.

[0042] Optionally, when multiple call edges included in the function call graph are traversed, the call type of each call edge is determined based on a user-defined function rule.

[0043] In step S202, a first call edge whose call type is an intra-service call is determined.

[0044] In step S203, a target call edge is determined based on the first call edge, and the target call edge is stored in the graph database.

[0045] Optionally, when the target call edge is written into the graph database, the target call edge is automatically deduplicated according to data already stored in the graph database. If the target call edge already exists in the graph database, the target call edge is not stored in the graph database.

[0046] In the embodiment of the present disclosure, based on the function call graph, each call edge in the function call graph is analyzed, and it can be analyzed whether the call edge belongs to an intra-service call or an inter-service call. Compared with the prior art in which the type of the call edge cannot be analyzed, the type of the call edge can be accurately analyzed in the embodiment of the present disclosure. Since the function call graph covers more comprehensively, the call edge belonging to the intra-service call is more accurate and comprehensive based on the function call graph, so that the data stored in the graph database is more comprehensive, and the query result obtained when the graph database is queried subsequently is more accurate.

[0047] Further, the first call edge that meets a preset requirement is filtered out as a target call edge in the first call edge. If the first call edge does not meet the preset requirement, the first call edge that does not meet the requirement is discarded.

[0048] In the embodiments of the present disclosure, by screening the first call edge, the call edge that does not meet the requirement is discarded, so that the call edge stored in the graph database is more accurate.

[0049] Figure 3 is a flowchart of a method for obtaining a target call edge stored in a graph database according to another traversal function call graph comprising a plurality of call edges, referring to Figure 3 The method comprises the following steps.

[0050] In step S301, a plurality of call edges included in the function call graph are traversed, and the call type of each call edge in the plurality of call edges is determined.

[0051] In step S302, the second call edge whose call type is inter-service call is determined, and the callee node corresponding to the second call edge is determined.

[0052] Optionally, after determining that the call type of the second call edge is inter-service call, the second call edge is stripped out from the function call graph, and the second call edge is serialized and stored in the global temporary file in the order of rows.

[0053] Each piece of serialized data contains the basic information of the caller node and the callee node in the second call edge, such as service_name, package_name, receiver_name and function_name.

[0054] In step S303, if the callee node is a preset node, the second call edge is stored in the graph database.

[0055] In the embodiments of the present disclosure, by determining the second call edge whose call type is inter-service call, and judging whether the callee node of the second call edge is a preset node, if the callee node is a preset node, it means that the second call edge can call the actual required function, so it is directly stored in the graph database, so that the call edge stored in the graph database is accurate and meets the functional requirements.

[0056] In some embodiments, it is assumed that there are two independent services user and perm, corresponding to module hello / world / perm and module hello / world / user respectively, and the function in the perm service calls the function in the user through inter-service call. The call edge directly obtained by static program analysis is: [perm][demo][][GetUserInfo]->[perm][demo][][RemoteCall]; and the actual expected call edge is: [perm][demo][][GetUserInfo]->[user][][][GetUserName]. Although the result obtained by static program analysis conforms to the semantics of the Go language, it does not conform to the expectation of the function, and therefore we need to handle this special case to obtain the actual expected result. The following will illustrate this special case, as shown in Figure 4 The following steps are included.

[0057] In step S401, a plurality of call edges included in the function call graph are traversed, and the call type of each call edge in the plurality of call edges is determined.

[0058] In step S402, a second call edge whose call type is inter-service call is determined, and a callee node corresponding to the second call edge.

[0059] In step S403, if the callee node is not a preset node, the actual parameter of the second call edge is extracted.

[0060] The actual parameter includes a service name service_name and a function name function_name.

[0061] Specifically, if the second call edge is stored in a global temporary file, the text line in the global temporary file is first deserialized to obtain the function information of the callee node, the function corresponding to the callee node is found from the AST of the file where the callee node is located, the actual parameter is extracted from the fixed parameter position, and the service_name and function_name are obtained.

[0062] Optionally, the AST is generated according to each source code file after the function call graph is generated and is stored in a global variable.

[0063] It is worth noting that the actual parameter extracted in the embodiments of the present disclosure is all passed through a string literal.

[0064] In step S404, it is queried whether there is a call edge matching the actual parameter in the graph database, and the processing mode of the second call edge is determined based on the query result.

[0065] The processing manner includes discarding or storing in the graph database.

[0066] In the embodiments of the present disclosure, whether there is a matched calling edge in the graph database is determined by extracting the arguments of the second calling edge, and different processing manners are performed on the second calling edge based on different query results, so that the calling edges finally stored in the graph database are all expected and accurate calling edges.

[0067] As a possible implementation manner, if the query result is that no matched calling edge with the arguments is found, it is determined that the processing manner for the second calling edge is discarding.

[0068] As another possible implementation manner, if the query result is that a matched calling edge with the arguments is found, and the calling edge is a single calling edge, a target calling edge is generated based on the matched calling edge with the arguments and the second calling edge, and is stored in the graph database.

[0069] Optionally, the callee node of the second calling edge is completed based on the matched calling edge with the arguments to generate the target calling edge.

[0070] As still another possible implementation manner, if the query result is that a matched calling edge with the arguments is found, and the number of calling edges is two or more, it is determined that the processing manner for the second calling edge is discarding.

[0071] In the embodiments of the present disclosure, different processing manners are determined for the second calling edge according to different query results. When the query result is that a matched calling edge with the arguments is found, and the calling edge is a single calling edge, the fields of the callee node of the second calling edge are completed to generate a target calling edge, that is, a calling edge with expected functions, and the target calling edge is stored in the graph database. When the graph database is queried subsequently, the query result is more accurate.

[0072] In some embodiments, since there may be a third calling edge with the callee node of the second calling edge as a starting point in the function calling graph, when the third calling edge is traversed, since the callee node of the third calling edge and the callee node of the second calling edge belong to the same type of function, the third calling edge is determined as an intra-service calling edge. Since the final result of the traversal is to analyze the calling relationship of the code library, rather than the calling relationship inside the inter-service calling, in order to reduce the interference result when the graph database is queried subsequently, all calling edges with the callee node of the second calling edge as a starting point need to be removed.

[0073] As a possible implementation manner, after all the calling edges included in the function calling graph are traversed, the subtree with the callee node of the second calling edge as a starting point is removed in the graph database.

[0074] As another possible implementation, after traversing all the call edges included in the function call graph, the third call edge starting from the callee node of the second call edge is cut off in the graph database, so that the internal call of the third call edge is unreachable.

[0075] As another possible implementation, after determining the second call edge, the subtree starting from the second call edge is immediately pruned in the function call graph.

[0076] In the embodiments of the present disclosure, in order to reduce the interference with the results when querying the graph database later, all the call edges starting from the callee node of the second call edge are pruned, so that the query results obtained when querying the graph database later are more accurate.

[0077] Based on any of the above embodiments, the plurality of functions serving as the starting points of static pointer analysis include the main functions and / or the non-main functions, and each static pointer analysis starting point corresponds to a main function or a non-main function.

[0078] The embodiments of the present disclosure make the function call graph generated by setting the non-main function as the starting point of static pointer analysis more comprehensive compared to the function call graph generated by setting only the main function as the starting point of static analysis, and improve the analysis coverage of the analyzed program.

[0079] Based on the same concept, the embodiments of the present disclosure also provide a device for analyzing function call relationships under a microservice architecture.

[0080] It can be understood that the device for analyzing function call relationships under a microservice architecture provided by the embodiments of the present disclosure includes hardware structures and / or software modules corresponding to the execution of each function in order to achieve the above functions. In combination with the units and algorithm steps of each example disclosed in the embodiments of the present disclosure, the embodiments of the present disclosure can be realized in the form of hardware or a combination of hardware and computer software. Whether a certain function is executed by hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the technical solutions of the embodiments of the present disclosure.

[0081] As an example implementation, Figure 5 is a block diagram of a device for analyzing function call relationships under a microservice architecture according to an example implementation of the present disclosure. Referring to Figure 5 As shown, the device 500 includes an acquisition module 501, an analysis module 502, and a processing module 503.

[0082] The acquisition module 501 is configured to acquire a plurality of functions as starting points of static pointer analysis.

[0083] The analysis module 502 is configured to perform static program analysis on the target code library according to the static pointer analysis starting point, and generate a function call graph according to an analysis result, the function call graph including a plurality of call edges determined based on the static pointer analysis starting point, the call edges being used to represent function call relationships of function calls performed by the static pointer analysis starting point as a caller node.

[0084] The processing module 503 is configured to traverse the plurality of call edges included in the function call graph to obtain a target call edge stored in the graph database.

[0085] In an embodiment, the processing module 503 is specifically configured to traverse the plurality of call edges included in the function call graph, determine a call type of each call edge in the plurality of call edges, and determine a first call edge with the call type of intra-service call; determine the target call edge based on the first call edge, and store the target call edge in the graph database.

[0086] In an embodiment, the processing module 503 is specifically further configured to filter, in the first call edge, a first call edge meeting a preset requirement as the target call edge.

[0087] In an embodiment, the processing module 503 is further configured to determine a second call edge with the call type of inter-service call and a callee node corresponding to the second call edge, and store the second call edge in the graph database if the callee node is a preset node.

[0088] In an embodiment, the apparatus further includes an extraction module 504 and a query module 505. The extraction module 504 is configured to extract an actual parameter of the second call edge if the callee node is not the preset node, the actual parameter including a service name and a function name.

[0089] The query module 505 is configured to query whether there is a call edge with a matching actual parameter in the graph database, and determine a processing manner for the second call edge based on a query result, the processing manner including discarding or storing in the graph database.

[0090] In an embodiment, the query module 505 is configured to determine the processing manner for the second call edge as discarding if the query result is that there is no call edge with the matching actual parameter; generate a target call edge based on the call edge with the matching actual parameter and the second call edge, and store the target call edge in the graph database if the query result is that there is the call edge with the matching actual parameter and the number of the call edges is one; and determine the processing manner for the second call edge as discarding if the query result is that there is the call edge with the matching actual parameter and the number of the call edges is two or more.

[0091] In an implementation, the processing module 503 is further configured to: discard, in the graph database, a sub-tree starting from a callee node of the second call edge; or cut, in the graph database, a third call edge starting from the callee node of the second call edge; or discard, in the function call graph, a sub-tree starting from the second call edge.

[0092] In an implementation, the plurality of functions include a main function and / or a non-main function.

[0093] As to the apparatus related above in the disclosure, the specific manners in which various modules perform operations have been described in detail in the embodiments related to the method, and thus will not be described in detail here.

[0094] In the technical solutions of the disclosure, the acquisition, storage and application of user personal information involved are in line with relevant laws and regulations and do not violate public order and good customs.

[0095] According to the embodiments of the disclosure, the disclosure further provides an electronic device, a readable storage medium and a computer program product.

[0096] Figure 6 A schematic block diagram of an example electronic device 600 that can be used to implement embodiments of the disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptops, desktops, tablets, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular telephones, smart phones, wearable devices, and other similar computing devices. The components shown here, their connections and relationships, and their functions, are meant to be examples only, and are not meant to limit implementations of the present disclosure described and / or claimed in this document.

[0097] As shown in Figure 6 The electronic device 600 includes a computing unit 601 that can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 602 or a computer program loaded from a storage unit 608 into a random access memory (RAM) 603. Various programs and data required for the operation of the electronic device 600 can also be stored in the RAM 603. The computing unit 601, the ROM 602, and the RAM 603 are connected to each other through a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0098] A plurality of components in the device 600 are connected to the I / O interface 605, including: an input unit 606, such as a keyboard, a mouse, etc.; an output unit 607, such as various types of displays, speakers, etc.; a storage unit 608, such as a magnetic disk, an optical disk, etc.; and a communication unit 609, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 609 allows the device 600 to exchange information / data with other devices through a computer network, such as the Internet, and / or various telecommunication networks.

[0099] The computing unit 601 can be various general and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 601 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller, microcontroller, etc. The computing unit 601 performs various methods and processes described above, such as the method of analyzing function call relationships under a microservices architecture. For example, in some embodiments, the method of analyzing function call relationships under a microservices architecture can be implemented as a computer software program, which is tangibly embodied in a machine-readable medium, such as the storage unit 608. In some embodiments, part or all of the computer program can be loaded and / or installed onto the device 600 via the ROM 602 and / or the communication unit 609. When the computer program is loaded onto the RAM 603 and executed by the computing unit 601, one or more steps of the method of analyzing function call relationships under a microservices architecture described above can be performed. Alternatively, in other embodiments, the computing unit 601 can be configured to perform the method of analyzing function call relationships under a microservices architecture by any other appropriate means, such as by means of firmware.

[0100] Various implementations of the systems and techniques described above can be realized in digital electronic circuitry, integrated circuitry, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a system on a chip (SOC), a programmable logic device (CPLD), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include implementation in one or more computer programs that are executable and / or interpretable on a programmable system including at least one programmable processor, which can be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.

[0101] Program code for carrying out methods of the present disclosure can be written in any combination of one or more programming languages. The program code can be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the program code, when executed by the processor or controller, produces the functions / operations specified in the flowcharts and / or block diagrams. The program code can be executed entirely on a machine, partially on a machine, partially on a machine as a standalone software package, or entirely on a remote machine or server.

[0102] In the context of the present disclosure, a machine-readable medium can be a tangible medium that contains or stores a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can include but is not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the machine-readable storage medium will include one or more lines of electrical connections, portable computer disks, hard disk drives, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or Flash memory), optical fibers, portable compact disc read-only memories (CD-ROMs), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0103] To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form, including acoustic, speech, or tactile input.

[0104] The systems and techniques described here can be implemented in a computing system that includes a back end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front end component (e.g., a user computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back end, middleware, or front end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (LAN), a wide area network (WAN), and the Internet.

[0105] The computer system can include clients and servers. This relationship can be. The servers are typically remote from the clients with the interactions between them occurring over a communication network. The relationship between a client and a server is one of client-server. The server can be a cloud server, a server of a distributed system, or a server incorporating a blockchain.

[0106] It should be understood that the steps shown in the various forms above can be reordered, added to, or deleted from. For example, the steps recited in the present disclosure can be performed in parallel, in series, or in a different order, as long as the desired results of the technology disclosed in the present disclosure are achieved, which is not limited herein.

[0107] The specific embodiments described above are not intended to be limiting. One of skill in the art will understand that various modifications, combinations, sub-combinations, and alternatives can be made to the specific embodiments described above without departing from the spirit and principles of this disclosure. Any further modifications, changes, or improvements that come within the spirit and principles of the disclosure are intended to fall within the scope of the disclosure.

Claims

1. A method for analyzing function call relationships in a microservice architecture, comprising: Multiple functions are used as the starting point for static pointer analysis; Static program analysis is performed on the target code library based on the static pointer analysis starting point, and a function call graph is generated based on the analysis results. The function call graph includes multiple call edges determined based on the static pointer analysis starting point. The call edges are used to represent the function call relationship in which the function call is performed with the static pointer analysis starting point as the caller node. Traverse the multiple call edges included in the function call graph to obtain the target call edges stored in the graph database; The target call edge includes at least one of the following: The first call edge that meets the preset requirements among the multiple call edges included in the function call graph is a call edge whose call type is an intra-service call; The call edge generated based on the second call edge included in the function call graph, wherein the second call edge is a call edge whose call type is inter-service call.

2. The method according to claim 1, wherein, The process of traversing the multiple call edges included in the function call graph to obtain the target call edge stored in the graph database includes: Traverse the multiple call edges included in the function call graph and determine the call type of each of the multiple call edges; The target calling edge is determined based on the first calling edge, and the target calling edge is stored in the graph database.

3. The method according to claim 2, further comprising: Identify the second calling edge whose call type is inter-service call, and the callee node corresponding to the second calling edge; If the called node is a preset node, then the second calling edge is stored in the graph database.

4. The method according to claim 3, further comprising: If the called node is not a preset node, then the actual parameters of the second calling edge are extracted, including the service name and the function name; The system queries whether a call edge matching the actual parameter exists in the graph database, and determines the processing method for the second call edge based on the query result. The processing method includes discarding or storing it in the graph database.

5. The method according to claim 4, wherein, The step of determining the processing method for the second calling edge based on the query results includes: If the query result is that no matching call edge is found, then the processing method for the second call edge is determined to be discard. If the query result finds a call edge that matches the actual parameter, and the call edge is a single call edge, then based on the call edge that matches the actual parameter and the second call edge, a target call edge is generated and stored in the graph database; If the query result shows that there are two or more call edges that match the actual parameter, then the processing method for the second call edge is determined to be discard.

6. The method according to claim 3, further comprising: Remove the subtree originating from the callee node of the second calling edge from the graph database; or In the graph database, the third calling edge, originating from the callee node of the second calling edge, is cut off; or Remove the subtree that originates from the second call edge in the function call graph.

7. The method according to claim 3, wherein, The plurality of functions includes the main function and / or non-main functions.

8. An apparatus for analyzing function call relationships in a microservice architecture, comprising: The acquisition module is used to acquire multiple functions as the starting point for static pointer analysis. The analysis module is used to perform static program analysis on the target code library based on the static pointer analysis starting point, and generate a function call graph based on the analysis results. The function call graph includes multiple call edges determined based on the static pointer analysis starting point, and the call edges are used to represent the function call relationship in which the function call is performed with the static pointer analysis starting point as the caller node. The processing module is used to traverse multiple call edges included in the function call graph and obtain the target call edge stored in the graph database; The target call edge includes at least one of the following: The first call edge that meets the preset requirements among the multiple call edges included in the function call graph is a call edge whose call type is an intra-service call; The call edge generated based on the second call edge included in the function call graph, wherein the second call edge is a call edge whose call type is inter-service call.

9. The apparatus according to claim 8, wherein, The processing module is specifically used to traverse the multiple call edges included in the function call graph, determine the call type of each call edge among the multiple call edges, determine the target call edge based on the first call edge, and store the target call edge in the graph database.

10. The apparatus according to claim 9, The processing module is further configured to determine a second calling edge whose calling type is an inter-service call, and the callee node corresponding to the second calling edge; if the callee node is a preset node, the second calling edge is stored in the graph database.

11. The apparatus according to claim 10, further comprising an extraction module and a query module; The extraction module is used to extract the actual parameters of the second calling edge if the called node is not a preset node. The actual parameters include the service name and the function name. The query module is used to query whether there is a call edge matching the actual parameter in the graph database, and to determine the processing method for the second call edge based on the query result. The processing method includes discarding or storing it in the graph database.

12. The apparatus according to claim 11, wherein, The query module is configured to: if the query result indicates that no matching edge for the actual parameter is found, then determine that the processing method for the second call edge is to discard it; if the query result indicates that a matching edge for the actual parameter is found, and the call edge is a single call edge, then generate a target call edge based on the matching edge for the actual parameter and the second call edge, and store it in the graph database; if the query result indicates that a matching edge for the actual parameter is found, and the number of call edges is two or more, then determine that the processing method for the second call edge is to discard it.

13. The apparatus according to claim 10, characterized in that, The processing module is further configured to remove subtrees originating from the callee node of the second calling edge in the graph database; or to cut off the third calling edge originating from the callee node of the second calling edge in the graph database; or to remove subtrees originating from the second calling edge in the function call graph.

14. The apparatus according to claim 10, wherein, The plurality of functions includes the main function and / or non-main functions.

15. An electronic device comprising: 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 to enable the at least one processor to perform the method of any one of claims 1-7.

16. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-7.

17. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-7.

Images