Microservice dependency link static analysis method and system based on syntax analysis tree

Abstract

The present invention discloses a static analysis method and system for microservice dependency links based on a syntax analysis tree, comprising: performing coding conventions on microservice calls; converting a current microservice source code file into a syntax analysis tree object; obtaining a class definition object according to the syntax analysis tree object, obtaining a class declaration object array according to the class definition object, traversing the declaration object array, and obtaining a method declaration object; obtaining a method declaration source code according to the method declaration object, and retrieving a microservice call method defined in the convention in the method declaration source code; judging whether the microservice name called in the microservice call method meets the convention requirements, and locating an abnormal dependency link according to the judgment result. The calling process of the microservice module is uniformly coded and conventioned, so as to locate the abnormal dependency relationship between the microservice modules and improve the quality of project management.

Description

Technical Field

[0001] The present invention relates to the technical field of computer microservice distributed systems, and in particular to a method and system for statically analyzing microservice dependency links based on a grammar analysis tree. Background Art

[0002] The statements in this section merely provide background information related to the present invention and do not necessarily constitute prior art.

[0003] The microservice architecture model divides the traditional single application into a group of independent, small service modules. The service modules coordinate and cooperate with each other, and the services collaborate with each other using lightweight communication mechanisms (usually RESTful APIs based on the HTTP protocol). As the complexity of system business requirements increases, the call chain dependencies between services in the distributed service architecture become more complex.

[0004] In order to realize link tracking collection, Google published a distributed link tracking paper "Dapper, a Large-Scale Distributed Systems Tracing Infrastructure". Subsequently, Google released the distributed link tracking system Dapper, and proposed a distributed link data dynamic analysis and collection technology based on Google-Dapper, which can build a microservice link tracking data model and identify the call dependency relationship between microservices; however, the current microservice link tracking dynamic analysis technology solution based on Dapper still faces the following shortcomings: 1) It is impossible to obtain the call dependency information between microservice modules in real time during the system development phase. 2) The completeness and accuracy of the obtained call link information are low. 3) The time and labor cost of obtaining the call link information are high. 4) The obtained call link information has a lag for developers, testers, and operation and maintenance personnel, affecting the efficiency of development, testing, and operation and maintenance.

[0005] Therefore, an improved or completely new distributed link tracking and analysis technology is needed, which can obtain the call link dependency data between each microservice module in real time before the system is deployed online, that is, the microservice link static analysis technology. Chinese patent CN112948137A discloses a microservice association analysis and prediction method, which applies the association analysis technology to the microservice call dependency analysis, and derives and calculates the link dependency relationship between microservice modules through a complex and rigorous mathematical model. After the system is developed and before the online deployment test, the system can be subjected to a comprehensive static analysis, thereby obtaining the dependency relationship between each microservice module, which solves some of the shortcomings of the microservice link dynamic analysis technology based on Google-Dapper, but it still has the following problems:

[0006] 1) The conclusion of direct association of microservices based on regular expression matching may be inaccurate and incomplete. In this type of technical solution, the source code is statically scanned, and regular expression matching technology is used through predetermined code patterns to extract and identify the direct association between microservices. For example, the pattern specified in the above invention is: {protocol}[separator]{associated service name}[separator]{service operation}[separator]. As long as the above pattern is met, it is considered that the current microservice has a direct dependency on the microservice at the position of "{associated service name}". This analysis and processing method will lead to inaccurate or incomplete analysis and processing conclusions when encountering the following situations, specifically:

[0007] A. There are some temporary comment code blocks in the code, and the comment code blocks happen to contain call codes to other microservices that meet the above pattern. The identified dependency on the microservice may not actually exist, and the identified dependent service may depend on other services. In this way, the dependency graph between the microservices of the entire system that is finally identified may be completely abnormal and lose its value.

[0008] B. There are some code blocks in the code that meet the above pattern but may not be microservice calls, such as some URL addresses pointing to third parties, which also meet the above pattern, but obviously do not belong to the call dependency between microservice modules within the system.

[0009] C. The developer's call to the microservice module in the code does not follow the preset regular expression pattern. For example, the URL is generated by dynamically splicing variables, so it cannot be correctly identified according to the above pattern, resulting in the possibility that some dependencies between the microservices of the entire system identified by this type of technology are missing.

[0010] 2) No technical guarantee solution is given, and it is completely dependent on the developer's initiative, which has high management costs and technical risks. This type of method is based on regular expression matching to extract the direct association of microservices. It requires developers to follow the following relevant conventions for coding to ensure the correctness and comprehensiveness of the final collected microservice link dependency data:

[0011] A. For some microservice calls that may not be needed temporarily, be sure to delete them directly instead of temporarily commenting the code.

[0012] B. Use static constants to declare the call URL of the microservice, and do not use variable splicing. In actual project experience, it is unrealistic to rely entirely on developers to consciously abide by certain development rules. Generally, code walkthroughs or other automated monitoring tools are needed to assist and ensure this, which will undoubtedly increase communication and management costs.

[0013] 3) The computational logic is complex and time-consuming. This microservice link static analysis technology based on association analysis requires a large number of vector and similarity calculations, and requires the establishment of an association knowledge base, which has a high computational logic and time complexity. Summary of the invention

[0014] In order to solve the above problems, the present invention proposes a microservice dependency link static analysis method and system based on a syntax analysis tree, which performs unified coding specifications on the calling process of the microservice module, thereby locating the abnormal dependency relationship between the microservice modules and improving the quality of project management.

[0015] In order to achieve the above object, the present invention adopts the following technical solution:

[0016] In a first aspect, the present invention provides a microservice dependency link static analysis method based on a grammar analysis tree, comprising:

[0017] Encode microservice calls;

[0018] Convert the current microservice source code file into a syntax analysis tree object;

[0019] Obtain a class definition object according to the syntax analysis tree object, obtain a class declaration object array according to the class definition object, traverse the declaration object array, and obtain a method declaration object;

[0020] Obtain the method declaration source code according to the method declaration object, and search the microservice call method defined in the specification in the method declaration source code;

[0021] Determine whether the name of the microservice called in the microservice calling method meets the specification requirements, and locate the abnormal dependency link based on the judgment result.

[0022] As an optional implementation method, a unified API specification is implemented for microservice calls. The process of unified API specification includes: independently designing the name of the called microservice as a separate parameter, and standardizing the format and value of the parameter; automatically setting the AMSToken request header and the corresponding token value in the http request header, and dynamically constructing the http request object according to the http method type.

[0023] As an optional implementation method, the obtained microservice call request is intercepted and verified using aspect tracking according to the protocol, including: parsing the http message header from the microservice call request, determining whether the microservice tag in the http message header is consistent with the microservice tag in the protocol, thereby identifying whether the microservice call is a standard protocol call; if it is a non-standard call, intercepting and processing it and issuing an alarm.

[0024] As an optional implementation method, the current microservice source code file is converted into a grammar analysis tree object using a Java grammar analysis tree tool development kit.

[0025] As an optional implementation, the class definition object is a formatted java source code file object; the method declaration source code is a formatted method declaration source code with comment codes removed.

[0026] As an optional implementation, the specification includes an enumeration class specification, and determines whether the microservice name called in the microservice calling method is a reference to the enumeration class.

[0027] As an optional implementation method, based on the judgment result, if it is a non-standard call, the current microservice name, the current microservice calling method, the code line number, and the exception type are stored in the exception dependency database; if it is a standard call, the corresponding enumeration value is extracted, and the current microservice name, the called microservice name, the microservice calling method, and the code line number are stored in the normal dependency database.

[0028] In a second aspect, the present invention provides a microservice dependency link static analysis system based on a grammar analysis tree, comprising:

[0029] A microservice coding specification module is configured to perform coding specifications on microservice calls;

[0030] A first source code analysis module is configured to convert the current microservice source code file into a syntax analysis tree object;

[0031] A second source code analysis module is configured to obtain a class definition object according to the syntax analysis tree object, obtain a class declaration object array according to the class definition object, traverse the declaration object array, and obtain a method declaration object;

[0032] A third source code analysis module is configured to obtain a method declaration source code according to the method declaration object, and retrieve a microservice call method defined in the specification from the method declaration source code;

[0033] The dependency link alarm module is configured to determine whether the name of the microservice called in the microservice calling method meets the specification requirements, and locate the abnormal dependency link based on the determination result.

[0034] In a third aspect, the present invention provides an electronic device comprising a memory and a processor, and computer instructions stored in the memory and executed on the processor, wherein when the computer instructions are executed by the processor, the method described in the first aspect is performed.

[0035] In a fourth aspect, the present invention provides a computer-readable storage medium for storing computer instructions, wherein when the computer instructions are executed by a processor, the method described in the first aspect is performed.

[0036] Compared with the prior art, the present invention has the following beneficial effects:

[0037] The present invention proposes a microservice dependency link static analysis method and system based on a syntax analysis tree, which realizes the dependency data among all microservice modules of a real-time project during the system development process. By comparing the difference between the dependency relationships of the actually developed microservice modules and the dependency relationships of the initial design, the dependency anomalies are located, and corrective guidance is given to developers in a timely manner or the original design is improved in a timely manner, thereby improving the information management efficiency and level of large-scale complex microservice architecture systems.

[0038] The present invention proposes a microservice dependency link static analysis method and system based on a syntax analysis tree, which can quickly and accurately locate problems such as module abnormal dependency and module circular dependency during the development and testing process, thereby improving development and testing efficiency.

[0039] The present invention proposes a microservice dependency link static analysis method and system based on a syntax analysis tree, which can timely, comprehensively and accurately understand the dependency relationship of the system microservice modules during the operation and maintenance process, provide precise and comprehensive technical support for the operation and maintenance planning and deployment implementation of the microservice modules, and improve the efficiency of deployment and operation and maintenance.

[0040] The present invention proposes a microservice dependency link static analysis method and system based on a syntax analysis tree, which encapsulates the calling process of a microservice module into a unified API, so that developers no longer need to deal with HTTP protocol details when accessing the remote microservice API, and no longer need to deal with network details such as network timeouts and network connection exceptions during remote calls. Developers can call remote microservice modules as simply and efficiently as calling local methods, significantly improving development efficiency and ensuring development quality through unified code encapsulation.

[0041] Advantages of additional aspects of the present invention will be given in part in the following description, and in part will become obvious from the following description, or will be learned through practice of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] The accompanying drawings in the specification, which constitute a part of the present invention, are used to provide a further understanding of the present invention. The exemplary embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute improper limitations on the present invention.

[0043] Figure 1 A microservice call relationship diagram provided in Example 1 of the present invention;

[0044] Figure 2 A schematic diagram of the Dapper dynamic analysis solution provided in Example 1 of the present invention;

[0045] Figure 3A flow chart of a method for statically analyzing microservice dependency links based on a grammar analysis tree provided in Example 1 of the present invention;

[0046] Figure 4 A core class diagram of the development protocol provided in Example 1 of the present invention;

[0047] Figure 5 A flowchart of protocol interception and verification processing provided in Example 1 of the present invention;

[0048] Figure 6 A flowchart of the protocol encapsulation process provided in Example 1 of the present invention;

[0049] Figure 7 Schematic diagram of a microservice dependency link static analysis system based on a grammar analysis tree provided in Example 1 of the present invention. DETAILED DESCRIPTION

[0050] The present invention will be further described below in conjunction with the accompanying drawings and embodiments.

[0051] It should be noted that the following detailed descriptions are exemplary and are intended to provide further explanation of the present invention. Unless otherwise specified, all technical and scientific terms used herein have the same meanings as those commonly understood by those skilled in the art to which the present invention belongs.

[0052] It should be noted that the terms used herein are only for describing specific embodiments, and are not intended to limit exemplary embodiments according to the present invention. As used herein, unless the context clearly indicates otherwise, the singular form is also intended to include the plural form. In addition, it should be understood that the terms "include" and "have" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0053] In the absence of conflict, the embodiments of the present invention and the features of the embodiments may be combined with each other.

[0054] Example 1

[0055] The microservice architecture model divides the traditional single application into a group of independent, small service modules. The service modules coordinate and cooperate with each other, and the services collaborate with each other using lightweight communication mechanisms (usually RESTful APIs based on the HTTP protocol). Each service module is built around the most suitable technology stack for the specific business and can be independently deployed in the production environment. As the business needs of the system become more and more complex, large information systems designed with the microservice architecture may have dozens or even hundreds of microservices in the background to support seemingly simple business scenarios. The more microservices the system is split into, the more complex the call chain dependencies between services under this distributed service architecture become. For example, Figure 1 shown.

[0056] The dependency link information between microservices is very important data for system designers, developers, testers, and operation and maintenance personnel, especially for large and complex distributed systems based on microservice architecture. Designers can use the call dependency link data of service modules to plan the design boundaries between modules, and promptly discover the circular dependency and abnormal dependency problems between modules caused by the design, greatly improving the design efficiency. Developers and testers can use the call dependency link data of service modules to quickly discover and locate code defects caused by dependency anomalies. Operation and maintenance personnel can use the call dependency link data of service modules to reasonably plan the deployment architecture and implementation steps of the system and improve operation and maintenance efficiency.

[0057] In a complex distributed system based on a microservice architecture, the dependency calling relationship between microservice modules has become an important basic data in the system architecture. Therefore, it is of great practical significance to study and analyze the collection mechanism of call dependency data between service modules in a microservice architecture to make the service dependency data collection more comprehensive, accurate and efficient.

[0058] In order to realize link tracking collection, Google published a distributed link tracking paper "Dapper, a Large-Scale Distributed Systems Tracing Infrastructure", and then released the distributed link tracking system Dapper. Up to now, there are many excellent distributed link tracking technologies and products in the industry to track the call link information of microservices, such as SkyWalking, Istio, Zipkin, etc., all inspired by Dapper published by Google. Dapper explains the concept, data representation, tracking, transmission, collection, storage and display of link tracking in distributed systems, especially in microservice architecture, and puts forward the concepts of Trace and Span:

[0059] Trace is a call link, which refers to the path of a front-end request through all back-end microservices. Each link is identified by a globally unique TraceID. Span represents the intermediate service node in the call link. Each Span has a unique identifier SpanID, and there is a parent-child relationship between spans. The upstream span is the parent span of the downstream (identified by ParentID). In this way, each span has two identifiers, SpanID and ParentID, which respectively identify the identifier of the current span and the Span identifier of its parent node. SpanID is unique in a link.

[0060] Dapper uses tracking technology to dynamically generate the structural data of the above data model during service operation, so that each service call link information can be collected, such as Figure 2 As shown in the figure, Dapper can well build a microservice link tracking data model and identify the call dependencies between microservices. However, the current microservice link tracking dynamic analysis technology solution based on Dapper still faces the following shortcomings:

[0061] 1) It is impossible to obtain the call dependency information between microservice modules in real time during the system development stage. The link tracking technology proposed by Google's Dapper is a dynamic link analysis technology, which requires that each module in the microservice system must have been developed and deployed, and each business process must have been successfully run at least once before the link data can be dynamically collected and displayed. Therefore, Google's Dapper and other link tracking technologies and products derived from Dapper extensions are currently unable to obtain the call link information between microservice modules during the system development stage.

[0062] 2) The completeness and accuracy of the acquired call link information are low. Dapper's dynamic link analysis technology is based on dynamic tracking to collect link information. Therefore, this type of technical solution not only requires the entire system to be deployed and run, but also requires the system's business process to be executed at least once completely and correctly before the relevant link data can be collected. This means that if the system process is not fully executed, the collected link dependency data may be incomplete; if some processes cannot run normally due to development defects, then the link dependency data may not be collected or collected inaccurately.

[0063] 3) It takes a lot of time and manpower to obtain call link information. Dapper's dynamic link analysis technology can only obtain the service's call dependency link information after the system is developed, deployed and run. This takes a long time and has a high time cost. In addition, the deployment and testing process of the system requires the cooperation of operation and maintenance and testers, and requires the participation of multiple departments, which increases manpower and communication costs.

[0064] 4) The obtained call link information has a lag for developers, testers, and operation and maintenance personnel, which affects the efficiency of development, testing, and operation and maintenance. Dapper's dynamic link analysis technology can only obtain the call dependency relationship between services after the system is developed, deployed, and tested. This means that developers, testers, and operation and maintenance personnel cannot discover some service dependency issues, such as dependency exceptions, circular dependencies, etc., in the development stage before the system is deployed online. As a result, they cannot discover and avoid problems caused by illegal service dependencies in the first time. They can only capture and solve problems after online deployment, testers conduct testing, or production environment problems are exposed. This lag seriously affects the development, testing, and operation and maintenance efficiency of the system.

[0065] Therefore, a microservice link static analysis technology is proposed, which can obtain the call link dependency data between each microservice module in real time before the system is deployed online. At the same time, combined with the shortcomings of the microservice association analysis and prediction method described in the background technology, this embodiment proposes a microservice dependency link static analysis method based on a grammar analysis tree, such as Figure 3 As shown, including:

[0066] S1: Encode the microservice call;

[0067] S2: Convert the current microservice source code file into a syntax analysis tree object;

[0068] S3: Obtain a class definition object according to the syntax analysis tree object, obtain a class declaration object array according to the class definition object, traverse the declaration object array, and obtain a method declaration object;

[0069] S4: Obtain the method declaration source code according to the method declaration object, and search the microservice call method defined in the specification in the method declaration source code;

[0070] S5: Determine whether the name of the microservice called in the microservice calling method meets the specification requirements, and locate the abnormal dependency link based on the judgment result.

[0071] In this embodiment, step S1 specifically includes uniformly stipulating the development and call access of microservices, and performing point tracking processing on the execution of all microservice backend codes;

[0072] As an optional implementation method, a unified API specification is implemented for the development and calling methods of microservices.

[0073] Furthermore, the format design in the unified API specification includes: independently designing the name of the called microservice as a separate parameter, and standardizing the format and value of the parameter, such as through enumeration class method.

[0074] Furthermore, the encapsulation process in the unified API specification includes: in addition to encapsulating the standard microservice http call request logic, a special token field and the corresponding value are added to the http request header, and the token and value are transparent to the developer, and the developer does not need or need to know the technical details.

[0075] As an optional implementation method, the effective execution of the specification is automatically verified through section tracking, and the call requests that do not meet the specification are intercepted, providing an automated technical solution for the effective execution of the specification.

[0076] Furthermore, the tracking point processing process of the microservice backend includes: before all microservice code logic is executed, the validity of the token field and value of the http request header is checked to ensure that only client requests that meet the service coding specifications will be successfully processed, and requests for microservice access that do not follow the unified API of the coding specifications will be intercepted and processed with alarms, technically ensuring the effective execution of the coding specifications and realizing automated verification of the validity of the microservice coding specifications.

[0077] like Figure 4 In the developed specification framework shown in the figure, according to the differences between the service provider and the caller, the specification framework includes different core classes, specifically BaseController, MSAop, MSEnum, and MSClientTool. BaseController and MSAop belong to the specification classes related to the service provider, and MSEnum and MSClientTool belong to the specification classes related to the service caller.

[0078] Among them, BaseController is the top-level class of all microservice implementation classes, and all microservice classes must inherit from this class;

[0079] MSAop is a microservice implementation class that intercepts and verifies microservice call requests according to the specification. Figure 5 As shown, it specifically includes: intercepting microservice call requests, parsing the http message header from the microservice call request, judging whether the microservice tag in the http message header is consistent with the microservice tag in the specification, so as to identify whether the microservice call is a standard specification call; if it is a non-standard call, the microservice call request is returned as an exception, and the relevant information of the abnormal call is marked, and an alarm is issued. The microservice call that does not comply with the specification requirements is intercepted and marked, and the automatic verification of the development specification is realized.

[0080] This specification class technically guarantees that developers must make unified calls in accordance with the specification framework requirements when developing microservice calls, providing technical support for the effective execution of the specification, improving the code quality of microservice calls, and reducing management costs.

[0081] MSEnum is an enumeration class for all microservices, which records the name, port, and other information of each microservice. When a microservice caller calls other microservices, it must reference this enumeration class to specify the name of the microservice being called.

[0082] MSClientTool is a tool class used by microservice callers to call other microservices. It provides a unified microservice call specification API. The first parameter in the microservice call specification API is the name of the called microservice, which must be referenced from the MSEnum class.

[0083] like Figure 6 The protocol encapsulation processing shown includes: the microservice call protocol API automatically sets the AMSToken request header and the corresponding token value in the http request header, and dynamically constructs the http request object according to the http method type (get / post / put / delete) to mark whether the microservice call request meets the protocol requirements.

[0084] The above development framework specification technically ensures that the developed microservice source code complies with the corresponding design conventions, thereby ensuring the correctness and comprehensiveness of the dependency link data conclusions drawn by the dependency link static analysis method.

[0085] In this embodiment, the syntax analysis tree technology is used to parse the microservice source code project to obtain high-quality method declaration source code; the direct call dependency data between microservices in the source code is extracted, the call requests that do not meet the specifications are automatically identified, and the abnormalities are marked as alarms.

[0086] Specifically, the step S2 includes:

[0087] Load and scan the microservice source code project, parse the service name information of the current microservice according to the code structure of the standard SpringCloudBoot microservice project, and load the URL information of each source code file under the source code project into the in-memory database Redis;

[0088] Traverse the source code file URL collection in the memory database Redis, and use the Java syntax tree tool development kit JDT to convert each source code file into a syntax analysis tree AST object CompilationUnit.

[0089] The step S3 comprises:

[0090] Get the class definition object TypeDeclaration from CompilationUnit, where the class definition object TypeDeclaration is a formatted Java source code file object;

[0091] Get all declaration object arrays of the class bodyDeclarations from TypeDeclaration. The declaration object array contains all attribute declarations and method declarations in the current source code. Since the microservice call occurs in the method declaration object, this embodiment only needs to traverse the bodyDeclarations array and filter out the method declaration object MethodDeclaration.

[0092] The step S4 comprises:

[0093] Get the source code content of the method declaration from the MethodDeclaration object; the method declaration source code is the method declaration source code that has been formatted by JDT and various comment codes have been removed. The formatting process is automatic line breaking for each statement;

[0094] The calling status of the MSClientTool tool method in the specification is retrieved from the method declaration source code. If a call is found, the first parameter in the microservice calling method, that is, the name of the called microservice, is extracted, and the name of the called microservice is judged.

[0095] Furthermore, high-quality method declaration source code removes various comment codes in the original code, so that the comment code does not affect the parsing results. This allows developers to retain any required comment code or instructions according to their own habits and actual project needs, without worrying about the impact of the comment code on the link dependency static analysis results, thereby improving code development efficiency and quality.

[0096] Furthermore, the coding specification API is matched and extracted based on the high-quality method declaration source code to accurately identify the name of the called microservice module, thereby eliminating the inaccurate identification problem that may be caused by the traditional regular expression pattern matching method to extract the microservice name.

[0097] In this embodiment, step S5 includes:

[0098] Verify whether the called microservice name is a reference to the enumeration class MSEnum;

[0099] If it is a non-standard call, the current microservice name, the current calling method name, the code line number, the exception type (the microservice name reference format is illegal), and other information are stored in the exception dependency database (MySql database);

[0100] If it is a standard call, the corresponding enumeration value is extracted as the name information of the called microservice, and the call dependency data such as the current microservice name, the called microservice name, the name of the method declaration, the code line number, etc. are stored in the normal dependency database (MySql database).

[0101] Repeat the above process until all method declaration source codes and all source code files are analyzed.

[0102] In this embodiment, after the source code file is analyzed, all the call dependency data between microservices are merged to obtain the global dependency data between all microservice modules; and the circular dependency problems between modules are automatically identified during the merging process. If a circular dependency call between microservices is found, the situation is automatically marked as a circular dependency exception, and the relevant information is stored in the exception dependency database.

[0103] In this embodiment, the normal dependency data between microservices and the abnormal call alarm data that violates the coding convention are stored, and the merged global dependency data is also stored in the global dependency database (MySql database) to facilitate graphical display by the display module.

[0104] In this embodiment, a graphical representation of the dependency graph between all microservice modules is used, and the circular dependencies therein can be automatically highlighted; the link dependency data alarm and display module can finely classify and display various abnormal data, such as:

[0105] (1) Information such as the abnormal project that does not use the API specified in the coding specification to call the microservice, the class name where the abnormal code is located, and the line number;

[0106] (2) The microservice is called using the API specified in the coding protocol, but the parameter format or content passed in is illegal, including the exception project, the class name where the exception code is located, and the line number;

[0107] (3) The name information of each microservice module that generates circular dependencies. Click each microservice to see the code class and line number information that generates the service dependency.

[0108] In this embodiment, not only is a unified protocol implemented for the way microservices are called, but corresponding technical safeguards are also designed synchronously. In the event that developers intentionally or unintentionally fail to follow the unified protocol and arbitrarily adopt other methods (such as the native httpclient API) to perform call coding for microservice access, it is ensured that the code cannot pass unit and functional testing in the development stage, testing stage, or production stage, thereby reducing the time and labor costs of project management and significantly improving the quality of project management.

[0109] Example 2

[0110] like Figure 7 As shown, this embodiment proposes a microservice dependency link static analysis system based on a syntax analysis tree, including:

[0111] A microservice coding specification module is configured to perform coding specifications on microservice calls;

[0112] A first source code analysis module is configured to convert the current microservice source code file into a syntax analysis tree object;

[0113] A second source code analysis module is configured to obtain a class definition object according to the syntax analysis tree object, obtain a class declaration object array according to the class definition object, traverse the declaration object array, and obtain a method declaration object;

[0114] A third source code analysis module is configured to obtain a method declaration source code according to the method declaration object, and retrieve a microservice call method defined in the specification from the method declaration source code;

[0115] The dependency link alarm module is configured to determine whether the name of the microservice called in the microservice calling method meets the specification requirements, and locate the abnormal dependency link based on the determination result.

[0116] It should be noted that the above modules correspond to the steps described in Example 1, and the examples and application scenarios implemented by the above modules and the corresponding steps are the same, but are not limited to the contents disclosed in the above Example 1. It should be noted that the above modules, as part of the system, can be executed in a computer system such as a set of computer executable instructions.

[0117] In this embodiment, the microservice coding specification module is used to unify the specifications for the development and call access of microservices, and to perform point-of-use processing on the execution of all microservice backend codes;

[0118] Furthermore, a unified API specification is implemented for the development and calling methods of microservices. The effective execution of the specification is automatically verified through aspect tracking, and the call requests that do not meet the specification are intercepted, providing an automated technical solution for the effective execution of the specification.

[0119] Furthermore, the format design in the unified API specification includes independently designing the name of the called microservice as a separate parameter, and standardizing the format and value of the parameter, such as through enumeration class.

[0120] Furthermore, the encapsulation process in the unified API specification includes, in addition to encapsulating the standard microservice http call request logic, adding a special token field and the corresponding value in the http request header, and the token and value are transparent to the developer, and the developer does not need to know the technical details.

[0121] Furthermore, the tracking point processing process of the microservice backend includes, before all microservice code logic is executed, checking the validity of the token field and value of the http request header to ensure that only client requests that meet the service coding specifications will be successfully processed, and requests for microservice access that do not follow the unified API of the coding specifications will be intercepted and processed with alarms, technically ensuring the effective execution of the coding specifications and realizing automated verification of the validity of the microservice coding specifications.

[0122] In this embodiment, the source code analysis module uses a syntax analysis tree to parse the microservice source code project to obtain high-quality method declaration source code; extracts direct call dependency data between microservices in the source code, automatically identifies call requests that do not meet the specifications, and marks the exception as an alarm.

[0123] Furthermore, high-quality method declaration source code removes various comment codes in the original code, so that the comment code does not affect the parsing results, allowing developers to use the code comment function with confidence and improve code development efficiency and quality.

[0124] Furthermore, the coding specification API is matched and extracted based on the high-quality method declaration source code to accurately identify the name of the called microservice module, thereby eliminating the inaccurate identification problem that may be caused by the traditional regular expression pattern matching method to extract the microservice name.

[0125] Furthermore, the extraction process of the called microservice name includes automatically identifying it as an abnormal call and marking it as an alarm when it is found that the microservice name parameter format in the encoding specification API does not meet the specification requirements (not a specified enumeration class reference).

[0126] In this embodiment, the system also includes a data merging processing module, which is used to uniformly merge the direct dependency data between microservices obtained by syntax analysis to obtain global dependency data between all microservice modules; and automatically identify circular dependency problems between modules during the merging process. If a circular dependency between microservices is found, corresponding alarm data is generated.

[0127] In this embodiment, the system further includes a data storage module, which is used to store normal dependency data between microservices analyzed by the source code analysis module and abnormal call alarm data that violates the coding convention, and also stores global dependency data merged by the data merging processing module;

[0128] Furthermore, the data storage module classifies and stores normal direct dependency data, abnormal dependency data, and global dependency tree data of all microservices between microservices, so as to facilitate various data displays.

[0129] In this embodiment, the dependency link alarm module also includes a display process for automatically issuing alarms for abnormal call data, circular dependency data, etc. that violate coding conventions, and graphically displays the dependency graph between all microservice modules, and can automatically highlight the circular dependencies.

[0130] Furthermore, link dependency data alarms and displays can finely classify and display various abnormal data, such as:

[0131] (1) Information such as the abnormal project that does not use the API specified in the coding specification to call the microservice, the class name where the abnormal code is located, and the line number;

[0132] (2) The microservice is called using the API specified in the coding protocol, but the parameter format or content passed in is illegal, including the exception project, the class name where the exception code is located, and the line number;

[0133] (3) The name information of each microservice module that generates circular dependencies. Click each microservice to see the code class and line number information that generates the service dependency.

[0134] In further embodiments, there is also provided:

[0135] An electronic device includes a memory and a processor, and computer instructions stored in the memory and executed on the processor, wherein when the computer instructions are executed by the processor, the method described in Embodiment 1 is performed. For the sake of brevity, it will not be described in detail here.

[0136] It should be understood that in this embodiment, the processor may be a central processing unit CPU, and the processor may also be other general-purpose processors, digital signal processors DSP, application-specific integrated circuits ASIC, off-the-shelf programmable gate arrays FPGA or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.

[0137] The memory may include a read-only memory and a random access memory, and provide instructions and data to the processor. A portion of the memory may also include a non-volatile random access memory. For example, the memory may also store information about the device type.

[0138] A computer-readable storage medium is used to store computer instructions, and when the computer instructions are executed by a processor, the method described in Example 1 is completed.

[0139] The method in Example 1 can be directly embodied as a hardware processor, or a combination of hardware and software modules in the processor. The software module can be located in a mature storage medium in the field such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware. To avoid repetition, it is not described in detail here.

[0140] Those skilled in the art will appreciate that the units, i.e., algorithm steps, of the various examples described in conjunction with this embodiment can be implemented in electronic hardware or in a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0141] Although the above describes the specific implementation mode of the present invention in conjunction with the accompanying drawings, it is not intended to limit the scope of protection of the present invention. Those skilled in the art should understand that various modifications or variations that can be made by those skilled in the art on the basis of the technical solution of the present invention without creative work are still within the scope of protection of the present invention.

Claims

1. A static analysis method for microservice dependency links based on syntax analysis tree, characterized in that: include: Encode microservice calls; The coding specification for microservice calls specifically includes unified specification for the development and call access of microservices, and at the same time, point-of-use processing for the execution of all microservice backend codes; Automatically check the effective execution of the specification through section tracking, intercept the call requests that do not meet the specification, and provide an automated technical solution for the effective execution of the specification; Convert the current microservice source code file into a syntax analysis tree object; Obtain a class definition object according to the syntax analysis tree object, obtain a class declaration object array according to the class definition object, traverse the declaration object array, and obtain a method declaration object; Obtain the method declaration source code according to the method declaration object, and search the microservice call method defined in the specification in the method declaration source code; Determine whether the name of the microservice called in the microservice calling method meets the specification requirements, and locate the abnormal dependency link based on the judgment result.

2. The microservice dependency link static analysis method based on grammar analysis tree according to claim 1, characterized in that: Unify the API specifications for microservice calls. The process of unifying the API specifications includes: independently designing the name of the called microservice as a separate parameter, and standardizing the format and value of the parameter; automatically setting the AMSToken request header and the corresponding token value in the http request header, and dynamically constructing the http request object according to the http method type.

3. The microservice dependency link static analysis method based on grammar analysis tree as claimed in claim 1, characterized in that: According to the specification, the obtained microservice call request is intercepted and verified using the section tracking point, including: parsing the http message header from the microservice call request, determining whether the microservice tag in the http message header is consistent with the microservice tag in the specification, so as to identify whether the microservice call is a standard specification call; if it is a non-standard call, intercept and process it and issue an alarm.

4. The microservice dependency link static analysis method based on grammar analysis tree as claimed in claim 1, characterized in that: The current microservice source code file is converted into a grammar analysis tree object using the Java grammar analysis tree tool development kit.

5. The microservice dependency link static analysis method based on grammar analysis tree according to claim 1, characterized in that: The class definition object is a formatted Java source code file object; the method declaration source code is a formatted method declaration source code with comment codes removed.

6. The microservice dependency link static analysis method based on grammar analysis tree according to claim 1, characterized in that: The specification includes an enumeration class specification, which determines whether the microservice name called in the microservice calling method is a reference to the enumeration class.

7. The microservice dependency link static analysis method based on grammar analysis tree according to claim 1, characterized in that: According to the judgment result, if it is a non-standard call, the current microservice name, current microservice call method, code line number, and exception type are stored in the exception dependency database; If it is a standard call, extract the corresponding enumeration value, and store the current microservice name, the called microservice name, the microservice calling method, and the code line number in the normal dependency database.

8. A microservice dependency link static analysis system based on syntax analysis tree, characterized in that: include: A microservice coding specification module is configured to perform coding specifications on microservice calls; The coding specification for microservice calls specifically includes unified specification for the development and call access of microservices, and at the same time, point-of-use processing for the execution of all microservice backend codes; Automatically check the effective execution of the specification through section tracking, intercept the call requests that do not meet the specification, and provide an automated technical solution for the effective execution of the specification; A first source code analysis module is configured to convert the current microservice source code file into a syntax analysis tree object; A second source code analysis module is configured to obtain a class definition object according to the syntax analysis tree object, obtain a class declaration object array according to the class definition object, traverse the declaration object array, and obtain a method declaration object; A third source code analysis module is configured to obtain a method declaration source code according to the method declaration object, and retrieve a microservice call method defined in the specification from the method declaration source code; The dependency link alarm module is configured to determine whether the name of the microservice called in the microservice calling method meets the specification requirements, and locate the abnormal dependency link based on the determination result.

9. An electronic device, characterized in that: The method comprises a memory and a processor and computer instructions stored in the memory and executed on the processor, wherein when the computer instructions are executed by the processor, the method according to any one of claims 1 to 7 is completed.

10. A computer-readable storage medium, characterized in that: Used to store computer instructions, which, when executed by a processor, complete the method described in any one of claims 1 to 7.

Images