Cross-service call graph construction method for Java micro-service framework

Abstract

The invention discloses a Java micro-service framework-oriented cross-service call graph construction method, which comprises the following steps of: S1, processing a to-be-detected target program and a related configuration file to obtain a result IR for static analysis; s2, performing pointing analysis on the IR generated in the step S1, and generating a pointing flow graph and a preliminary calling graph in the single micro-service; s3, in combination with a configuration file and a code annotation related to service communication in the target program, through remote procedure call (RPC) and message-based communication (MBC) API semantics provided by a modeling micro-service framework, communicating directional flow diagrams and call diagrams of a plurality of micro-services; and S4, on the basis of analysis results of the steps S2 and S3, constructing a complete cross-service call graph. Compared with a traditional Java application-oriented call graph construction method, the method has the advantages that a service communication mechanism of the micro-service framework is modeled, so that a cross-service communication path is analyzed, a complete cross-service call graph is effectively constructed, and basic support is provided for tasks such as dependency analysis and security detection of the micro-service framework.

Description

Technical Field

[0001] The present invention relates to a method for constructing a cross-service call graph for a Java microservice framework, belonging to the technical field of static analysis of microservice frameworks. Background Art

[0002] The microservice architecture is widely used in current Java enterprise applications. By decomposing traditional monolithic applications into loosely coupled distributed small services, the scalability and flexibility of software are improved. In a microservice framework, the interaction between logical modules that was originally achieved through in-process method calls is now realized through cross-process communication methods such as remote procedure call (RPC) and message-based communication (MBC). This brings challenges to understanding the dependencies between services and constructing a cross-service call graph.

[0003] For a Java microservice framework, traditional call graph construction mainly falls into two methods: dynamic tracing and static analysis. Distributed call chain tracing is an important dynamic analysis technique. This technique first instruments all services to collect call information, then records the actual calls that occur during the service operation, and finally constructs a service call graph by analyzing the call logs. Although dynamic analysis has high accuracy, it requires the service to actually run to collect data and may miss unexecuted call paths. For static analysis, call graph construction techniques based on pointer analysis are usually adopted. Pointer analysis is responsible for analyzing the data dependencies and propagation relationships within a service, and the call graph represents the possible calls between statements and methods within a service. However, the current static analysis cannot understand the service communication mechanism of the microservice framework and cannot construct a call graph that connects multiple services, resulting in the inability to effectively analyze cross-service call relationships. Summary of the Invention

[0004] Object of the Invention: Aiming at the problems and deficiencies in the prior art, the present invention provides a method for constructing a cross-service call graph for a Java microservice framework. By modeling the service communication mechanism of the microservice framework and analyzing the call dependencies between services, the purpose of constructing a cross-service call graph is achieved.

[0005] Technical Solution: A method for constructing a cross-service call graph for a Java microservice framework, the method comprising the following steps: S1. Process the target program and configuration file to be detected to obtain the result IR for static analysis; S2. Perform pointer analysis on the IR generated in step S1 to generate a pointer flow graph (PFG) and a preliminary call graph (CG) within a single microservice; S3. Combine the configuration files and code annotations related to service communication in the target program code, and model the service communication API semantics provided by the microservice framework for remote procedure calls (RPC) and message-based communication (MBC) between microservices, and connect the pointing flow graphs and call graphs of multiple microservices; S4. Based on the analysis results of steps S2 and S3, construct a complete cross-service call graph.

[0006] Preferably, in step S1 for processing the target program and configuration file to be detected, it specifically includes: S11. Process the Java source code or bytecode of the target program, and use the open-source framework Tai-e to obtain the three-address code IR; S12. Process the configuration files related to microservices, including application configuration files, service registration and discovery configuration files, and message queue configuration files, and use file reading and parsing to obtain configuration parameters such as application names and service registration information; S13. Process the annotation information related to the framework, including service annotations, endpoint annotations, dependency injection annotations, etc., and use IR reading and parsing to obtain semantic information such as the declarations and dependencies of components within the service, and the component call relationships between services.

[0007] Preferably, in the pointing analysis in step S2, it specifically includes: S21. For the part related to user code in the IR, use the traditional statement-oriented pointing analysis method to construct the pointing flow graph and preliminary call graph within the service; S22. For the dependency injection annotations and Web endpoint annotations in the IR, analyze in combination with the relevant configuration files to improve the pointing flow graph and call graph within the service; S23. For the part related to other framework code in the IR, use the existing modeling method or traditional pointing analysis method to further improve the pointing flow graph and call graph.

[0008] Preferably, in the analysis of dependency injection annotations in step S22, it specifically includes: S221. Scan the annotations for creating DI objects, including @Bean annotation methods and annotation classes such as @Service; S222. Analyze the process of creating DI objects, and store the created objects in the DI container for management; S223. Scan and identify the injection points that need to inject DI objects, including fields and parameters marked with annotations such as @Autowired; S224. Select appropriate objects from the DI container according to type matching, and establish the pointing relationship between the injection points and the objects.

[0009] Preferably, in the step S3, for the modeling of the inter-service communication mechanism, it specifically includes: S31. For the RPC communication mechanism, identify the dependencies between services from the configuration file and program annotations, analyze the mapping rules between the RPC client proxy and the server interface, and construct the call relationship between services and the directed graph of parameter passing; S32. For the MBC communication mechanism, identify the configuration information of the message exchanger (Exchange), queue (Queue), and binding (Binding) from the configuration file and program annotations, analyze the publish-subscribe relationship of messages, and construct the message passing relationship between services and the directed graph of parameter passing.

[0010] Preferably, in the step S31, for the modeling of the RPC communication mechanism, it specifically includes: S311. Model the creation of the RPC client proxy. According to annotation information such as @FeignClient and application configurations, identify the correspondence between the RPC interface and the target service, and construct the pointing relationship for the client proxy object; S312. Model the RPC method call. Analyze the annotation information such as @RequestMapping of the RPC interface method, establish the mapping relationship between the parameters of the calling method and the parameters with the @RequestParam annotation in the server controller method, and construct the edge of the directed graph of parameter passing from the caller to the callee; S313. Model the return value of the RPC method. Analyze the return value variable of the server controller method, and construct the edge of the directed graph of return value passing from the callee to the caller.

[0011] Preferably, in the step S32, for the modeling of the MBC communication mechanism, it specifically includes: S321. Model the message exchanger and message queue. According to the @Bean annotation method in the @Configuration annotation class, analyze the creation of the message exchanger (Exchange) and queue (Queue) and their Binding relationship, and construct the message routing relationship; S322. Model the message publishing. Analyze the call of message sending APIs such as RabbitTemplate, and construct the message passing edge from the sender to the Exchange according to the name of the message exchanger, routing key, and message body type; S323. Model the message subscription. Analyze the annotation information such as @RabbitListener, and construct the message passing edge from the Exchange to the Queue according to the queue name and message body type. S324. Model the message routing. According to the routing rules configured in the Binding, construct a message transfer edge between the Queue and the subscriber, thereby connecting the message publisher and the subscriber.

[0012] Preferably, in step S4 of constructing the cross-service call graph, it specifically includes: S41. Merge the method call graphs within each microservice to construct a basic call structure; S42. According to the RPC analysis result, add synchronous call edges between services; S43. According to the MBC analysis result, add asynchronous call edges between services; S44. Construct and optimize the end-to-end complete call link.

[0013] Beneficial effects: Compared with the existing technical solutions, the present invention has the following advantages: 1) The present invention provides a pointing analysis method for a Java microservice framework. By modeling the service communication mechanism, this method can construct a pointing flow graph that connects multiple services.

[0014] 2) The present invention provides a graph construction method for cross-service calls. Based on the pointing analysis, this method can analyze the call dependency relationship between services, thereby constructing a complete cross-service call graph.

[0015] 3) The pointing analysis and call graph construction methods proposed by the present invention are also applicable to analyzing other framework characteristics related to service communication. Description of the Drawings

[0016] Figure 1 is the flowchart of the method in the embodiment of the present invention. Detailed Embodiments

[0017] The following further clarifies the present invention in conjunction with specific embodiments. It should be understood that these embodiments are only used to illustrate the present invention and not to limit the scope of the present invention. After reading the present invention, various equivalent modifications made by those skilled in the art to the present invention all fall within the scope defined by the appended claims of this application.

[0018] As Figure 1 shown, the cross-service call graph construction method for a Java microservice framework includes the following steps: S1. Process the target program and configuration file to be detected to obtain the result IR for static analysis; In the process of processing the target program code to be detected, the open-source framework Tai-e is used to process the target program code to obtain the three-address code IR for static analysis. At the same time, the configuration files related to microservices are processed to parse configuration parameters such as application names and service registration information, and various framework-related annotation information is processed to parse and obtain the semantic information of the annotations from the IR.

[0019] S2. Perform a points-to analysis on the IR generated in step S1 to generate a points-to flow graph and a preliminary call graph within a single microservice; S21. For the part related to user code in the IR, use the traditional statement-oriented points-to analysis method to construct a points-to flow graph and a preliminary call graph within the service.

[0020] S22. For the framework code related to dependency injection and Web endpoint configuration in the IR, analyze it in combination with the relevant configuration files to improve the points-to flow graph and call graph within the service.

[0021] S23. For the part related to other framework code in the IR, use existing modeling methods or traditional points-to analysis methods to further improve the points-to flow graph and call graph.

[0022] S3. Combine the configuration files and code annotations related to service communication in the target program code, and model the semantics of the service communication API provided by the microservice framework for remote procedure calls (RPC) and message-based communication (MBC) between microservices, and connect the points-to flow graphs and call graphs of multiple microservices; Since the present invention belongs to a static analysis method for a Java microservice framework, the specific implementation method will be introduced below in combination with Java code examples. The example code shows the call relationships between three microservices. App1 calls App2 through RPC, and App2 calls App3 through MBC.

[0023] Line 1, / / application.name: App1 Line 2, @Service class App1Service { Line 3, @Autowired App2Client c; / / points to o7 Line 4, void main() { Line 5, c.foo("user", "password"); Line 6,} Line 7,} Line 8, @FeignClient("App2") interface App2Client { / / o7 Line 9, @GetMapping(" / app2 / foo") String foo( Line 10, @RequestParam String a1, @RequestParam String a2); Line 11,} Line 12, / / application.name: App2 Line 13, @Controller class App2Controller { Line 14, @Autowired RabbitTemplate rt; Line 15, @GetMapping(" / app2 / foo") void foo( Line 16, @RequestParam("a1") String b1, Line 17, @RequestParam("a2") String b2) { Line 18, User u = new User(b1, b2); / / o17 Line 19, rt.convertAndSend("e1", "user.hello", u); Line 20,} Line 21,} Line 22, / / application.name: App3 Line 23, @Configuration class App3Config { Line 24, @Bean Exchange e1() { Line 25, return new TopicExchange("e1"); Line 26,} Line 27, @Bean Queue q1() { Line 28, return new Queue("q1"); Line 29,} Line 30, @Bean Binding b1(Exchange e1, Queue q1) { Line 31, return new Binding(q1.getName(), QUEUE, Line 32, e1.getName(), "user.*", null); Line 33,} Line 34,} Line 35, @Service class App3Service { Line 36, @RabbitListener(queues="q1") void hello(User user) { Line 37, System.out.println(user.getPassword()); Line 38,} Line 39,} Regarding the example code, the analysis of the framework code related to dependency injection in step S22: S221. Scan and create annotations for DI objects. The analyzer identifies the @Service annotation class App1Service in App1, the @Controller annotation class App2Controller in App2, the @Service annotation class App3Service and the @Configuration annotation class App3Config in App3.

[0024] S222. Analyze the creation process of DI objects. For the @Bean methods in the @Configuration class, the analyzer analyzes the e1(), q1(), and b1() methods to create Exchange, Queue, and Binding objects. For other @Service and @Controller annotation classes, the analyzer creates corresponding service objects for them.

[0025] S223. Scan and identify the injection points that need to inject DI objects. The analyzer identifies the @Autowired field c in App1Service, the @Autowired field rt in App2Controller, and the @Bean parameters e1 and q1 of the b1 method in App3Config.

[0026] S224. Establish the pointing relationship between the injection points and the objects. The analyzer injects the App2Client proxy object into the c field of App1Service, injects the RabbitTemplate object into the rt field of App2Controller, and injects the Exchange object e1 and the Queue object q1 into the b1 method parameters of App3Config according to type matching.

[0027] For the example code, the modeling of the RPC communication mechanism in step S31: S311. Create the RPC client proxy model. The analyzer identifies the @FeignClient("App2") annotation of the App2Client interface and constructs an RPC proxy object pointing to the App2 service.

[0028] S312. Model the RPC method call. The analyzer establishes a method call mapping based on the @GetMapping(" / app2 / foo") annotation of the foo method in the App2Client interface and the corresponding annotation of the foo method in the App2Controller class. At the same time, based on the @RequestParam annotation, it establishes the transfer relationship between the parameters "user" and "password" and b1 and b2.

[0029] For the example code, the modeling of the MBC communication mechanism in step S32: S321. Model the message exchange and message queue. The analyzer processes the @Bean method in App3Config, creates an Exchange object named "e1" and a Queue object named "q1", and establishes a routing relationship between them according to the Binding configuration. The routing key pattern is "user.*".

[0030] S322. Model the message publishing. The analyzer processes the rt.convertAndSend("e1", "user.hello", u) call in App2Controller and constructs a message transfer edge from the o17 object to the Exchange "e1" according to the parameters.

[0031] S323. Model the message subscription. The analyzer identifies the @RabbitListener(queues="q1") annotation of the hello method in App3Service and establishes a message transfer edge from the Exchange "e1" to the Queue "q1".

[0032] S324. Model the message routing. Since the routing key "user.hello" of the message matches the "user.*" pattern configured in the Binding, the analyzer establishes a message transfer edge between the Queue "q1" and the parameter user of the hello method, thus connecting the message sending of App2 and the message receiving of App3.

[0033] For the example code, the construction of the cross-service call graph in step S4: S41. The analyzer first constructs the method call graphs within each service, including the call from the main method in App1 to c.foo(), the call to the foo method in App2, and the call to the hello method in App3.

[0034] S42. Based on the RPC analysis results, add cross-service call edges from c.foo() in App1 to the foo method in App2.

[0035] S43. Based on the MBC analysis results, add cross-service asynchronous call edges from rt.convertAndSend() in App2 to the hello method in App3.

[0036] S44. Finally, construct the complete call chain: App1.main() → App1.c.foo() → App2.foo() → App2.rt.convertAndSend() → App3.hello().

[0037] Obviously, those skilled in the art should understand that the steps of the method of the embodiments of the present invention described above can be implemented by a general-purpose computing device. They can be concentrated on a single computing device or distributed on a network composed of multiple computing devices. Optionally, they can be implemented by program code executable by the computing device. Thus, they can be stored in a storage device and executed by the computing device. And in some cases, the steps shown or described can be executed in a different order than here, or they can be separately fabricated into individual integrated circuit modules, or multiple modules or steps among them can be fabricated into a single integrated circuit module for implementation. In this way, the embodiments of the present invention are not limited to any specific combination of hardware and software.

Claims

1. A cross-service call graph construction method for a Java microservice framework, characterized in that: The following steps are involved: S1, process the target program to be detected and related configuration files to obtain the result IR for static analysis; S2. Perform directional analysis on the IR generated in step S1 to generate a directional flow graph and a preliminary call graph within a single microservice; S3. Combine the configuration files and code annotations related to service communication in the target program, and connect the pointing flow graph and call graph of multiple microservices by modeling the API semantics of remote procedure call (RPC) and message-based communication (MBC) provided by the microservice framework; S4. Based on the analysis results of steps S2 and S3, a complete cross-service call graph is constructed.

2. The cross-service call graph construction method for a Java microservice framework according to claim 1 is characterized in that: The step S1 specifically includes: S11, processing the Java source code or bytecode of the target program, and using the open source framework Tai-e to obtain the three-address code IR; S12. Process microservice-related configuration files, including application configuration files, service registration and discovery configuration files, and message queue configuration files; S13. Processing framework-related annotation information, including service annotations, endpoint annotations, dependency injection annotations, etc., using IR reading and parsing to obtain declarations and dependencies of components within the service, and component call relationships between services.

3. The cross-service call graph construction method for a Java microservice framework according to claim 1 is characterized in that: The pointing analysis in step S2 specifically includes: S21. For the part of IR related to user code, the traditional statement-oriented pointing analysis method is used to build the pointing flow graph and preliminary call graph inside the service; S22. Analyze the dependency injection and Web endpoint annotations in the IR in combination with the relevant configuration files to improve the pointing flow graph and call graph within the service; S23. For the parts of IR related to other framework codes, use existing modeling methods or traditional pointing analysis methods to further improve the pointing flow graph and call graph.

4. The cross-service call graph construction method for a Java microservice framework according to claim 3 is characterized in that: The dependency annotation analysis in step S22 specifically includes: S221, scan the annotations for creating DI objects, including @Bean annotated methods and @Service annotated classes; S222, analyzing the DI object creation process, and storing the created object in the DI container for management; S223, scan and identify the injection points where DI objects need to be injected, including fields and parameters marked with annotations such as @Autowired; S224. Select a suitable object from the DI container based on type matching, and establish a pointing relationship between the injection point and the object.

5. The cross-service call graph construction method for a Java microservice framework according to claim 1, characterized in that: The modeling of the RPC communication mechanism in step S3 specifically includes: S311, modeling the creation of RPC client proxy, identifying the correspondence between RPC interface and target service according to @FeignClient and other annotation information and application configuration, and building a pointing relationship for the client proxy object; S312, modeling RPC method calls, analyzing annotation information such as @RequestMapping of the RPC interface method, establishing a mapping relationship between the parameters of the calling method and the parameters with @RequestParam annotations in the server-side controller method, and constructing a flow graph edge pointing to parameter transfer from the caller to the callee; S313, modeling the RPC method return value, analyzing the return value variable of the server-side controller method, and constructing the flow graph edge pointing to the return value transfer from the callee to the caller.

6. The cross-service call graph construction method for a Java microservice framework according to claim 1, characterized in that: The modeling of the MBC communication mechanism in step S3 specifically includes: S321. Modeling message exchanges and message queues. According to the @Bean annotation method in the @Configuration annotation class, analyze the creation of Exchange and Queue and the Binding relationship between them, and build message routing relationships. S322, modeling message publishing, analyzing the calls of message sending APIs such as RabbitTemplate, and building the message delivery edge from the sender to the Exchange based on the exchange name, routing key, and message body type of the message; S323, modeling message subscription, analyzing annotation information such as @RabbitListener, and building a message delivery edge from Exchange to Queue based on the queue name and message body type; S324. Model message routing. According to the routing rules configured by Binding, build a message transmission edge between the Queue and the subscriber, thereby connecting the message publisher and the subscriber.

7. The cross-service call graph construction method for a Java microservice framework according to claim 1, characterized in that: The step S4 constructs a cross-service call graph, specifically including: S41. Merge the method call graphs within each microservice to build a basic call structure. S42. Add a synchronous call edge between services according to the RPC analysis result. S43. Adding asynchronous call edges between services according to the MBC analysis results; S44. Build and optimize a complete end-to-end call chain.

Images