Monomer application migration reconstruction method and device, electronic equipment and storage medium

Abstract

The invention discloses a monomer application migration reconstruction method and device, electronic equipment and a storage medium, and belongs to the technical field of computers.The method comprises the steps that a source code of a target monomer application is obtained; analyzing the source code to obtain a syntax tree, and generating a calling relation topological graph; clustering and gathering classes in the calling relation topological graph according to pre-divided micro-service business types, and generating a micro-service calling relation graph; and distributing and storing source codes of different business types in a micro-service folder database according to a business type classification result in the micro-service calling relation graph, and generating a micro-service architecture corresponding to the target single application. According to the method and the device, the classes in the source code are clustered through the pre-divided micro-service business types, so that the source code can be redistributed according to the business function types without manual operation, the labor and time cost is effectively saved, and the migration and reconstruction efficiency of the single application is improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method, device, electronic device and storage medium for migration and reconstruction of a single application. Background Art

[0002] Currently, with the continuous iteration of monolithic applications using component architecture, the code size and complexity are rapidly expanding, and the number of projects that need to be maintained is large.

[0003] In related technologies, monolithic applications are usually migrated and refactored into microservice architectures. However, in actual applications, it is found that the current microservice transformation method requires manual copying of component codes to be migrated to new projects based on experience. The transformation work will face the problem of extremely large workload and require high manpower and time costs.

[0004] In summary, the technical problems existing in the relevant technologies need to be improved. Summary of the invention

[0005] The embodiments of the present application provide a method, device, electronic device and storage medium for migration and reconstruction of a single application, which can effectively save manpower and time costs and improve the efficiency of migration and reconstruction of a single application.

[0006] On the one hand, an embodiment of the present application provides a method for migration and reconstruction of a single application, comprising the following steps:

[0007] Get the source code of the target monolithic application;

[0008] Parsing the source code to obtain a syntax tree and generating a call relationship topology diagram; wherein the call relationship topology diagram includes at least one call link; each node in the call link is a class;

[0009] According to the pre-divided microservice business types, the classes in the call relationship topology diagram are clustered to generate a microservice call relationship diagram;

[0010] According to the business type classification result in the microservice call relationship diagram, source codes of different business types are distributed and stored in a microservice folder database to generate a microservice architecture corresponding to the target monolithic application.

[0011] Optionally, the parsing of the source code to obtain a syntax tree and generating a call relationship topology diagram includes:

[0012] Traverse and parse each source code file to extract component code and project code;

[0013] Scan the component code and the project code, and generate a syntax tree with the controller layer interface as the root node;

[0014] Calculate the call relationship between each class in the syntax tree to generate a call link;

[0015] The call relationship topology graph is generated according to the call link.

[0016] Optionally, clustering the classes in the generated call relationship topology diagram according to the pre-divided microservice business types to generate the microservice call relationship diagram includes:

[0017] Obtain pre-divided microservice business categories and naming keywords related to the microservice business categories;

[0018] According to the microservice business type and the naming keyword, the call relationship topology diagram is rescanned, and a hierarchical classification identifier is added to each method;

[0019] According to the hierarchical classification identifier, the classes in the call relationship topology diagram are clustered to generate a microservice call relationship diagram.

[0020] Optionally, after distributing and storing source codes of different business types in a microservice folder database according to the business type classification result in the microservice call relationship diagram, and generating a microservice architecture corresponding to the target monolithic application, the method further includes:

[0021] In response to a microservice startup instruction, determining a class in the microservice folder database that is identified as open;

[0022] Determine all public methods in the class marked as open and input parameters and output parameters of the public methods;

[0023] Encapsulate all the public methods and the input parameters and output parameters of the public methods into a packaging class object;

[0024] Record all the packaging class objects and complete the registration.

[0025] Optionally, after encapsulating all the public methods and the input parameters and output parameters of the public methods into packaging class objects, the method further includes:

[0026] Inserting a parameter verification object into the packaging class object;

[0027] Wherein, the parameter verification object includes empty judgment.

[0028] Optionally, after the record completes the registration of all the packaging class objects, the method further includes:

[0029] Determine the interface information that needs to be opened;

[0030] Define all interface information declarations in the configuration class.

[0031] Optionally, after the record completes the registration of all the packaging class objects, the method further includes:

[0032] In response to the microservice call request, obtain the microservice call request;

[0033] Parse and read the calling information and parameter information of the class and method carried in the microservice call request;

[0034] According to the call information and parameter information, determine the corresponding class and execute it, and generate an execution result;

[0035] Send the execution result to the sender of the microservice call request.

[0036] On the other hand, an embodiment of the present application provides a single application migration and reconstruction device, the device comprising:

[0037] Code acquisition module, used to obtain the source code of the target monolithic application;

[0038] A code parsing module, used to parse the source code to obtain a syntax tree and generate a call relationship topology diagram; wherein the call relationship topology diagram includes at least one call link; each node in the call link is a class;

[0039] A clustering module is used to cluster the classes in the call relationship topology diagram according to the pre-divided microservice business types to generate a microservice call relationship diagram;

[0040] The code distribution module is used to distribute and store source codes of different business types in a microservice folder database according to the business type classification results in the microservice call relationship diagram, and generate a microservice architecture corresponding to the target single application.

[0041] On the other hand, an embodiment of the present application provides an electronic device, the electronic device includes a memory and a processor, the memory stores a computer program, and the processor implements the above-mentioned single application migration and reconstruction method when executing the computer program.

[0042] On the other hand, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the above-mentioned single application migration and reconstruction method is implemented.

[0043] The embodiment of the present application clusters the classes in the source code by pre-dividing the microservice business types, so that the source code can be redistributed according to the business function types without manual operation, effectively saving manpower and time costs, and improving the efficiency of single application migration and reconstruction. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] Figure 1 It is a schematic diagram of an implementation environment of a single application migration and reconstruction method provided in an embodiment of the present application;

[0045] Figure 2 It is a flowchart of a method for migration and reconstruction of a single application provided in an embodiment of the present application;

[0046] Figure 3 It is a schematic diagram of a process for generating a call relationship topology diagram provided by an embodiment of the present application;

[0047] Figure 4 It is a schematic diagram of a process for generating a microservice call relationship diagram provided by an embodiment of the present application;

[0048] Figure 5 It is a schematic diagram of a code distribution process provided by an embodiment of the present application;

[0049] Figure 6 This is a flowchart of a registration object provided by an embodiment of the present application;

[0050] Figure 7 This is a flowchart of starting a remote call service provided by an embodiment of the present application;

[0051] Figure 8 It is a flow chart of responding to a service call request provided by an embodiment of the present application;

[0052] Fig. 9 It is a structural schematic diagram of a single application migration and reconstruction device provided in an embodiment of the present application;

[0053] Fig.10 It is a schematic diagram of the hardware structure of the electronic device provided in the embodiment of the present application. DETAILED DESCRIPTION

[0054] In order to make the purpose, technical solutions and advantages of the present application clearer, the present application is further described in detail below in conjunction with the accompanying drawings and examples. It should be understood that the specific embodiments described herein are only used to explain the present application and are not intended to limit the present application. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the embodiments of the present application. They are only examples of devices and methods consistent with some aspects of the embodiments of the present application as detailed in the attached claims.

[0055] It is understood that the terms "first", "second", etc. used in this application can be used to describe various concepts in this article, but unless otherwise specified, these concepts are not limited by these terms. These terms are only used to distinguish one concept from another concept. For example, without departing from the scope of the embodiment of the present application, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the words "if" and "if" as used herein can be interpreted as "at the time of" or "when" or "in response to determination".

[0056] The terms "at least one", "multiple", "each", "any", etc. used in this application, at least one includes one, two or more, multiple includes two or more, each refers to each of the corresponding multiple, and any refers to any one of the multiple.

[0057] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0058] Currently, with the continuous iteration of monolithic applications using component architecture, the code size and complexity are rapidly expanding, and the number of projects that need to be maintained is large. Among them, a monolithic application is an architecture that concentrates all functions and components of an application in a single, independent unit. In this architecture, all codes and resources are compiled into an executable file and deployed on a single server. As the application grows, it may face problems with scalability, maintainability, and deployment speed.

[0059] In related technologies, monolithic applications are usually migrated and refactored into a microservice architecture. Microservice architecture is a design pattern that decomposes an application into a set of small, independent services, each of which runs in its own process and interacts through a lightweight communication mechanism. Each service is built around a specific business function and can be independently developed, deployed, expanded, and maintained. However, in actual applications, it is found that the current microservice transformation method requires manual copying of the component code to be migrated to the new project based on experience. The transformation work will face the problem of extremely large workload and require high labor and time costs.

[0060] In view of this, the embodiments of the present application provide a method, device, electronic device and storage medium for migration and reconstruction of a monolithic application. By clustering the classes in the source code according to the pre-divided microservice business types, the source code can be reallocated according to the business function type without manual operation, effectively saving manpower and time costs and improving the efficiency of migration and reconstruction of monolithic applications.

[0061] It should be noted that in each specific implementation of the present application, when it comes to the need to perform relevant processing based on data related to user identity or characteristics such as user information, user behavior data, user historical data, and user location information, the user's permission or consent will be obtained first, and the collection, use, and processing of these data will comply with relevant laws, regulations, and standards. In addition, when the embodiment of the present application needs to obtain the user's sensitive personal information, the user's separate permission or consent will be obtained through a pop-up window or by jumping to a confirmation page. After clearly obtaining the user's separate permission or consent, the necessary user-related data for the normal operation of the embodiment of the present application will be obtained.

[0062] The specific implementation of the embodiment of the present application is described in detail below in conjunction with the accompanying drawings. First, a single application migration and reconstruction method provided in the embodiment of the present application is described in conjunction with the accompanying drawings.

[0063] Please refer to Figure 1 , Figure 1 The schematic diagram of the implementation environment of a single application migration and reconstruction method provided by the embodiment of the present application is shown. In the implementation environment, the main software and hardware entities involved include a terminal processor 110 and a server 120.

[0064] Specifically, the terminal processor 110 may be installed with a related single application migration and reconstruction method control program, and the server 120 is the background server of the control program. The terminal processor 110 and the background server 120 are connected in communication. The single application migration and reconstruction method provided in the embodiment of the present application can be executed on the terminal processor 110 side.

[0065] Server 120 can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers. It can also be a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN (Content Delivery Network), as well as big data and artificial intelligence platforms.

[0066] In addition, the server 120 may also be a node server in the blockchain network.

[0067] The terminal processor 110 and the server 120 may establish a communication connection through a wireless network. The wireless network uses standard communication technology and / or protocols, and the network may be set to the Internet, or any other network, such as but not limited to a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), a mobile, or any combination of a wireless network, a private network, or a virtual private network. Moreover, the above-mentioned software and hardware entities may use the same communication connection mode or different communication connection modes, and this application does not impose any specific restrictions on this.

[0068] Of course, it is understandable that Figure 1 The implementation environment in the embodiment of the present application is only some optional application scenarios in the method for migration and reconstruction of a single application provided in the embodiment of the present application. The actual application is not fixed. Figure 1 The software and hardware environment shown is not specifically limited in this application.

[0069] like Figure 2 As shown, Figure 2 It is a flowchart of a method for migrating and reconstructing a single application provided in an embodiment of the present application, which specifically includes but is not limited to steps S100 to S400.

[0070] Step S100: Obtain source code of the target single application.

[0071] In the embodiments of the present application, a monolithic application generally adopts an architecture that concentrates all functions and components of an application into a single, independent unit. In this architecture, all codes and resources are compiled into an executable file and deployed on a single server. Therefore, by obtaining the relevant files on the server, the source code of the target monolithic application can be read. The target monolithic application refers to the monolithic application to be migrated and reconstructed.

[0072] Step S200, parse the source code to obtain a syntax tree, and generate a call relationship topology diagram; wherein the call relationship topology diagram includes at least one call link; each node in the call link is a class.

[0073] In an embodiment of the present application, a syntax tree refers to a tree structure generated from the source code of a programming language, which is used to represent the grammatical structure of the source code. By generating a syntax tree, it is possible to better and more clearly determine how to decompose the original application into multiple independent microservices when migrating and refactoring a monolithic application into a microservice architecture, thereby helping to define the interfaces between services and ensure that they can communicate and collaborate efficiently.

[0074] Furthermore, according to the structure of the syntax tree, the calling relationship between classes is calculated to determine each complete calling link.

[0075] Among them, a class refers to the blueprint or template for creating an object in object-oriented programming, defining a set of data and methods to describe the state and function of the object. Each node in each call link is a class, and a call relationship topology diagram is generated based on all call links.

[0076] Specifically, as an optional implementation, please refer to Figure 3 , Figure 3 It is a schematic diagram of a process of generating a call relationship topology diagram provided by an embodiment of the present application, wherein the source code is parsed to obtain a syntax tree, and a call relationship topology diagram is generated, including:

[0077] Step S210, traverse and parse each source code file to extract component code and project code;

[0078] Step S220, scanning the component code and the project code, taking the controller layer interface as the root node, and generating a syntax tree;

[0079] Step S230, calculating the call relationship between each class in the syntax tree to generate a call link;

[0080] Step S240: Generate the call relationship topology diagram according to the call link.

[0081] In an embodiment of the present application, source code files related to the target monomer application are obtained, and component codes and project codes are extracted therefrom. For example, taking java files as an example, each java file is traversed and parsed to find specific component definitions (such as classes, functions or modules), and their related codes are extracted. The codes related to the project logic are further identified, and the project codes are extracted. Then, the controller layer (Controller layer) interface is used as the root node, and a tool such as JavaParser is called to generate a syntax tree and calculate the call relationship between each class in the syntax tree to generate a call link. By traversing each project and related components, all complete call links in the source code file of the target monomer application are extracted, and a call relationship topology diagram is generated based on the obtained call links.

[0082] Step S300: Cluster the classes in the call relationship topology diagram according to the pre-divided microservice business types to generate a microservice call relationship diagram.

[0083] In the embodiment of the present application, the business boundaries can be pre-planned according to the specific business status and the types of microservices can be determined. For example, three types of microservices are divided into user services, enterprise information services, and file services according to existing projects.

[0084] Furthermore, based on the pre-divided microservice business types, the call relationship topology diagram is rescanned, the classes expected to be under the same service are aggregated, and a microservice call relationship diagram is generated according to the clustering results.

[0085] Specifically, as an optional implementation, please refer to Figure 4 , Figure 4 The present invention provides a schematic diagram of a process for generating a microservice call relationship diagram according to an embodiment of the present invention. The method comprises:

[0086] Step S310: obtaining pre-divided microservice business categories and naming keywords related to the microservice business categories;

[0087] Step S320: rescan the call relationship topology diagram according to the microservice business type and the naming keyword, and add a hierarchical classification identifier for each method;

[0088] Step S330: Cluster the classes in the call relationship topology diagram according to the hierarchical classification identifier to generate a microservice call relationship diagram.

[0089] In an embodiment of the present application, after determining the microservices to be built, naming keywords related to each microservice can be further given. For example, three types of microservice business are divided into user services, enterprise information services, and file services according to existing projects, and the naming keyword related to user services is determined to be user, the naming keyword related to enterprise information services is determined to be corp, and the naming keywords related to file services include file, upload, download, and storage.

[0090] Furthermore, based on the pre-classified microservice business types and naming keywords, the call relationship topology is rescanned, and a hierarchical classification identifier is added to each method in each class object. Finally, the classes expected to be under the same service are aggregated in combination with the call relationship topology and hierarchical classification identifier, thereby generating a microservice call relationship diagram. The microservice call relationship diagram is used to display the interactions and dependencies between microservices.

[0091] Step S400: According to the business type classification result in the microservice call relationship diagram, source codes of different business types are distributed and stored in a microservice folder database to generate a microservice architecture corresponding to the target monolithic application.

[0092] In an embodiment of the present application, according to the business type classification results in the microservice call relationship diagram, the classified source code is distributed and stored in the microservice folder database to facilitate subsequent copy calls, thereby completing the migration and reconstruction of the monolithic application and generating a microservice architecture.

[0093] It is understandable that by migrating the underlying atomic capability logic, that is, the business code of the service class or interface implementation class to the microservice architecture, the upper-level service does not need to pay attention to the implementation details, but only needs to call or aggregate the downstream microservice functions.

[0094] Therefore, by redistributing the source code according to the pre-divided microservice business types and hierarchical classification rules, it is possible to reduce repetitive manual operations, speed up the migration and reconstruction efficiency of monolithic applications, and decompose monolithic applications into multiple independent microservices.

[0095] For example, please refer to Figure 5 , Figure 5 It is a flow chart of code distribution provided by an embodiment of the present application. When the source code of a monolithic application is distributed, the executable file of the target monolithic application is first obtained, the source code is extracted, and a syntax tree is generated by parsing.

[0096] Furthermore, taking Java as an example, each Java file is traversed, the calling relationship between each class is calculated, a calling relationship topology diagram is generated, and the methods in all classes are hierarchically classified and identified according to the pre-divided business categories. Then, clustering sets are performed according to the identification and calling relationship topology structure to draw a microservice calling relationship diagram.

[0097] Furthermore, the clustering results can be checked. For example, they can be judged by an artificial intelligence deep learning model, or they can be manually checked by relevant staff. If it is considered that the clustering results need to be adjusted, the destination of the class can be manually adjusted, or relevant naming keywords can be optimized, hierarchical classification rules can be adjusted, and each Java file can be re-traversed until it is determined that the clustering results meet the requirements. Finally, the code can be distributed to the microservice folder database based on the clustering results for subsequent copying and calling.

[0098] Specifically, as an optional implementation, please refer to Figure 6 , Figure 6 It is a flow chart of a registration class object provided by an embodiment of the present application. After the source code of different business types is distributed and stored in a microservice folder database according to the business type classification result in the microservice call relationship diagram, and a microservice architecture corresponding to the target monolithic application is generated, the method further includes:

[0099] In response to a microservice startup instruction, determining a class in the microservice folder database that is identified as open;

[0100] Determine all public methods in the class marked as open and input parameters and output parameters of the public methods;

[0101] Encapsulate all the public methods and the input parameters and output parameters of the public methods into a packaging class object;

[0102] Record all the packaging class objects and complete the registration.

[0103] In an embodiment of the present application, the functions in the component source code migrated to the microservice can also be encapsulated into an interface to facilitate direct calling by other microservices. Therefore, the present application also provides a method for automatically encapsulating microservices into interfaces to provide external services, and provides related client proxy components, which can split classes and methods into two parts.

[0104] Furthermore, when the microservice is started, the microservice provider may scan and determine the classes marked as open in the microservice folder database, wherein the identification method includes but is not limited to annotations, configuration files, and specified scan paths.

[0105] Furthermore, the classes marked as open are traversed and scanned to determine all public methods and related input parameters and output parameters, and all determined public methods and input parameters and output parameters of the public methods are encapsulated into packaging class objects.

[0106] Finally, all packaging class objects are recorded to complete the registration of interface information. Exemplarily, the recording method includes but is not limited to reporting to a registration center or registering in a local context variable.

[0107] Optionally, after encapsulating all the public methods and the input parameters and output parameters of the public methods into packaging class objects, the method further includes:

[0108] Inserting a parameter verification object into the packaging class object;

[0109] Wherein, the parameter verification object includes empty judgment.

[0110] In an embodiment of the present application, before registering the interface information, a parameter verification object can also be inserted, such as introducing a null check, to check the input parameters to ensure that they meet the expected type, range, format, etc., which can effectively avoid runtime errors and unnecessary exceptions.

[0111] In an optional implementation, after the record completes the registration of all the packaging class objects, the method further includes:

[0112] Determine the interface information that needs to be opened;

[0113] Define all interface information declarations in the configuration class.

[0114] In an embodiment of the present application, when the microservice provider registers interface information, it will determine which interfaces need to be opened, and these interface declarations can be defined in the configuration class of the client component and can be declared as Bean objects. The microservice consumer (such as a microservice user) only needs to follow the configuration class to inject the Bean object into the Spring IOC container to facilitate the microservice consumer to remotely call the microservice.

[0115] In practical applications, please refer to Figure 7 , Figure 7 It is a flow chart of starting a remote call service provided by an embodiment of the present application, and the execution subject is a microservice user.

[0116] Furthermore, when the service user starts and performs initialization work, it can scan and determine the Bean object declaration information in the subsequent configuration class, and extract the interface information of the class, method, input parameter and output parameter, and generate a proxy class for it. The proxy class encapsulates the http call to the service provider, including retry mechanism, exception handling, return result adaptation, etc., returns the encapsulated proxy class, completes the encapsulation, so as to start the remote call service later.

[0117] Among them, the retry mechanism can be implemented through the Guava-Retry tool, which can be implemented by configuring retry conditions (such as throwing runtime exceptions, result detection exceptions), retry strategies (number of retries, fixed waiting time, increasing waiting time, exponential waiting time, determining waiting time according to exception type, compound waiting time strategy), and monitoring exception handling.

[0118] It should be noted that this application does not impose any specific restrictions on the retry mechanism, and the retry strategy for remote calls can be set according to the specific scenario requirements.

[0119] Exception handling means that when an exception occurs on the service provider side, the exception information is encapsulated in JSON and returned. Optionally, the service provider can also convert the exception object (the getTargetException method of the InvocationTargetException thrown by the target method of the reflection call can get the type of the exception object, so that the caller can restore the exception through deserialization) into a binary stream through serialization tools such as hessian, kryo, fury, etc., and return it.

[0120] Furthermore, the service caller's proxy class parses and throws the exception, and the service caller uses the previous code to handle business exceptions, returning an empty object or an empty collection according to the result type. If the return result causes an exception in the subsequent code execution, it will be captured and processed by the try-catch or global exception handling configuration in the code; when the service caller calls the downstream service provider and an exception occurs, it will be retried immediately according to the retry strategy. If the retry fails, an empty object or an empty collection will be returned according to the result type. If the return result causes an exception in the subsequent code execution, it will also be captured and processed by the try-catch or global exception handling configuration in the code.

[0121] Return result adaptation means that the service provider and the service caller can transmit information through JSON strings. Both parties can know the return result type through reflection, and use JSON format to encapsulate the results for communication and free conversion.

[0122] Of course, it should be noted that the present application does not impose any specific restrictions on the string format, and the response string format can be selected according to the specific programming language requirements.

[0123] Therefore, it is understandable that by making remote calls to microservices, under the influence of the proxy mechanism, method calls to Bean objects will follow the logic in the proxy class, thereby implementing calls to downstream microservices. In addition, using the proxy mechanism, the original code can continue to remain in the original project without affecting the effectiveness of the proxy, which makes it easier to troubleshoot problems on the one hand, and on the other hand, if a rollback is required, the proxy for the abnormal method can be turned off in a targeted manner.

[0124] Specifically, as an optional implementation, please refer to Figure 8 , Figure 8 It is a flow chart of responding to a service call request provided by an embodiment of the present application. After the record completes the registration of all the packaging class objects, the method further includes:

[0125] In response to the microservice call request, obtain the microservice call request;

[0126] Parse and read the calling information and parameter information of the class and method carried in the microservice call request;

[0127] According to the call information and parameter information, determine the corresponding class and execute it, and generate an execution result;

[0128] Send the execution result to the sender of the microservice call request.

[0129] In an embodiment of the present application, a microservice provider may set at least one service access interface according to business requirements for a microservice user to call services. After the microservice provider responds to a microservice call request sent by a microservice user, it may obtain the microservice call request, parse the method and input parameters to be called, and query the registration information of the relevant method to confirm whether it is open.

[0130] Furthermore, checking the legitimacy of the parameters can effectively avoid runtime errors and unnecessary exceptions. If the check passes, the request will be distributed to the specific implementation logic of the corresponding class, and the final execution result will be determined. Finally, the execution result will be packaged and returned to the sender of the microservice call request, that is, the microservice user, thereby completing the response to the service call request.

[0131] Next, the single application migration and reconstruction method provided in the present invention is introduced and described in detail in combination with a specific application implementation process:

[0132] In an embodiment of the present application, a method for migration and reconstruction of a monolithic application is provided. The method can be applied to a monolithic application reconstruction scenario. By clustering the classes in the source code based on the pre-divided microservice business types, the source code can be reallocated according to the business function types without manual operation, thereby effectively saving manpower and time costs and improving the efficiency of migration and reconstruction of the monolithic application.

[0133] Specifically, by obtaining relevant files on the server, the source code of the target monolithic application can be read, and the component code and project code can be extracted therefrom. Then, the controller layer interface is used as the root node to generate a syntax tree and calculate the calling relationship between each class in the syntax tree to generate a calling link. By traversing each project and related components, all complete calling links in the source code file of the target monolithic application are extracted, and based on the obtained calling links, a calling relationship topology diagram is generated.

[0134] Furthermore, based on the pre-divided microservice business types and naming keywords, the call relationship topology diagram is rescanned, and a hierarchical classification identifier is added to each method in each class object. Finally, the call relationship topology and hierarchical classification identifier are combined to aggregate the classes expected to be under the same service, thereby generating a microservice call relationship diagram.

[0135] Furthermore, based on the pre-divided microservice business types and naming keywords, the call relationship topology diagram is rescanned, and a hierarchical classification identifier is added to each method in each class object. Finally, the call relationship topology and hierarchical classification identifier are combined to aggregate the classes expected to be under the same service, thereby generating a microservice call relationship diagram.

[0136] Furthermore, the present application also provides a method of automatically encapsulating a microservice into an interface to provide external services. When the microservice is started, the microservice provider can scan and determine the classes marked as open in the microservice folder database, traverse and scan the classes marked as open, determine all public methods and related input parameters and output parameters, encapsulate all the determined public methods and the input parameters and output parameters of the public methods into packaging class objects, record all packaging class objects, and complete the registration of interface information. Before registering the interface information, a parameter verification object can also be inserted.

[0137] Furthermore, when the microservice provider registers interface information, it will determine which interfaces need to be opened, and these interface declarations can be defined in the configuration class of the client component and can be declared as Bean objects. The microservice consumer (such as the microservice user) only needs to inherit the configuration class to inject the Bean object into the Spring IOC container, so that the microservice consumer can remotely call the microservice.

[0138] Exemplarily, when the service user starts and performs initialization work, it can scan and determine the Bean object declaration information in the inherited configuration class, and extract the interface information of the class, method, input parameter and output parameter, and generate a proxy class for it. The proxy class encapsulates the http call to the service provider, including retry mechanism, exception handling, return result adaptation, etc., returns the encapsulated proxy class, completes the encapsulation, so as to start the remote call service later.

[0139] Finally, the microservice provider can set up at least one service access interface according to business needs for the microservice user to call the service. When the microservice provider responds to the microservice call request sent by the microservice user, it can obtain the microservice call request, parse the method and input parameters to be called, and query the registration information of the relevant method to confirm whether it is open.

[0140] Furthermore, checking the legitimacy of the parameters can effectively avoid runtime errors and unnecessary exceptions. If the check passes, the request will be distributed to the specific implementation logic of the corresponding class, and the final execution result will be determined. Finally, the execution result will be packaged and returned to the sender of the microservice call request, that is, the microservice user, thereby completing the response to the service call request.

[0141] See also Fig. 9 , Fig. 9 9 is a schematic diagram of a structure of a single application migration and reconstruction device 900 provided in an embodiment of the present application, which can implement the above-mentioned single application migration and reconstruction method, and the device includes:

[0142] A code acquisition module 910 is used to acquire the source code of the target single application;

[0143] The code parsing module 920 is used to parse the source code to obtain a syntax tree and generate a call relationship topology diagram; wherein the call relationship topology diagram includes at least one call link; each node in the call link is a class;

[0144] The clustering module 930 is used to cluster the classes in the call relationship topology diagram according to the pre-divided microservice business types to generate a microservice call relationship diagram;

[0145] The code distribution module 940 is used to distribute and store source codes of different business types in a microservice folder database according to the business type classification results in the microservice call relationship diagram, and generate a microservice architecture corresponding to the target single application.

[0146] It can be understood that the contents of the above method embodiments are all applicable to the present device embodiments, the functions specifically implemented by the present device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0147] Please refer to Fig.10 , Fig.10 The hardware structure of the electronic device provided in the embodiment of the present application is illustrated, and the electronic device includes:

[0148] The processor 1001 may be implemented by a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (Application Specific Integrated Circuit, ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of the present application;

[0149] The memory 1002 can be implemented in the form of a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 1002 can store an operating system and other applications. When the technical solution provided in the embodiment of this specification is implemented by software or firmware, the relevant program code is stored in the memory 1002, and the processor 1001 calls and executes the single application migration and reconstruction method of the embodiment of this application;

[0150] Input / output interface 1003, used to implement information input and output;

[0151] The communication interface 1004 is used to realize the communication interaction between the device and other devices. The communication can be realized through a wired manner (such as USB, network cable, etc.) or a wireless manner (such as mobile network, WIFI, Bluetooth, etc.);

[0152] A bus 1005 , which transmits information between various components of the device (e.g., the processor 1001 , the memory 1002 , the input / output interface 1003 , and the communication interface 1004 );

[0153] The processor 1001 , the memory 1002 , the input / output interface 1003 and the communication interface 1004 are connected to each other in communication within the device via the bus 1005 .

[0154] An embodiment of the present application also provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the above-mentioned single application migration and reconstruction method is implemented.

[0155] It can be understood that the contents of the above method embodiments are all applicable to the present storage medium embodiments, the functions specifically implemented by the present storage medium embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0156] The memory, as a non-transient computer-readable storage medium, can be used to store non-transient software programs and non-transient computer executable programs. In addition, the memory may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some embodiments, the memory may optionally include a memory remotely disposed relative to the processor, and these remote memories may be connected to the processor via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0157] The embodiments of the present application provide a method, device, electronic device and storage medium for migrating and reconstructing a single application. The method clusters the classes in the source code by pre-dividing the microservice business types, thereby realizing the redistribution of the source code according to the business function types without manual operation, effectively saving manpower and time costs, and improving the efficiency of migration and reconstruction of the single application.

[0158] The embodiments described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. Those skilled in the art will appreciate that with the evolution of technology and the emergence of new application scenarios, the technical solutions provided in the embodiments of the present application are also applicable to similar technical problems.

[0159] Those skilled in the art will appreciate that the technical solutions shown in the figures do not constitute a limitation on the embodiments of the present application, and may include more or fewer steps than shown in the figures, or a combination of certain steps, or different steps.

[0160] The device embodiments described above are merely illustrative, and the units described as separate components may or may not be physically separated, that is, they may be located in one place or distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0161] Those skilled in the art will appreciate that all or some of the steps in the methods disclosed above, and the functional modules / units in the systems and devices may be implemented as software, firmware, hardware, or a suitable combination thereof.

[0162] The terms "first", "second", "third", "fourth", etc. (if any) in the specification of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" 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.

[0163] It should be understood that in the present application, "at least one (item)" means one or more, and "plurality" means two or more. "And / or" is used to describe the association relationship of associated objects, indicating that three relationships may exist. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally indicates that the objects associated before and after are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.

[0164] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the above units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0165] The units described above as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0166] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0167] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including multiple instructions to enable a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of various embodiments of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (Read-Only Memory, referred to as ROM), random access memory (Random Access Memory, referred to as RAM), disk or optical disk and other media that can store programs.

[0168] The preferred embodiments of the present invention are described above with reference to the accompanying drawings, but the scope of the rights of the present invention is not limited thereto. Any modification, equivalent substitution and improvement made by a person skilled in the art without departing from the scope and essence of the present invention should be within the scope of the rights of the present invention.

Claims

1. A method for migration and reconstruction of a single application, characterized in that: The method comprises the following steps: Get the source code of the target monolithic application; Parsing the source code to obtain a syntax tree and generating a call relationship topology diagram; wherein the call relationship topology diagram includes at least one call link; each node in the call link is a class; According to the pre-divided microservice business types, the classes in the call relationship topology diagram are clustered to generate a microservice call relationship diagram; According to the business type classification result in the microservice call relationship diagram, source codes of different business types are distributed and stored in a microservice folder database to generate a microservice architecture corresponding to the target monolithic application.

2. The method for migration and reconstruction of a single application according to claim 1, characterized in that: The parsing of the source code to obtain a syntax tree and generating a call relationship topology diagram includes: Traverse and parse each source code file to extract component code and project code; Scan the component code and the project code, and generate a syntax tree with the controller layer interface as the root node; Calculate the call relationship between each class in the syntax tree to generate a call link; The call relationship topology graph is generated according to the call link.

3. The method for migration and reconstruction of a single application according to claim 1, characterized in that: The clustering of classes in the generated call relationship topology diagram according to the pre-divided microservice business types to generate a microservice call relationship diagram includes: Obtain pre-divided microservice business categories and naming keywords related to the microservice business categories; According to the microservice business type and the naming keyword, the call relationship topology diagram is rescanned, and a hierarchical classification identifier is added to each method; According to the hierarchical classification identifier, the classes in the call relationship topology diagram are clustered to generate a microservice call relationship diagram.

4. The method for migration and reconstruction of a single application according to claim 1, characterized in that: After distributing and storing source codes of different business types in a microservice folder database according to the business type classification result in the microservice call relationship diagram, and generating a microservice architecture corresponding to the target monolithic application, the method further includes: In response to a microservice startup instruction, determining a class in the microservice folder database that is identified as open; Determine all public methods in the class marked as open and input parameters and output parameters of the public methods; Encapsulate all the public methods and the input parameters and output parameters of the public methods into a packaging class object; Record all the packaging class objects and complete the registration.

5. The method for migration and reconstruction of a single application according to claim 4, characterized in that: After encapsulating all the public methods and the input parameters and output parameters of the public methods into packaging class objects, the method further includes: Inserting a parameter verification object into the packaging class object; Wherein, the parameter verification object includes empty judgment.

6. The method for migration and reconstruction of a single application according to claim 4, characterized in that: After the record completes the registration of all the packaging class objects, the method further includes: Determine the interface information that needs to be opened; Define all interface information declarations in the configuration class.

7. The method for migration and reconstruction of a single application according to claim 4, characterized in that: After the record completes the registration of all the packaging class objects, the method further includes: In response to the microservice call request, obtain the microservice call request; Parse and read the calling information and parameter information of the class and method carried in the microservice call request; According to the call information and parameter information, determine the corresponding class and execute it, and generate an execution result; Send the execution result to the sender of the microservice call request.

8. A single application migration and reconstruction device, characterized in that: The device comprises: Code acquisition module, used to obtain the source code of the target monolithic application; A code parsing module, used to parse the source code to obtain a syntax tree and generate a call relationship topology diagram; wherein the call relationship topology diagram includes at least one call link; each node in the call link is a class; A clustering module is used to cluster the classes in the call relationship topology diagram according to the pre-divided microservice business types to generate a microservice call relationship diagram; The code distribution module is used to distribute and store source codes of different business types in a microservice folder database according to the business type classification results in the microservice call relationship diagram, and generate a microservice architecture corresponding to the target single application.

9. An electronic device, characterized in that: The electronic device includes a memory and a processor, the memory stores a computer program, and the processor implements the single application migration and reconstruction method according to any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the monolithic application migration and reconstruction method described in any one of claims 1 to 7 is implemented.

Images