CN115344305A

CN115344305A - Method and device for analyzing function call relation under micro-service architecture

Info

Publication number: CN115344305A
Application number: CN202210917970.2A
Authority: CN
Inventors: 张国昊; 马晓刚
Original assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Current assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Priority date: 2022-08-01
Filing date: 2022-08-01
Publication date: 2022-11-15

Abstract

The invention provides a method and a device for analyzing a function call relation under a micro-service architecture, relates to the technical field of computers, and particularly relates to the field of static program analysis. The specific implementation scheme is as follows: acquiring a plurality of functions as static pointer analysis starting points; performing static program analysis on the target code library according to the static pointer analysis starting point, and generating a function call graph according to an analysis result, wherein the function call graph comprises a plurality of call edges determined based on the static pointer analysis starting point, and the call edges are used for representing a function call relation for performing function call by taking the static pointer analysis starting point as a caller node; and traversing a plurality of calling edges included in the function calling graph to obtain a target calling edge stored in the graph database.

Description

Method and device for analyzing function call relation under micro-service architecture

Technical Field

The present disclosure relates to the field of computer technology, and more particularly, to the field of static program analysis.

Background

Static program analysis (Static program analysis) refers to a method of analyzing semantics and behavior of code without actually executing a program. With the rapid development of Go language in recent years, the static program analysis technology is widely applied to Go function call relation, code specification inspection and the like.

However, currently, existing static program analysis tools generally only support a main function as a pointer analysis starting point, and for some programs (such as HTTP Server) that depend on a dynamic call processing request, static analysis that uses a main function as a pointer analysis starting point may lose a large amount of function call relation analysis results due to the unreachable problem of a dynamic call edge.

Disclosure of Invention

The disclosure provides a method and a device for analyzing a function call relation under a micro-service architecture.

According to an aspect of the present disclosure, there is provided a method for analyzing a function call relationship under a microservice architecture, including: acquiring a plurality of functions as the starting points of static pointer analysis; performing static program analysis on a target code library according to the static pointer analysis starting point, and generating a function call graph according to an analysis result, wherein the function call graph comprises a plurality of call edges determined based on the static pointer analysis starting point, and the call edges are used for representing a function call relation for performing function call by taking the static pointer analysis starting point as a caller node; and traversing a plurality of calling edges included in the function calling graph to obtain a target calling edge stored in the graph database.

According to another aspect of the present disclosure, there is provided an apparatus for analyzing function call relations under a microservice architecture, including: the acquisition module is used for acquiring a plurality of functions as the starting points of static pointer analysis; the analysis module is used for performing static program analysis on the target code library according to the static pointer analysis starting point and generating a function call graph according to an analysis result, wherein the function call graph comprises a plurality of call edges determined based on the static pointer analysis starting point, and the call edges are used for representing a function call relation for performing function call by taking the static pointer analysis starting point as a caller node; and the processing module is used for traversing a plurality of calling edges included in the function calling graph to obtain a target calling edge stored in the graph database.

According to another aspect of the present disclosure, there is provided an electronic device including: at least one processor; and a memory communicatively coupled to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method described above.

According to another aspect of the present disclosure, there is provided a non-transitory computer readable storage medium having stored thereon computer instructions for causing the computer to perform the above-described method.

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.

The method for analyzing the function call relation under the micro-service architecture can acquire more comprehensive function call relation, generate more comprehensive function call graph, and obtain more accurate analysis result based on the function call graph.

It should be understood that the statements in this section do not necessarily identify key or critical features of the embodiments of the present disclosure, nor do they limit the scope of the present disclosure. Other features of the present disclosure will become apparent from the following description.

Drawings

The drawings are included to provide a better understanding of the present solution and are not to be construed as limiting the present disclosure. Wherein:

FIG. 1 is a flowchart of a method for analyzing a function call relationship in a microservice architecture according to an embodiment of the present disclosure;

FIG. 2 is a flow chart of another method for analyzing function call relationships in a microservice architecture according to an embodiment of the present disclosure;

FIG. 3 is a flowchart of a method for analyzing a function call relationship under a microservice architecture according to another embodiment of the disclosure;

FIG. 4 is a flowchart of a method for analyzing a function call relationship under a microservice architecture according to an embodiment of the present disclosure;

FIG. 5 is a block diagram of an apparatus for analyzing function call relationships in a microservice architecture according to an embodiment of the present disclosure;

FIG. 6 is a block diagram of an electronic device for implementing a method of analyzing function call relationships under a microservice architecture in accordance with an embodiment of the present disclosure.

Detailed Description

Exemplary embodiments of the present disclosure are described below with reference to the accompanying drawings, in which various details of the embodiments of the disclosure are included to assist understanding, and which are to be considered as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the disclosure. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.

Static program analysis (Static program analysis) refers to a method of analyzing semantics and behavior of code without actually executing a program. With the rapid reversal of Go language in recent years, the static program analysis technology is widely applied to Go function call relation, code specification examination and the like. However, currently existing static program analysis tools usually only support the function funcmain () as the starting point of pointer analysis, and for some programs (such as HTTP Server) that depend on dynamic call processing requests, the static analysis that uses the function funcmain () as the starting point of pointer analysis may lose a large amount of function call relation analysis results due to the unreachable problem of dynamic call edges. On the other hand, the existing static program analysis tool cannot analyze the cross-service call relation in the HTTP Server-based micro-service architecture, which causes inaccurate results of part of function call relations.

For example, the Go official module golden. Org/x/tools implements the Andersen's pointer analysis algorithm, providing basic function call graph generation capability. However, the Go official library only supports the use of the func init () and func main () in the package main as the starting point of the pointer analysis, which is fatal to the program that exists Web Server and depends on the dynamic call processing request, because this means that the static program analysis is not reachable, and a large amount of analysis results are necessarily lost.

For a specific example, to avoid over-inflation of the router configuration, the Web Server in Go language will often use reflect to establish dynamic routing, and for static program analysis, if only funcmain () can be specified as the starting point, the function under controller is unreachable.

Based on this, the embodiment of the present disclosure provides a method for analyzing a function call relationship under a microservice architecture, which performs static program analysis on a target code library by using a plurality of functions as static pointer analysis starting points, and can obtain a more comprehensive function call relationship to generate a more comprehensive function call graph, thereby obtaining an analysis result of the comprehensive function call relationship based on the function call graph.

FIG. 1 is a flowchart of a method for analyzing function call relationships in a microservice architecture, according to an exemplary embodiment of the disclosure, the method comprising the steps of:

in step S101, a plurality of functions are acquired as static pointer analysis starting points.

And the static pointer analysis starting point is used for starting from the static pointer analysis starting point and analyzing the function call relation in the code library when the code library is subjected to static program analysis.

Optionally, the user may configure a plurality of functions in a user-defined manner as the static pointer analysis starting points, the plurality of functions are transmitted to the official repository through modifying the official repository, and when the analysis program is initialized, the configuration defined by the user is read from the official repository, so that the static pointer analysis starting points of the code repositories are obtained.

Specifically, the pointers. Config module is used for managing analysis starting points of each code library, and before an official library is not modified, the pointers. Config module defaults to transmit a main packet of ssa.package type, acquires func main () and func init () from the main packet and converts the func main () and the func init () into a CGnode, and then starts to execute static program analysis.

In the embodiment of the disclosure, by modifying the official library, fields are newly added in the pointer. Config module, a self-defined non-main function can be transmitted as a starting point, and the self-defined non-main function can be any named function. When static program analysis is needed, reading the configuration of the self-defined non-main function, and converting the self-defined non-main function and the init function corresponding to the page into the CGNode which is used as a static pointer analysis starting point.

In step S102, a static program analysis is performed on the target code library according to the static pointer analysis starting point, and a function call graph is generated according to the analysis result.

The nodes in the function call relationship diagram are the set of all functions in the program, and the edges in the diagram are also called call edges and represent the call relationship between the functions. If the calling relation exists between the functions, the nodes are connected through a directed arc, and the directed arc points to the callee node from the caller node. If a ring exists in the call relation graph, the recursive call exists in the program.

In the embodiment of the disclosure, the function call graph includes a plurality of call edges determined based on the static pointer analysis starting point, and the call edges are used for characterizing a function call relation of a function call with the static pointer analysis starting point as a caller node.

Illustratively, the static pointer analysis starting points of the target code library are 3, which are a main function, a C function and an F function respectively, the function call relationship of the target code library obtained through static program analysis is main- > a- > B, C- > D and F- > I, then main- > a- > B represents a call edge determined by using the main function as the static pointer analysis starting point, the main function is a caller node (caller), the B function is a callee node (caller), and similarly, C- > D and F- > I represent call edges determined by using the C function and the F function as the static pointer analysis starting points, the C function and the F function are caller nodes, and the D function and the I function are callee nodes respectively.

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

Optionally, the caller node and the caller node of each of the plurality of call edges are converted into normalized data beneficial to operation and storage, and then the plurality of call edges are traversed, so as to reduce traversal time.

According to the method and the device for analyzing the static pointer, the multiple functions are obtained to serve as the static pointer analysis starting points, the function call graph generated by static program analysis on the target code library based on the static pointer analysis starting points can reflect the function call relation in the target code library more comprehensively, and therefore the target call graph stored in the graph database based on the function call graph is more comprehensive and accurate.

Fig. 2 is a schematic flowchart of a method for traversing multiple call edges included in a function call graph to obtain a target call edge stored in a graph database according to an embodiment of the present disclosure, and referring to fig. 2, the method includes the following steps.

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

Wherein the call type comprises an intra-service call or an inter-service call.

Optionally, the in-service call indicates that the caller node and the callee node belong to a function in the same module, that is, the service names of the caller node and the callee node are the same. The inter-service call represents 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.

Illustratively, user information and a user nickname are stored in a user module, user authority is stored in a perm module, when user information needs to be obtained, the user nickname needs to be obtained first, corresponding user information is searched according to the user nickname, and at the moment, the calling relationship is that the user module- > the user module belongs to the same module, namely, calling in service. When a user needs to obtain the user right, a nickname of the user needs to be obtained first, the corresponding user right is searched according to the nickname of the user, and at the moment, the calling relation is perm module-user module, and the perm module-user module belongs to different modules, namely, calling between services.

Optionally, when traversing a plurality of call edges included in the function call graph, determining a call type of each call edge based on a user-defined function rule.

In step S202, the call type is determined as the first call edge of the intra-service call.

In step S203, a target calling edge is determined based on the first calling edge, and the target calling edge is stored in the graph database.

Optionally, when the target calling edge is written into the graph database, the target calling edge is automatically deduplicated according to data already stored in the graph database, and if the target calling edge already exists in the graph database, the target calling edge is not stored in the graph database.

In the embodiment of the disclosure, each calling edge in the function call graph is analyzed based on the function call graph, and whether the calling edge belongs to in-service calling or between-service calling can be analyzed.

Furthermore, the first calling edges meeting the preset requirements are screened from the first calling edges to serve as target calling edges. And if the first calling edge does not meet the preset requirement, discarding the first calling edge which does not meet the requirement.

In the embodiment of the disclosure, the first calling edges are screened, and the calling edges which do not meet the requirement are discarded, so that the calling edges stored in the graph database are more accurate.

FIG. 3 is a flow diagram illustrating a method for traversing multiple call edges included in a function call graph to obtain a target call edge stored in a graph database according to the present disclosure, and referring to FIG. 3, the method includes the following steps.

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

In step S302, the call type is determined as a second call edge of the inter-service call and a callee node corresponding to the second call edge.

Optionally, after determining that the call type of the second call edge is inter-service call, the second call edge is stripped from the function call graph, serialized, and stored in the global temporary file according to the row sequence.

Each piece of serialized data contains basic information of the caller node and the callee node in the second calling side, such as service _ name, package _ name, receiver _ name, and function _ name.

In step S303, if the callee node is a preset node, the second calling edge is stored in the graph database.

In the embodiment of the disclosure, by determining that the call type is the second call edge of the inter-service call, and determining whether the called node of the second call edge is a preset node, if the called node is the preset node, it indicates that the second call edge can call a function which is actually required, and therefore, the second call edge is directly stored in the graph database, so that the call edges stored in the graph database are all accurate call edges which meet the functional requirements.

In some embodiments, assume that there are two independent services, user and perm, corresponding to module hello/world/perm and module hello/world/user, respectively, and a function in perm service calls a function in user through inter-service call. The calling edge directly obtained by static program analysis is: [ perm ] [ demo ] [ ] [ GetUserInfo ] - > [ perm ] [ demo ] [ ] [ RemoteCall ]; and the actual expected calling edges are: [ perm ] [ demo ] [ ] [ GetUserInfo ] - > [ user ] [ ] [ GetUserName ]. Although the result obtained by static program analysis conforms to the Go language semantics, the result does not conform to the expectation of the function, so that the special case needs to be processed, and the result obtained by analysis actually expects. This particular case will be explained below, as shown in fig. 4, comprising the following steps.

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

In step S402, it is determined that the call type is a second call edge of the inter-service call and a callee node corresponding to the second call edge.

In step S403, if the callee node is not the preset node, the real parameters of the second calling edge are extracted.

The argument includes a service name service _ name and a function name function _ name.

Specifically, if the second calling edge is stored in the global temporary file, deserializing a text line in the global temporary file to obtain function information of the callee node, finding a function corresponding to the callee node from the AST of the file in which the callee node is located, extracting real parameters from a fixed parameter position, and obtaining the service _ name and the function _ name.

Alternatively, the AST may be generated from each source code file and stored in a global variable after the function call graph is generated.

It should be noted that all extracted parameters in the embodiments of the present disclosure are transmitted through string literal quantity.

In step S404, it is queried whether there is a calling edge matching the argument in the graph database, and a processing manner for the second calling edge is determined based on the query result.

Wherein the processing mode comprises discarding or storing to a graph database.

In the embodiment of the disclosure, whether the second calling edge is matched with the database is judged by extracting the actual parameters of the second calling edge, and different processing modes are performed on the second calling edge based on different query results, so that the calling edges finally stored in the database are all the calling edges which are in line with expectation and accuracy.

As a possible implementation, if the query result is that there is no match found from the query. And if the real parameter calling edge is determined, the processing mode of the second calling edge is determined to be discarding.

As another possible implementation manner, if the query result is that a calling edge with matching real parameters is queried and the calling edge is a single calling edge, a target calling edge is generated based on the calling edge and the second calling edge with matching real parameters and is stored in the graph database.

Optionally, the packet field and the receiver field of the caller node of the second calling edge are completed based on the calling edge matched with the actual parameters, and a target calling edge is generated.

As another possible implementation manner, if the query result is that a calling edge with a matching argument exists in the query, and the number of the calling edges is two or more, it is determined that the processing manner for the second calling edge is discarding.

In the embodiment of the disclosure, different processing modes for the second calling edge are determined according to different query results, when the query result is that a calling edge with matching parameters exists in the query, and the calling edge is a single calling edge, the field of the callee node of the second calling edge is completed, so that a target calling edge, namely a calling edge with a function meeting expected requirements, is generated, and is stored in the graph database, and when the graph database is searched subsequently, the search result is more accurate.

In some embodiments, a third calling edge may exist in the function call graph, where the third calling edge uses the callee node of the second calling edge as a starting point, and 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 in-service call, and since a final result of the traversal is to analyze a call relation of the code base, rather than call an internal call relation between services, in order to reduce an interference result when a graph database is subsequently queried, all calling edges using the callee node of the second calling edge as a starting point need to be removed.

As a possible implementation manner, after all the calling edges included in the function call graph are traversed, a sub-tree with a callee node of the second calling edge as a starting point is eliminated from the graph database.

As another possible implementation, after all the call edges included in the function call graph are traversed, a third call edge starting from a 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 not reachable.

As yet another possible implementation, immediately after the second calling edge is determined, a subtree starting from the second calling edge is culled in the function call graph.

In the embodiment of the disclosure, in order to reduce interference results when the graph database is subsequently queried, all calling edges with the callee node of the second calling edge as a starting point are eliminated, so that query results obtained when the graph database is subsequently queried are more accurate.

According to any of the above embodiments, the plurality of functions as the starting points of the static pointer analysis include a main function and/or a non-main function, and each starting point of the static pointer analysis corresponds to one main function or non-main function.

The non-main function is also set as the static pointer analysis starting point, so that compared with a function call graph generated only by taking the main function as the static analysis starting point, the analysis coverage of the analyzed program is improved.

Based on the same conception, the embodiment of the disclosure also provides a device for analyzing the function call relation under the micro-service architecture.

It is to be understood that, in order to implement the above functions, the apparatus for analyzing function call relationships in a microservice architecture provided by the embodiments of the present disclosure includes a hardware structure and/or a software module corresponding to executing each function. The disclosed embodiments can be implemented in hardware or a combination of hardware and computer software, in combination with the exemplary elements and algorithm steps disclosed in the disclosed embodiments. Whether a function is performed as hardware or computer software drives hardware depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.

As an exemplary embodiment, fig. 5 is a block diagram of an apparatus for analyzing function call relationships in a microservice architecture according to an exemplary embodiment shown in the present disclosure. Referring to fig. 5, the apparatus 500 includes an obtaining module 501, an analyzing module 502, and a processing module 503.

An obtaining module 501, configured to obtain multiple functions as starting points of static pointer analysis;

an analysis module 502, 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, where 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 a function call relationship in which the static pointer analysis starting point is used as a caller node to perform function call;

the processing module 503 is configured to traverse multiple calling edges included in the function call graph to obtain a target calling edge stored in the graph database.

In an embodiment, the processing module 503 is specifically configured to traverse a plurality of call edges included in the function call graph, and determine a call type of each call edge in the plurality of call edges, where the call type includes an intra-service call or an inter-service call; determining the calling type as a first calling edge called in the service; and determining a target calling side based on the first calling side, and storing the target calling side to the graph database.

In an embodiment, the processing module 503 is specifically configured to filter the first calling edge that meets the preset requirement from the first calling edge as a target calling edge.

In an embodiment, the processing module 503 is further configured to determine that the call type is a second call edge of the inter-service call, and a callee node corresponding to the second call edge; and if the called node is a preset node, storing the second calling edge into the graph database.

In an embodiment, the apparatus further includes an extracting module 504 and a querying module 505, where the extracting module 504 is configured to extract an actual parameter of the second calling edge if the callee node is not a preset node, where the actual parameter includes a service name and a function name;

and the query module 505 is configured to query whether a calling edge matching the argument exists in the graph database, and determine a processing manner for the second calling edge based on a query result, where the processing manner includes discarding or storing to the graph database.

In an embodiment, the query module 505 is configured to determine that a processing manner of the second call edge is discarded if the query result indicates that no call edge with matching arguments exists; if the query result is that the calling edge with the matched actual parameters is queried and the calling edge is a single calling edge, generating a target calling edge based on the calling edge with the matched actual parameters and a second calling edge, and storing the target calling edge in a graph database; and if the query result is that the calling edges with the matching parameters exist and the number of the calling edges is two or more, determining that the processing mode of the second calling edge is discarded.

In one embodiment, the processing module 503 is further configured to cull a sub-tree in the graph database, where the sub-tree starts from a callee node of the second calling edge; or cutting off a third calling edge taking the callee node of the second calling edge as a starting point in the graph database; or a subtree with the second calling edge as the starting point is eliminated from the function calling graph.

In one embodiment, the plurality of functions includes a primary function and/or a non-primary function.

The specific manner in which the various modules perform operations has been described in detail in relation to the apparatus of the present disclosure above, and will not be elaborated upon here.

In the technical scheme of the disclosure, the acquisition, storage, application and the like of the personal information of the related user all accord with the regulations of related laws and regulations, and do not violate the good customs of the public order.

The present disclosure also provides an electronic device, a readable storage medium, and a computer program product according to embodiments of the present disclosure.

FIG. 6 illustrates a schematic block diagram of an example electronic device 600 that can be used to implement embodiments of the present disclosure. Electronic devices are intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The electronic device may also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions, are meant to be examples only, and are not meant to limit implementations of the disclosure described and/or claimed herein.

As shown in fig. 6, the apparatus 600 includes a computing unit 601, which 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. In the RAM603, various programs and data required for the operation of the device 600 can also be stored. The calculation unit 601, the ROM602, and the RAM603 are connected to each other via a bus 604. An input/output (I/O) interface 605 is also connected to bus 604.

A number 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, and the like; an output unit 607 such as various types of displays, speakers, and the like; a storage unit 608, such as a magnetic disk, optical disk, or the like; and a communication unit 609 such as a network card, modem, wireless communication transceiver, etc. The communication unit 609 allows the device 600 to exchange information/data with other devices via a computer network such as the internet and/or various telecommunication networks.

The computing unit 601 may be a variety of general and/or special purpose processing components having 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 dedicated Artificial Intelligence (AI) computing chips, various computing units running machine learning model algorithms, a Digital Signal Processor (DSP), and any suitable processor, controller, microcontroller, and so forth. The computing unit 601 performs the various methods and processes described above, such as methods that analyze function call relationships under a microservice architecture. For example, in some embodiments, the method of analyzing function call relationships under a microservice architecture may be implemented as a computer software program tangibly embodied in a machine-readable medium, such as storage unit 608. In some embodiments, part or all of the computer program may be loaded and/or installed onto the device 600 via the ROM602 and/or the communication unit 609. When the computer program is loaded into RAM603 and executed by computing unit 601, one or more steps of the above described method of analyzing function call relationships in a microservice architecture may be performed. Alternatively, in other embodiments, the computing unit 601 may be configured by any other suitable means (e.g., by means of firmware) to perform a method of analyzing function call relationships under a microservice architecture.

Various implementations of the systems and techniques described here above may be implemented in digital electronic circuitry, integrated circuitry, field Programmable Gate Arrays (FPGAs), application Specific Integrated Circuits (ASICs), application Specific Standard Products (ASSPs), system on a chip (SOCs), load programmable logic devices (CPLDs), computer hardware, firmware, software, and/or combinations thereof. These various embodiments may include: implemented in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, receiving data and instructions from, and transmitting data and instructions to, a storage system, at least one input device, and at least one output device.

Program code for implementing the methods of the present disclosure may be written in any combination of one or more programming languages. These program code may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program code, when executed by the processor or controller, causes the functions/acts specified in the flowchart and/or block diagram to be performed. The program code may execute entirely on the machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

In the context of this disclosure, a machine-readable medium may be a tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium may 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 a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

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 a user; and a keyboard and a pointing device (e.g., a mouse or a trackball) by which a user may provide input to the computer. Other kinds of devices may also be used to provide for interaction with a user; 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 may be received in any form, including acoustic, speech, or tactile input.

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: local Area Networks (LANs), wide Area Networks (WANs), and the Internet.

The computer system may include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. The server may be a cloud server, a server of a distributed system, or a server combining a blockchain.

It should be understood that various forms of the flows shown above may be used, with steps reordered, added, or deleted. For example, the steps described in the present disclosure may be executed in parallel, sequentially, or in different orders, as long as the desired results of the technical solutions disclosed in the present disclosure can be achieved, and the present disclosure is not limited herein.

The above detailed description should not be construed as limiting the scope of the disclosure. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may be made, depending on design requirements and other factors. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present disclosure should be included in the scope of protection of the present disclosure.

Claims

1. A method for analyzing function call relations under a micro service architecture comprises the following steps:

acquiring a plurality of functions as the starting points of static pointer analysis;

performing static program analysis on a target code library according to the static pointer analysis starting point, and generating a function call graph according to an analysis result, wherein the function call graph comprises a plurality of call edges determined based on the static pointer analysis starting point, and the call edges are used for representing a function call relation for performing function call by taking the static pointer analysis starting point as a caller node;

and traversing a plurality of calling edges included in the function calling graph to obtain a target calling edge stored in the graph database.

2. The method of claim 1, wherein traversing the plurality of call edges included in the function call graph to obtain a target call edge stored in a graph database comprises:

traversing a plurality of calling edges included in the function calling graph, and determining the calling type of each calling edge in the plurality of calling edges, wherein the calling type comprises in-service calling or inter-service calling;

determining the calling type as a first calling edge called in the service;

and determining a target calling side based on the first calling side, and storing the target calling side to a graph database.

3. The method of claim 2, wherein the determining a target invocation edge based on the first invocation edge comprises:

and screening the first calling edges meeting the preset requirement from the first calling edges to be used as target calling edges.

4. The method of claim 2, further comprising:

determining a second calling edge with a calling type as an inter-service call and a callee node corresponding to the second calling edge;

and if the callee node is a preset node, storing the second calling edge into the graph database.

5. The method of claim 4, further comprising:

if the called node is not a preset node, extracting the actual parameters of the second calling edge, wherein the actual parameters comprise a service name and a function name;

and querying whether the graph database has a calling edge matched with the actual parameters or not, and determining a processing mode of the second calling edge based on a query result, wherein the processing mode comprises discarding or storing to the graph database.

6. The method of claim 5, wherein the determining a manner of processing the second invocation edge based on the query result comprises:

if the query result indicates that the calling edge matched with the actual parameter does not exist in the query result, determining that the processing mode of the second calling edge is discarded;

if the query result is that a calling edge matched with the real parameters exists in the query and the calling edge is a single calling edge, generating a target calling edge based on the calling edge matched with the real parameters and the second calling edge, and storing the target calling edge in the graph database;

and if the query result is that two or more calling edges matched with the actual parameters exist in the query, determining that the processing mode of the second calling edge is discarded.

7. The method of claim 4, further comprising:

removing subtrees taking callee nodes of the second calling edge as starting points from the graph database; or alternatively

Cutting off a third calling edge taking a called node of the second calling edge as a starting point in the graph database; or

And eliminating a subtree taking the second calling edge as a starting point in the function calling graph.

8. The method of claim 4, wherein the plurality of functions comprise a master function and/or a non-master function.

9. An apparatus for analyzing function call relationships under a microservice architecture, comprising:

the acquisition module is used for acquiring a plurality of functions as the starting points of static pointer analysis;

the analysis module is used for performing static program analysis on the target code library according to the static pointer analysis starting point and generating a function call graph according to an analysis result, wherein the function call graph comprises a plurality of call edges determined based on the static pointer analysis starting point, and the call edges are used for representing a function call relation for performing function call by taking the static pointer analysis starting point as a caller node;

and the processing module is used for traversing a plurality of calling edges included in the function calling graph to obtain a target calling edge stored in the graph database.

10. The apparatus of claim 9, wherein,

the processing module is specifically configured to traverse a plurality of call edges included in the function call graph, and determine a call type of each call edge in the plurality of call edges, where the call type includes intra-service call or inter-service call; determining the calling type as a first calling edge called in the service; and determining a target calling side based on the first calling side, and storing the target calling side to a graph database.

11. The apparatus of claim 10, wherein,

the processing module is specifically further configured to filter the first calling edges that meet preset requirements, as target calling edges, from the first calling edges.

12. The apparatus of claim 10, wherein the first and second electrodes are disposed on opposite sides of the substrate,

the processing module is further configured to determine that a call type is a second call edge called between services, and a callee node corresponding to the second call edge; and if the callee node is a preset node, storing the second calling edge into the graph database.

13. The apparatus of claim 12, further comprising an extraction module and a query module;

the extracting module is configured to extract the parameters of the second calling edge if the callee node is not a preset node, where the parameters include a service name and a function name;

the query module is used for querying whether the graph database has a calling edge matched with the actual parameters or not, and determining a processing mode of the second calling edge based on a query result, wherein the processing mode comprises discarding or storing to the graph database.

14. The apparatus of claim 13, wherein,

the query module is used for determining that the processing mode of the second calling edge is discarded if the query result indicates that the calling edge matched with the real parameter does not exist in the query; if the query result is that a calling edge matched with the real parameters exists in the query and the calling edge is a single calling edge, generating a target calling edge based on the calling edge matched with the real parameters and the second calling edge, and storing the target calling edge in the graph database; and if the query result indicates that the calling edges matched with the real parameters exist in the query and the number of the calling edges is two or more, determining that the processing mode of the second calling edge is discarded.

15. The apparatus of claim 12,

the processing module is further configured to remove a subtree with a callee node of the second calling edge as a starting point from the graph database; or cutting off a third calling edge taking a called node of the second calling edge as a starting point in the graph database; or eliminating a subtree taking the second calling edge as a starting point in the function calling graph.

16. The apparatus of claim 12, wherein the plurality of functions comprise a master function and/or a non-master function.

17. An electronic device, comprising:

at least one processor; and

a memory communicatively coupled to the at least one processor; wherein, the first and the second end of the pipe are connected with each other,

the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-8.

18. A non-transitory computer readable storage medium having stored thereon computer instructions for causing the computer to perform the method of any one of claims 1-8.

19. A computer program product comprising a computer program which, when executed by a processor, implements the method according to any one of claims 1-8.