Method, apparatus and system for splitting a monolithic application into microservices based on SOA

Abstract

An embodiment of the present disclosure discloses a method, device, and system for splitting a monolithic application into microservices based on SOA. The method includes: outputting information to prompt an operator to import source files; dividing all source files into different services according to pre-configured information; when the source file is a code file, analyzing all class references from the source file to obtain the source code class path, reference class path, reference class method, and reference method frequency as the code dependency analysis result; when the source file is a database file, determining all introduced table names and the operation types for the table names from the database file; comprehensively quantifying the code dependency analysis result and the database table dependency analysis result; adjusting the directory structure and code layering structure of the source files with a monolithic structure according to the service division result of the previous step; and exporting the database tables and data of the monolithic application into database files according to the service division result of the previous step.

Description

Technical Field

[0001] The present disclosure relates to the field of computer technology, and particularly to a method, device, and system for splitting a SOA monolithic application into microservices. Background Art

[0002] Monolithic application: The entire application is deployed in a single web project, which is an engineering project running in a single JVM (Java Virtual Machine). Generally, it adopts a layered architecture. In the order of invocation, from top to bottom, there are the presentation layer, business layer, data access (DAO) layer, and DB layer. The presentation layer is responsible for the user experience, the business layer is responsible for business logic, the data access layer is responsible for data access and storage in the DB layer to implement functions such as addition, deletion, modification, and query. The business layer defines the business logic of the application and is the core of the entire application.

[0003] Disadvantages of monolithic applications: 1) Reliability: Each bug may affect the reliability of the entire application. Since all modules run in one process, a bug in any one module, such as a memory leak, may bring down the entire process. 2) High complexity: The huge codebase of a monolithic application can be daunting, especially for new team members. The application is difficult to understand and iterate, which slows down the development speed. Due to the lack of clear module boundaries, modularity gradually disappears. 3) Difficult continuous deployment: The huge monolithic application itself is a major obstacle to frequent deployment. 4) To update a component, the entire monolithic application must be redeployed, interrupting background tasks that may have nothing to do with the change and potentially causing other problems. Additionally, components that are not updated may not start properly. Redeployment increases risks and thus hinders frequent updates. 5) Limited scalability: The monolithic architecture can only be scaled one-dimensionally. On the one hand, it can increase business capacity by running multiple application service instances for expansion. On the other hand, different application components have different resource requirements: some are CPU-intensive, and some are memory-intensive. The monolithic architecture cannot scale each component separately. 6) Hindrance to technological innovation: Monolithic applications often use a unified technology platform or solution to solve all problems. Every member of the team must use the same development language and architecture, and it is very difficult to introduce a new framework or technology platform. The monolithic architecture forces the team to use the technology stack selected at the initial stage of development for a long time. For example, if the JVM language is chosen, components written in non-JVM languages cannot be used in the application with this monolithic architecture.

[0004] SOA: Service-Oriented Architecture is a component model that connects different functional units (called services) of an application through well-defined interfaces and contracts between these services.

[0005] Microservices architecture: A way to develop a single application using a series of smaller-grained services. Each service runs in its own process, and services communicate in a lightweight manner (usually HTTP API). These services are independently deployed through an automated deployment mechanism based on business logic and scope.

[0006] Advantages of microservices architecture: 1) Independent deployment of services: Each service is an independent project and can be independently deployed without relying on other services, with low coupling. 2) Fast startup of services: After splitting, the startup speed of services must be much faster than before splitting. 3) More suitable for agile development: Agile development takes the evolution of user requirements as the core and adopts an iterative and gradual approach. Service splitting allows for quick release of new versions. When modifying a service, only the corresponding service needs to be released, without having to release the whole again. 4) Single responsibility: Dedicated teams are responsible for dedicated services. As the business develops rapidly, there will be more and more R & D personnel. Each team can be responsible for the corresponding business line, and service splitting is conducive to division of labor among teams. 5) Services can be dynamically scaled up on demand: When the traffic of a certain service is large, we only need to scale up this service. 6) Code reuse: Each service provides REST API. All basic services must be extracted, and many underlying implementations can be provided in the form of interfaces.

[0007] In summary, upgrading from a monolithic architecture to a microservices architecture can help enterprises better manage business processes and improve the development efficiency of information systems at the same time. Summary of the Invention

[0008] Embodiments of the present disclosure provide a method, apparatus, and system for splitting a SOA monolithic application into microservices.

[0009] In a first aspect, embodiments of the present disclosure provide a method for splitting a SOA monolithic application into microservices, characterized by including:

[0010] Output information prompting the operator to import the source file, and after the source file is successfully imported, scan the imported source file to obtain relevant information of the source file; the relevant information includes the storage path of the source file, the file type of the source file, and the package name;

[0011] Divide all source files into different services according to pre-configured information;

[0012] When the source file is a code file, analyze all class references from the source file to obtain the source code class path, reference class path, reference class method, and reference method frequency, as the code dependency analysis result;

[0013] When the source file is a database file, determine all the introduced table names and the operation types for the table names from the database file; determine the main table from all the introduced tables, determine the other tables as associated tables, and store the service to which the database file belongs, the main table, the associated tables, and the usage frequency of the tables determined from the database file correspondingly as the database table dependency analysis result;

[0014] By comprehensively quantifying the code dependency analysis result and the database table dependency analysis result, and presenting the service division result obtained from the comprehensive quantification as a two-dimensional matrix, with the vertical axis representing the calling service, the horizontal axis representing the referenced service, and the value at the intersection of the vertical axis and the horizontal axis representing the number of references; the detailed information is stored in an associated manner for the value at the intersection point, and the detailed information includes the service to which the source code belongs, the source code path, the dependent service, the referenced class path, the referenced method, the reference method frequency, the associated table, and the association frequency;

[0015] Adjust the directory structure and the code layering structure of the source file with a monolithic structure according to the service division result of the previous step;

[0016] Export the database tables of the monolithic application and the data as database files according to the service division result of the previous step.

[0017] Further, the method further includes:

[0018] After comprehensively quantifying the code dependency analysis result and the database table dependency analysis result, perform manual adjustment on the code dependency analysis result and the database table dependency analysis result; wherein, when the service division result is modified, it triggers the code analysis operation and simultaneously updates the comprehensive quantification analysis result;

[0019] Further, when the source file is a code file, analyze all class references from the source file, and obtain the source code class path, the referenced class path, the referenced class method, and the reference method frequency as the code dependency analysis result, including:

[0020] When the file type of the source file is a JAVA file, perform abstract syntax tree analysis on the source code file. After excluding the class references that are the same as the package name of the source code file by parsing all the class references of the imported source code included in each node of the syntax tree, store the source code class path, the referenced class path, the referenced class method, and the reference method frequency.

[0021] Further, when the source file is a database file, determine all the introduced table names and the operation types for the table names from the database file; determine the main table from all the introduced tables, determine the other tables as associated tables, and store the service to which the database file belongs, the main table, the associated tables, and the usage frequency of the tables determined from the database file correspondingly as the database table dependency analysis result, including:

[0022] If the source file is an SQL file, analyze all the table names introduced in the SQL file, record the operation types, and determine the main table according to the following rules:

[0023] Determine the database tables whose table operation types include CREATE, UPDATE, or DELETE as the main tables of the SQL file, and other tables as associated tables;

[0024] If all table operation types are of the SELECT type, determine the main table according to the usage frequency of the tables. The table with the highest frequency is the main table, and the others are all associated tables.

[0025] In a second aspect, an apparatus for splitting a SOA monolithic application into microservices according to an embodiment of the present disclosure is characterized by including:

[0026] An output module, configured to output information prompting an operator to import a source file, and after the source file is successfully imported, scan the imported source file to obtain relevant information of the source file; the relevant information includes the storage path of the source file, the file type of the source file, and the package name;

[0027] A partitioning module, configured to partition all source files into different services according to pre-configured information;

[0028] A first analysis module, configured to, when the source file is a code file, analyze all class references from the source file to obtain the source code class path, the reference class path, the reference class method, and the reference method frequency as the code dependency analysis result;

[0029] A second analysis module, configured to, when the source file is a database file, determine all the table names introduced in the database file and the operation types for the table names; determine the main table from all the introduced tables, determine other tables as associated tables, and store the service to which the database file belongs, the main table, the associated tables, and the usage frequency of the tables determined from the database file correspondingly as the database table dependency analysis result;

[0030] A quantization module, configured to comprehensively quantify the code dependency analysis result and the database table dependency analysis result, and display the service partitioning result obtained by the comprehensive quantization as a two-dimensional matrix. The vertical axis represents the calling service, the horizontal axis represents the referenced service, and the value at the intersection of the vertical axis and the horizontal axis represents the number of references; the numerical value at the intersection is associated with and stores detailed information, and the detailed information includes the service to which the source code belongs, the source code path, the dependent service, the reference class path, the reference method, the reference method frequency, the associated table, and the associated frequency;

[0031] An adjustment module, configured to adjust the directory structure and code layering structure of the source files of the monomer structure according to the service division result of the previous step;

[0032] An export module, configured to export the database tables of the monomer application according to the service division result of the previous step, and export the database tables and data into database files by service.

[0033] Thirdly, an SOA monomer application splitting microservice-based system is provided in an embodiment of the present disclosure, which is characterized by including: an input and display part, an analysis part, and a splitting part;

[0034] The input and display part includes: a display module, an information input module, a calibration module, and an export module;

[0035] The analysis part includes a service division module, a code dependency analysis module, a database table dependency analysis module, and a comprehensive quantitative analysis module;

[0036] The splitting part includes a code splitting module and a database splitting module, where:

[0037] The display module is responsible for displaying all information that can be operated by users and providing visual and wizard-style operation functions; the optional service list is displayed in an external device by calling the service division module;

[0038] The information input module is used to input the control and usage information of users, and at the same time provide the input and interaction of basic information required during the microservice splitting process; all operations in the information input module will be directly output visually through the display module; through the information input module, various configurations during the microservice splitting process can be managed, facilitating visual manual intervention;

[0039] The export module is responsible for exporting the service division result into an Excel file, and is also responsible for exporting the quantitative analysis result into an Excel file;

[0040] The calibration module is responsible for manually adjusting the service division result and the comprehensive quantitative analysis result, and the adjustment interface provides a batch adjustment function;

[0041] The service division module is used to configure the configuration information for dividing services. The database tables are divided using the table name prefix, and the source code is divided using the package name prefix; the source files are divided into each service according to the pre-configured configuration information; after the service division is completed, the calibration module is used to manually adjust the service division result;

[0042] The code dependency analysis module is responsible for analyzing the call relationships between all classes in the source code and classes under other package names, and detailedly recording the file location, class path, line number where the calling code is located, and the path, method, etc. of the called class;

[0043] The database table dependency analysis module is responsible for analyzing the database tables used in the SQL statements in the source file and recording the file path of the user and the database table information;

[0044] The comprehensive quantitative analysis module is used to analyze the dependency relationships between services based on the results of code dependency analysis and database table dependency analysis. The analysis result is presented as a two-dimensional matrix, where the vertical axis represents the calling service, the horizontal axis represents the referenced service, and the value at the intersection of the vertical axis and the horizontal axis represents the number of references;

[0045] The code splitting module is responsible for splitting the code into the folders corresponding to their respective services according to the service division results;

[0046] The database splitting module is responsible for exporting the database tables and data into database files according to the service division results.

[0047] The above functions can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions.

[0048] In a possible design, the structure of the above device includes a memory and a processor. The memory is used to store one or more computer instructions that support the above device to execute the corresponding method, and the processor is configured to execute the computer instructions stored in the memory. The above device may further include a communication interface for the device to communicate with other devices or communication networks.

[0049] In a fourth aspect, an embodiment of the present disclosure provides an electronic device, including a memory, a processor, and a computer program stored on the memory. The processor executes the computer program to implement the method described in any of the above aspects.

[0050] In a fifth aspect, an embodiment of the present disclosure provides a computer-readable storage medium for storing computer instructions used by any of the above devices. When the computer instructions are executed by a processor, they are used to implement the method described in any of the above aspects.

[0051] In a sixth aspect, an embodiment of the present disclosure provides a computer program product that includes computer instructions. When the computer instructions are executed by a processor, they are used to implement the method described in any of the above aspects.

[0052] The technical solutions provided by the embodiments of the present disclosure may include the following beneficial effects:

[0053] Through the use of a code analysis tool, the present invention can intuitively understand the dependency relationships of the service codes after partitioning. Through comprehensive quantitative analysis, it can provide data support for microservice splitting. The use of a splitting tool can greatly improve the efficiency and accuracy of microservice splitting.

[0054] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and cannot limit the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0055] In conjunction with the accompanying drawings, through the following detailed description of non-limiting embodiments, other features, objects, and advantages of the present disclosure will become more apparent. In the drawings:

[0056] Figure 1 A flowchart showing a method for splitting a microservice from a SOA monolithic application according to an embodiment of the present disclosure;

[0057] Figure 2 A system block diagram showing a system for splitting a microservice from a SOA monolithic application according to an embodiment of the present disclosure;

[0058] Figure 3 A flowchart showing an implementation of a method for splitting a microservice from a SOA monolithic application according to an embodiment of the present disclosure;

[0059] Figure 4 A schematic structural diagram of an electronic device suitable for implementing a method for splitting a microservice from a SOA monolithic application according to an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0060] In the following, exemplary embodiments of the present disclosure will be described in detail with reference to the accompanying drawings, so that those skilled in the art can easily implement them. In addition, for clarity, parts unrelated to the description of the exemplary embodiments are omitted in the drawings.

[0061] In the present disclosure, it should be understood that terms such as "including" or "having" are intended to indicate the existence of features, numbers, steps, actions, components, parts, or combinations thereof disclosed in this specification, and do not exclude the possibility of the existence or addition of one or more other features, numbers, steps, actions, components, parts, or combinations thereof.

[0062] It should also be noted that, without conflict, the embodiments in the present disclosure and the features in the embodiments can be combined with each other. The present disclosure will be described in detail below with reference to the drawings and in conjunction with the embodiments.

[0063] The technical problem to be solved by the present invention: By scanning the source code, the initially divided microservices are determined, and then through code semantic analysis, the quantifiable dependencies between the codes and database tables among the services are sorted out. The code analysis establishes a set of quantifiable evaluation criteria for the complex splitting work and also provides data support for code splitting. Finally, the complex monolithic application is gradually split into an application program that meets the microservice architecture style.

[0064] The technical solution of the present invention is: A system and method for splitting a monolithic application into microservices based on SOA, including: an input and display part, an analysis part, and a splitting part; the input and display part includes: a display module, an information input module, a calibration module, and an export module; the analysis part includes a service division module, a code dependency analysis module, a database table dependency analysis module, and a comprehensive quantitative analysis module; the splitting part includes a code splitting module and a database splitting module, where:

[0065] Display module: Responsible for displaying all the information that all users can operate and providing visual and wizard-style operation functions; displaying the list of optional services to an external device by calling the service division module;

[0066] Information input module: Inputs the control and usage information of the user, and at the same time provides the input and interaction of basic information required during the microservice splitting process; all operations in the information input module will be directly output visually through the display module; through the information input module, various configurations during the microservice splitting process can be managed, facilitating visual manual intervention;

[0067] Export module: Responsible for exporting the service division result into an Excel file; responsible for exporting the quantitative analysis result into an Excel file;

[0068] Calibration module: Responsible for adjusting the result of service division, and the calibration interface provides a function for batch adjustment; responsible for adjusting the result of quantitative analysis, and the calibration interface provides a function for batch adjustment;

[0069] Service division module: Configures the rules for dividing services. The database tables are divided using the table name prefix, and the JAVA code is divided using the package name prefix; divides the source code into each service according to the pre-configured rules; after the service division is completed, the result can be adjusted using the calibration module;

[0070] Code dependency analysis module: Responsible for analyzing the call relationships between all classes in the source code and classes under other package names, and detailed records of the file location, class path, line number where the calling code is located, and the path and method of the called class are provided;

[0071] Database Table Dependency Analysis Module: Responsible for analyzing the database tables used in SQL statements in the code, and recording in detail the file paths of the users and the database table information;

[0072] Comprehensive Quantitative Analysis Module: Based on the results of code dependency analysis and database table dependency analysis, analyze the dependency relationships between services. The analysis results are presented as a two-dimensional matrix, where the vertical axis represents the calling service, the horizontal axis represents the referenced service, and the value at the intersection of the vertical axis and the horizontal axis represents the number of references. The larger the value, the closer the dependency;

[0073] Code Splitting Module: Responsible for splitting the code into the folders corresponding to their respective services according to the service division results

[0074] Database Splitting Module: Responsible for exporting the database tables and data into SQL files according to the service division results.

[0075] The details of the embodiments of the present disclosure will be described in detail below through specific embodiments.

[0076] Figure 1 The flowchart showing a method for splitting a SOA monolithic application into microservices according to an embodiment of the present disclosure is as follows Figure 1 As shown, the method for splitting a SOA monolithic application into microservices includes the following steps:

[0077] In step S101, information prompting the operator to import the source file is output, and after the source file is successfully imported, the imported source file is scanned to obtain relevant information of the source file; the relevant information includes the storage path of the source file, the file type of the source file, and the package name;

[0078] In step S102, all source files are divided into different services according to the pre-configured information;

[0079] In step S103, when the source file is a code file, all class references are analyzed from the source file to obtain the source code class path, reference class path, reference class method, and reference method frequency, as the code dependency analysis result;

[0080] In step S104, when the source file is a database file, all introduced table names and the operation types for the table names are determined from the database file; the main table is determined from all the introduced tables, and the other tables are determined as associated tables, and the service to which the database file belongs, as well as the main table, associated tables, and table usage frequency determined from the database file are stored correspondingly, as the database table dependency analysis result;

[0081] In step S105, by comprehensively quantifying the code dependency analysis result and the database table dependency analysis result, and presenting the service division result obtained from the comprehensive quantification as a two-dimensional matrix, where the vertical axis represents the calling service, the horizontal axis represents the referenced service, and the value at the intersection of the vertical axis and the horizontal axis represents the number of references; the numerical value at the intersection is associated with storing detailed information, which includes the service to which the source code belongs, the source code path, the dependent service, the reference class path, the reference method, the reference method frequency, the associated table, and the associated frequency.

[0082] In step S106, the source files of the monolithic structure are adjusted in terms of the directory structure and the code layering structure according to the service division result of the previous step.

[0083] In step S107, the database tables of the monolithic application are exported into database files by service together with the data according to the service division result of the previous step.

[0084] In this embodiment, the information input module prompts the operator to import the source code. After the source code is successfully imported, the service division module performs a scan of the source code to complete the collection and collation of detailed information such as the storage path of the source code, the source code file type, and the package name.

[0085] The service division module divides all the source code into different services according to the configured information. In some embodiments, it can be divided according to the prefix of the package name, and the package names included in each service can be configured in the configuration information. In other embodiments, if there are discrepancies between the service division result and the actual business, the function of the calibration module can be used for manual calibration.

[0086] The code dependency analysis part analyzes all class references from the source code files, obtains the source code class path, referenced class path, referenced class methods, and the frequency of referenced methods as the code dependency analysis result. Among them, the source code class path refers to the path of the class of the current source code, which controls the package name and the class name. The referenced class refers to the class referenced in the source code, and the referenced method is the method referenced in the source code. For example, if the file type is a JAVA file, an Abstract Syntax Tree (AST) analysis is performed on the source code file. By parsing all the class references of the imported source code included in the ImportDeclaration, FieldDeclaration, and MethodDeclaration child nodes under the compilationUnit node in the syntax tree, after excluding the class references with the same package name as the source code, the source code class path, referenced class path, referenced class methods, and the frequency of referenced methods are stored. Among them, one compilationUnit node corresponds to a JAVA source code after AST analysis. The ImportDeclaration node contains the declarations of all imported packages in the source code, the FieldDeclaration node contains the declarations of all attributes in the source code, and the MethodDeclaration node contains the declarations of all methods in the source code. In the embodiments of the present disclosure, these three nodes can be analyzed to obtain all other packages depended on in the source code.

[0087] The database table dependency analysis part determines all the introduced table names and the operation types for the said table names from the source code files; determines the main table from all the introduced tables, determines the other tables as associated tables, and stores the service to which the source code file belongs, the main table, associated tables, and the usage frequency of the tables determined from the source code file correspondingly as the database table dependency analysis result. If the file type is an SQL file, all the introduced table names in the file can be analyzed, and the operation types (one or more of CREATE, SELECT, UPDATE, or DELETE) are recorded. The main table is determined according to the following rules: If the operation type of a certain table contains CREATE, UPDATE, or DELETE, then it is determined that this table is the main table of the SQL file, and the other tables are associated tables; if the operation types of all tables are only SELECT, then the main table is determined according to the usage frequency of the tables, and the one with the highest frequency is the main table, and the others are all associated tables. If there are more than two main tables in the SQL file, one can be selected as the main table through manual intervention.

[0088] The database table dependency analysis module determines the service to which the SQL file belongs by parsing the value of the namespace, and stores the main table information, associated table information, and the frequency of use of the associated tables of the service to which the SQL file belongs. Among them, (the value of the namespace is the class path of the JAVA source code, that is, it includes the package name and the class name. Based on the package name in the class path, the service to which the SQL file belongs can be determined).

[0089] Comprehensive quantitative analysis part: By comprehensively quantifying the results of code dependency analysis and database table dependency analysis, and presenting the service division results obtained from the comprehensive quantification as a two-dimensional matrix. The vertical axis represents the calling service, the horizontal axis represents the referenced service, and the value at the intersection of the vertical axis and the horizontal axis represents the number of references. The larger the value, the closer the dependency; by clicking on the value at the intersection point, you can drill down to view the detailed information of the dependencies between services. The detailed information will list the service to which the source code belongs, the source code path, the dependent service, the reference class path, the reference method, the frequency of the reference method, the associated table, and the associated frequency. The dependent service can be the service to which the reference class belongs, determined based on the package name in the reference class path.

[0090] Calibration part: Through the calibration operation of the calibration module, the service to which the source code belongs can be modified. Once the service division result is modified, it will trigger the code dependency analysis operation and update the comprehensive quantitative analysis result at the same time.

[0091] Code splitting part: Responsible for adjusting the directory structure and code layering structure of the source code with a monolithic structure according to the service division result of the previous step. Each service after adjustment meets the microservice architecture style. Each service corresponds to a maven project, which contains 5 sub-maven projects: api project, pub project, service project, ui project, and boot project. Among them, the api project is the api class of the component, and calls the backend service through the restful interface; the pub project is the common class of the component, mainly the dto class; the service project is the backend service class of the component, including rest services, services, daos, etc.; the ui project is the project of the service using jsp for the front end, mainly containing the controller layer code of the service; the boot project is the startup project of the component, mainly including the startup class and the relevant configuration files of the service.

[0092] In some embodiments, the microservice splitting principle is as follows:

[0093] 1) Based on business logic: Split the closely related businesses into one microservice. For example, split the dependent service and the current service into one microservice; split the relatively independent functions into separate microservices. Split the common components into independent atomic services and sink them to the bottom layer to form a relatively independent atomic service layer. Split the business shared by multiple service components into a separate microservice for unified invocation by other services.

[0094] 2) Based on reliability: Group the core modules with high reliability requirements together, and group the non-core modules with low reliability requirements together.

[0095] 3) Based on stability, extract the unstable and frequently modified parts and merge them into one service component, and divide the stable and infrequently changed parts into one component to achieve separate deployment and management.

[0096] 4) Based on performance, prioritize the services in the system according to their performance requirements. Separate the modules with high performance requirements into one service, and group the modules with low performance requirements together.

[0097] After service splitting, use the REST method for cross-service calls.

[0098] The database splitting part is responsible for exporting the database tables and data of the monolithic database structure into SQL files according to the service division results of the previous step. The database administrator creates new database instances for each service and imports the SQL files to complete the physical splitting of the database. After service splitting, use the REST method for cross-service table association.

[0099] The present invention has the following beneficial effects compared with the prior art:

[0100] By using the code analysis tool, the present invention can intuitively understand the dependency relationships of the codes of each divided service. Through comprehensive quantitative analysis, it can provide data support for microservice splitting. Using the splitting tool can greatly improve the efficiency and accuracy of microservice splitting.

[0101] Figure 2 Show a system structure block diagram of splitting a microservice from a SOA monolithic application according to an embodiment of the present disclosure. As Figure 2 shown, the system mainly includes an input and display part, an analysis part, and a splitting part; the input and display part includes: a display module, an information input module, a calibration module, and an export module; the analysis part includes a service division module, a code dependency analysis module, a database table dependency analysis module, and a comprehensive quantitative analysis module; the splitting part includes a code splitting module and a database splitting module, where:

[0102] The specific implementation of the input and display part is as follows: After the system starts, the input and display part is mainly used to display necessary menus, control panels, and data items. The information input module and the display module together solve the control and information interaction of external users with the system by sequentially solving settings such as code scanning, service division, code dependency analysis, database table dependency analysis, code splitting, and database table splitting. The system will automatically manage each process and handle exceptions. If manual intervention is required, a reminder will be given in the form of a pop-up dialog box on the interface.

[0103] The specific implementation of the code analysis part is as follows: Configure the configuration information of the division service. The database tables are divided using the table name prefix, that is, those with the same table name prefix are divided into the same service. The code is divided using the package name prefix, that is, those with the same package name prefix are divided into the same service.

[0104] The database attribute information table of the above configuration information is shown as follows:

[0105]

[0106] Service division module: Divide the source code into each service according to the microservice configuration information. After division, the microservice division result table is obtained, as shown in the following table:

[0107]

[0108] Code dependency analysis module: Responsible for analyzing the call relationships between all JAVA classes in the microservice division result table and classes under other package names, recording in detail the class path, line number where the calling code is located, and the path, method, etc. of the called class, and obtaining the code dependency division result table, as shown in the following table;

[0109]

[0110] Database table dependency analysis module: Responsible for analyzing the database tables used in the SQL statements of all TABLEs in the microservice division result table, recording in detail the usage parties such as the file path of the JAVA source file and the database table information, and obtaining the database table dependency analysis result table, as shown in the following table:

[0111]

[0112] Comprehensive quantitative analysis module: Based on the results of code dependency analysis and database table dependency analysis, analyze the dependency relationships between each service and other services. The analysis result is presented as a two-dimensional matrix. The vertical axis represents the calling service, the horizontal axis represents the called service, and the value at the intersection of the vertical axis and the horizontal axis represents the number of calls. The larger the value, the closer the dependency.

[0113] The specific implementation of the code splitting part is as follows: split the code into the folders corresponding to their respective services based on the microservice division result table; export the database tables and data into SQL files based on the microservice division result table.

[0114] The monolithic application uses a large and comprehensive database, while each service in the microservice architecture connects to its own database. This involves splitting a large and comprehensive database, and the basis for splitting is the service division result table. In this embodiment, the tables and data in the monolithic application database are split into different databases based on the microservice division result table.

[0115] As Figure 3 shown, the implementation steps of a method for splitting a monolithic application into microservices based on SOA are as follows:

[0116] Code analysis: The information input module prompts the operator to import the source code. After the source code is successfully imported, the service division module scans the source code and completes the collection and collation of detailed information such as code paths, file types, and package names. The service division module divides all source codes into different services according to the configured rules. If the result of service division does not match the actual business, the function of the calibration module can be used for manual intervention. Code dependency analysis: If the file type is a JAVA file, the source code file is analyzed by the Abstract Syntax Tree (AST). By parsing all class references that import the source code included in the ImportDeclaration, FieldDeclaration, and MethodDeclaration child nodes under the compilationUnit node in the syntax tree, after excluding the class references with the same package name as the source code package, the source code class path, reference class path, reference class method, and reference method frequency are stored. Database table dependency analysis: If the file type is an SQL file, all the table names introduced in the file need to be analyzed, and the operation types (one or more of CREATE, SELECT, UPDATE, or DELETE) are recorded. The main table is determined according to the following rules: If the operation type of a certain table includes CREATE, UPDATE, or DELETE, then it is determined that this table is the main table of the SQL file, and other tables are associated tables; If the operation type of all tables is only SELECT, the main table is determined according to the usage frequency of the tables, and the table with the highest frequency is the main table, and the others are all associated tables. If there are more than two main tables in the SQL file, manual intervention is required. The database table dependency analysis module determines the service to which the SQL file belongs by parsing the value of the namespace, and stores the main table information, associated table information, and associated table usage frequency of the service to which the SQL file belongs. Comprehensive quantitative analysis: By comprehensively quantifying the results of code dependency analysis and database table dependency analysis, the analysis results are presented as a two-dimensional matrix. The vertical axis represents the calling service, the horizontal axis represents the referenced service, and the value at the intersection of the vertical axis and the horizontal axis represents the number of references. The larger the value, the closer the dependency. By clicking on the value at the intersection, you can drill down to view the detailed information of the dependencies between services. The detailed information will list the service to which the source code belongs, the source code path, the dependent service, the reference class path, the reference method, the reference method frequency, the associated table, and the associated frequency. Through the calibration operation of the calibration module, the service to which the source code belongs can be modified. Once the service division result is modified, it will trigger the code analysis operation and update the comprehensive quantitative analysis result at the same time. As Figure 2 shown, calibration and analysis is a cyclic process, and the next splitting stage can only be entered until the comprehensive quantitative analysis result meets the business requirements.

[0117] Code splitting: Responsible for adjusting the directory structure and code layering structure of the source code of the monolithic structure according to the service division results of the previous step. Each service after adjustment meets the microservices architecture style, and each service corresponds to a maven project, which contains 5 sub-maven projects as follows: 1) api project: api classes of the component, calling the backend service through restful interfaces; 2) pub project: common classes of the component, mainly dto classes; 3) service project: backend service classes of the component, including rest services, services, daos, etc.; 4) ui project: only services that use jsp for the front end have this project, mainly including the controller layer code of the service; 5) boot project: startup project of the component, mainly including startup classes and relevant configuration files of the service. After service splitting, cross-service calls need to be transformed into REST-style calls. Database splitting: Responsible for exporting database tables and data of the monolithic application into SQL files according to the service division results of the previous step. The database administrator creates new database instances for each service and imports the SQL files to complete the physical splitting of the database. After service splitting, cross-service table associations need to be transformed into REST-style calls.

[0118] The following is an embodiment of the disclosed device, which can be used to execute the embodiment of the disclosed method.

[0119] A device for splitting a SOA monolithic application into microservices according to an embodiment of the present disclosure. The device can be implemented as part or all of an electronic device through software, hardware, or a combination of both. The device for splitting a SOA monolithic application into microservices includes:

[0120] An output module, configured to output information prompting an operator to import a source file, and after the source file is successfully imported, scan the imported source file to obtain relevant information of the source file; the relevant information includes the storage path of the source file, the file type of the source file, and the package name.

[0121] A division module, configured to divide all source files into different services according to pre-configured information.

[0122] A first analysis module, configured to, when the source file is a code file, analyze all class references from the source file to obtain the source code class path, the reference class path, the reference class method, and the reference method frequency, as the code dependency analysis result.

[0123] A second analysis module, configured to, when the source file is a database file, determine all introduced table names and the operation types for the table names from the database file; determine a main table from all the introduced tables, determine other tables as associated tables, and store the service to which the database file belongs, the main table, the associated tables, and the usage frequency of the tables correspondingly as the database table dependency analysis result;

[0124] A quantification module, configured to comprehensively quantify the code dependency analysis result and the database table dependency analysis result, and display the service division result obtained from the comprehensive quantification as a two-dimensional matrix, where the vertical axis represents the calling service, the horizontal axis represents the referenced service, and the value at the intersection of the vertical axis and the horizontal axis represents the number of references; detailed information is stored in an associated manner for the value at the intersection point, and the detailed information includes the service to which the source code belongs, the source code path, the dependent service, the referenced class path, the referenced method, the frequency of the referenced method, the associated tables, and the associated frequency;

[0125] An adjustment module, configured to adjust the directory structure and the code layering structure of the source file with a monolithic structure according to the service division result of the previous step;

[0126] An export module, configured to export the database tables of the monolithic application and the data as database files according to the service division result of the previous step for each service.

[0127] The apparatus for splitting a monolithic application based on SOA into microservices corresponds to the method for splitting a monolithic application based on SOA in the above text. For specific details, reference can be made to the description of the method for splitting a monolithic application based on SOA in the above text, and details will not be elaborated here.

[0128] Figure 4 It is a schematic structural diagram of an electronic device suitable for implementing the method for splitting a monolithic application based on SOA into microservices according to an embodiment of the present disclosure.

[0129] As Figure 4 shown, the electronic device 400 includes a processing unit 401, which can be implemented as a processing unit such as a CPU, GPU, FPGA, NPU, etc. The processing unit 401 can execute various processes in the embodiments of any of the above methods of the present disclosure according to the program stored in the read-only memory (ROM) 402 or the program loaded from the storage section 408 into the random access memory (RAM) 403. In the RAM 403, various programs and data required for the operation of the electronic device 400 are also stored. The processing unit 401, the ROM 402, and the RAM 403 are connected to each other through a bus 404. The input / output (I / O) interface 405 is also connected to the bus 404.

[0130] The following components are connected to the I / O interface 405: an input part 406 including a keyboard, a mouse, etc.; an output part 407 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc. as well as a speaker, etc.; a storage part 408 including a hard disk, etc.; and a communication part 409 including a network interface card such as a LAN card, a modem, etc. The communication part 409 performs communication processing via a network such as the Internet. A drive 410 is also connected to the I / O interface 405 as required. A removable medium 411, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 410 as required so that a computer program read therefrom can be installed into the storage part 408 as required.

[0131] Specifically, according to an embodiment of the present disclosure, any of the methods described above with reference to the embodiments of the present disclosure can be implemented as a computer software program. For example, an embodiment of the present disclosure includes a computer program product that includes a computer program tangibly embodied on a machine-readable medium, the computer program including program code for performing any of the methods in the embodiments of the present disclosure. In such an embodiment, the computer program can be downloaded and installed from a network via the communication part 409, and / or installed from the removable medium 411.

[0132] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architectures, functions, and operations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagram may represent a module, a program segment, or a part of code that includes one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than marked in the accompanying drawings. For example, two consecutive blocks shown may actually be executed substantially in parallel, and they may sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart, and combinations of blocks in the block diagram and / or flowchart, can be implemented by a dedicated hardware-based system that performs the specified functions or operations, or can be implemented by a combination of dedicated hardware and computer instructions.

[0133] The units or modules involved in the embodiments described in the present disclosure can be implemented in software or in hardware. The described units or modules can also be provided in a processor, and the names of these units or modules do not, in some cases, constitute a limitation on the units or modules themselves.

[0134] As another aspect, the present disclosure also provides a computer-readable storage medium, which may be the computer-readable storage medium included in the device described in the above embodiments; or it may exist separately and be a computer-readable storage medium not assembled into the device. The computer-readable storage medium stores one or more programs, and the one or more programs are used by one or more processors to execute the methods described in the present disclosure.

[0135] The above description is only a preferred embodiment of the present disclosure and an explanation of the technical principles applied. Those skilled in the art should understand that the scope of the invention involved in the present disclosure is not limited to the technical solutions formed by the specific combination of the above technical features, and should also cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the inventive concept. For example, the technical solutions formed by mutually replacing the above features with the technical features (but not limited to) having similar functions disclosed in the present disclosure.

Claims

1. A method for splitting a monolithic application into microservices based on SOA, characterized in that Including: Output information to prompt the operator to import the source file, and after the source file is successfully imported, scan the imported source file to obtain relevant information of the source file; The relevant information includes the storage path of the source file, the file type of the source file, and the package name; Divide all source files into different services according to the pre-configured information; When the source file is a code file, analyze all class references from the source file to obtain the source code class path, reference class path, reference class method, and reference method frequency, as the code dependency analysis result; When the source file is a database file, determine all introduced table names and the operation types for the table names from the database file; determine the main table from all introduced tables, determine other tables as associated tables, and store the service to which the database file belongs, as well as the main table, associated tables, and table usage frequency determined from the database file, as the database table dependency analysis result; By comprehensively quantifying the code dependency analysis result and the database table dependency analysis result, and presenting the service division result obtained from the comprehensive quantification as a two-dimensional matrix, where the vertical axis represents the calling service, the horizontal axis represents the referenced service, and the value at the intersection of the vertical axis and the horizontal axis represents the number of references; The numerical value at the intersection is associated with and stores detailed information, which includes the service to which the source code belongs, the source code path, the dependent service, the reference class path, the reference method, the reference method frequency, the associated table, and the association frequency; Adjust the directory structure and code hierarchical structure of the source file with a monolithic structure according to the service division result of the previous step; According to the service division result of the previous step, export the database tables of the monolithic application and the data into database files by service.

2. The method according to claim 1, wherein The method further includes: After comprehensively quantifying the code dependency analysis result and the database table dependency analysis result, perform manual adjustment on the code dependency analysis result and the database table dependency analysis result; among them, when the service division result is modified, it triggers the code analysis operation and updates the comprehensive quantification analysis result at the same time.

3. The method according to claim 1, characterized in that When the source file is a code file, analyze all class references from the source file to obtain the source code class path, reference class path, reference class method, and reference method frequency, as the code dependency analysis result, including: When the file type of the source file is a JAVA file, perform abstract syntax tree analysis on the source code file. By parsing all class references that import the source code included in each node of the syntax tree, excluding the class references with the same package name as the source code file, store the source code class path, reference class path, reference class method, and reference method frequency.

4. The method according to claim 1, wherein When the source file is a database file, determine all introduced table names and the operation types for the table names from the database file; determine the main table from all introduced tables, determine other tables as associated tables, and store the service to which the database file belongs, as well as the main table, associated tables, and table usage frequency determined from the database file, as the database table dependency analysis result, including: When the source file is an SQL file, analyze all introduced table names in the SQL file and record the operation type. Determine the main table according to the following rules: Determine the database table with table operation types including CREATE, UPDATE, or DELETE as the main table of the SQL file, and other tables as associated tables; If all table operation types are of the SELECT type, determine the main table according to the usage frequency of the tables. The table with the highest frequency is the main table, and the others are all associated tables.

5. An apparatus for splitting a SOA monolithic application into microservices, characterized in that, Including: An output module, configured to output information prompting the operator to import the source file, and after the source file is successfully imported, scan the imported source file to obtain relevant information of the source file; the relevant information includes the storage path of the source file, the file type of the source file, and the package name; A division module, configured to divide all source files into different services according to pre-configured information; A first analysis module, configured to, when the source file is a code file, analyze all class references from the source file to obtain the source code class path, the reference class path, the reference class method, and the reference method frequency, as the code dependency analysis result; A second analysis module, configured to, when the source file is a database file, determine all introduced table names and the operation types for the table names from the database file; determine the main table from all the introduced tables, determine other tables as associated tables, and store the service to which the database file belongs, as well as the main table, associated tables, and the usage frequency of the tables determined from the database file correspondingly, as the database table dependency analysis result; A quantification module, configured to comprehensively quantify the code dependency analysis result and the database table dependency analysis result, and display the service division result obtained from the comprehensive quantification as a two-dimensional matrix, where the vertical axis represents the calling service, the horizontal axis represents the referenced service, and the value at the intersection of the vertical axis and the horizontal axis represents the number of references; The value at the intersection is associated with and stores detailed information, which includes the service to which the source code belongs, the source code path, the dependent service, the reference class path, the reference method, the reference method frequency, the associated table, and the associated frequency; An adjustment module, configured to adjust the directory structure and the code hierarchical structure of the source file with a monolithic structure according to the service division result of the previous step; An export module, configured to export the database tables of the monolithic application into database files by service according to the service division result of the previous step, together with the database tables and data.

6. A system for splitting a monolithic application into microservices based on SOA, characterized in that Including: An input and display part, an analysis part, and a splitting part; The input and display part includes: a display module, an information input module, a calibration module, and an export module; The analysis part includes a service division module, a code dependency analysis module, a database table dependency analysis module, and a comprehensive quantification analysis module; The splitting part includes a code splitting module and a database splitting module, where: The display module is responsible for displaying all the information that all users can operate and providing a visual and wizard-style operation function; display the list of optional services in an external device by calling the service division module; The information input module is used to input the control and usage information of the user, and at the same time provide the input and interaction of basic information required in the microservice splitting process; all operations in the information input module will be directly output visually through the display module; through the information input module, various configurations in the microservice splitting process can be managed, facilitating visual manual intervention; The export module is responsible for exporting the service division results into an Excel file, and is also responsible for exporting the quantitative analysis results into an Excel file; The calibration module is responsible for manually adjusting the service division results and the comprehensive quantitative analysis results. The adjustment interface provides a batch adjustment function; The service division module is used to configure the configuration information for dividing services. The database tables are divided using the table name prefix, and the source code is divided using the package name prefix; the source files are divided into each service according to the pre-configured configuration information; after the service division is completed, the calibration module is used to manually adjust the service division results; The code dependency analysis module is responsible for analyzing the call relationships between all classes in the source code and classes in other package names, and detailedly recording the file location, class path, line number where the calling code is located, and the path and method of the called class, etc.; The database table dependency analysis module is responsible for analyzing the database tables used in the SQL statements in the source files, and recording the file path and database table information of the user; The comprehensive quantitative analysis module is used to analyze the dependency relationships between each service and other services based on the code dependency analysis results and the database table dependency analysis results. The analysis results are presented as a two-dimensional matrix, where the vertical axis represents the calling service, the horizontal axis represents the referenced service, and the value at the intersection of the vertical axis and the horizontal axis represents the number of references; The code splitting module is responsible for splitting the code into the corresponding folders of each service according to the service division results; The database splitting module is responsible for exporting the database tables and data into database files according to the service division results.

7. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored on the memory. Among them, the processor executes the computer program to implement the method described in any one of claims 1-4.

8. A computer-readable storage medium having computer instructions stored thereon, characterized in that, When the computer instruction is executed by the processor, it implements the method described in any one of claims 1-4.

9. A computer program product comprising computer instructions, characterized in that, When the computer instruction is executed by the processor, it implements the method described in any one of claims 1-4.

Images