A microservice splitting method based on system characteristics

Abstract

This invention relates to a microservice decomposition method based on system characteristics and a microservice decomposition framework that generates a node attribute network based on system characteristics. This invention combines dynamic and static analysis techniques for software systems to obtain comprehensive system characteristics, then establishes a corresponding node attribute network and performs visual decomposition. This invention creates a node association matrix by analyzing the decomposition results of different system characteristics. After clustering these nodes, it optimizes the results using the NSGA-II algorithm to obtain the final microservice candidates. Experiments demonstrate that this invention can provide effective microservice candidates with higher cohesion and density than other advanced microservice decomposition methods.

Description

Technical Field

[0001] The present invention belongs to the field of software engineering microservice architecture, and specifically relates to a microservice splitting method based on system characteristics. Background Art

[0002] In recent years, cloud native has been a hot topic in industry and academia. The Cloud Native Computing Foundation (CNCF) defines cloud native as a cloud-based technology architecture that encompasses key technologies such as containers, microservices, service meshes, and immutable infrastructure. Cloud native applications offer advantages such as rapid deployment, continuous delivery, continuous integration, high reliability, scalability, and elasticity. Cloud native improves the agility and productivity of IT companies in product development, achieving the goal of balancing high reliability with low costs. It has seen rapid growth in the industry, with major companies such as Netflix, Facebook, and Twitter abroad, and Alibaba, Huawei, and Tencent in China migrating to cloud native architectures, particularly microservices. Microservices enable monolithic applications to fully leverage the advantages of the cloud environment, support technological heterogeneity, improve system adaptability to technological development, and shorten system delivery time. Therefore, refactoring monolithic applications into microservices of appropriate granularity is a current research hotspot.

[0003] Existing microservice refactoring methods can be categorized into four main types: First, microservice decomposition based on domain-driven design. This approach, grounded in object-oriented thinking and starting from the business, reflects the system's abstractions through domain models, resulting in a reasonable service decomposition. However, when analyzing bounded contexts, it relies too heavily on domain experts. Otherwise, a correct domain model cannot be established, resulting in unclear boundaries between the decomposed microservices. Second, microservice decomposition based on system business. This approach decomposes microservices based on the business handled by the monolithic system. However, identifying business capabilities and services requires considerable time and understanding of the business, and often relies on the subjective experience of the system architect. Third, microservice decomposition based on functional and non-functional requirements utilizes information such as the monolithic system's API interfaces and URI resources to achieve refactoring. This approach only considers functional or non-functional factors, which can lead to discrepancies between the decomposed microservices and the intended microservices, such as load imbalance. Fourth, microservice decomposition utilizes the monolithic system's coupling, cohesion, and version information to assess the relationships between system elements (such as classes and packages), analyzing system characteristics to achieve microservice decomposition. However, if we only analyze a single static or (and) dynamic feature of the system, the split microservices may not be comprehensive enough. The microservice splitting that can meet specific needs cannot be widely used in the software field.

[0004] From an efficiency perspective, existing microservice splitting methods can be categorized as non-automated splitting (split microservices based on domain-driven design, split microservices based on system business), semi-automated splitting, and automated splitting (split microservices based on functional and non-functional requirements, split microservices based on internal system characteristics). Non-automated microservice splitting methods can tailor splitting to different migration requirements and provide corresponding microservice candidates. However, the entire splitting process relies on domain experts or architects, which limits the splitting and reduces efficiency. Semi-automated and automated microservice splitting methods can only meet specific microservice splitting requirements and cannot provide generalized microservice splitting results for different application domains. However, the requirements of monolithic applications in different application domains when migrating to a microservices architecture are often multifaceted and focused on different priorities. For example, the communications and information services domain focuses on system performance and cost, while the financial domain prioritizes system security and reliability.

[0005] Currently, the industry primarily uses non-automated splitting methods to migrate monolithic systems to a microservices architecture. While these methods offer flexible, domain-specific splitting, the resulting split may not accurately meet migration requirements, and IT companies incur significant human and time costs. Semi-automated and automated microservice splitting methods offer objective and efficient splitting, but lack domain-specific flexibility. If IT companies blindly use microservice splitting methods, they may waste significant resources without generating a suitable microservices design, increasing the difficulty of subsequent microservice implementation, expansion, and maintenance. This deprives them of the benefits of a microservices architecture while simultaneously facing significant financial losses. The consequences of this risk of failure are unbearable for small and medium-sized IT companies. Summary of the Invention

[0006] The present invention is aimed at the problems existing in the existing technology and provides a microservice splitting method based on system characteristics. The purpose of this technical solution is to solve the shortcomings of the existing microservice splitting technology. The present invention can still be used for microservice splitting in the absence of relevant documentation for single applications.

[0007] To achieve the above objectives, the technical solution of the present invention is as follows: a microservice splitting method based on system characteristics, the method comprising the following steps:

[0008] Step S1: For the code program of the single system, use a combination of dynamic analysis and static analysis techniques to obtain the characteristic information of the system at the method granularity level. Dynamic analysis can better reflect the flow details of the system business. Therefore, the data obtained by dynamic analysis is mainly used, and the data of static analysis is supplemented to create a node attribute network corresponding to the single system. This network is marked as G;

[0009] Step S2: For the node attribute network G obtained in step S1, use the classic community detection algorithm to divide its topological structure, obtain the results of splitting from the perspective of system functional characteristics, and then use the clustering algorithm to cluster the different attribute data of the nodes of G respectively, and obtain the results of splitting from the perspective of system non-functional characteristics (performance), communication structure and organizational structure, and mark the above split results as Pf, Pt, Pa, and Pw respectively;

[0010] Step S3: Using the results of splitting G under different system characteristics generated in step S2, analyze the correlation between the nodes in G and establish node correlation matrices under different system characteristics, which are represented as corr_Pf, corr_Pt, corr_Pa, and corr_Pw respectively. Based on the above four matrices, create a comprehensive node correlation matrix, represented as corr_Matrix. Then use a clustering algorithm based on a similarity matrix to cluster the nodes in corr_Matrix, placing related network nodes, that is, entity methods, in one cluster, and assigning unrelated nodes to different clusters to obtain preliminary microservice candidate results;

[0011] Step S4: Use the NSGA-II multi-objective optimization algorithm to improve the microservice candidates obtained in step S3 to generate a microservice splitting result with higher quality.

[0012] As an improvement of the present invention, the software system dynamic and static analysis tools in step S1 respectively use Kieker and java-callgraph to collect the dynamic and static behavior characteristics of the entity methods of the monomer system, specifically including the calling relationship, number of calls, response time and developer of the entity methods. The unified format of the generated system feature data is represented as These entities represent the calling method e, the average response time of e, the submitter of e, the called method f, the average response time of f, the submitter of f, and the interaction frequency between e and f. These entity methods constitute the nodes of G, the calling relationships between methods constitute the directed edges of G, and the characteristics of the methods constitute the attributes of the nodes of G.

[0013] As an improvement of the present invention, the division of the topological structure of G in step S2 needs to ignore the attributes of the nodes of G. In the division of the attributes of the nodes of G, the response time attribute of the node is used as a reference for measuring the non-functional characteristics (performance) of the system, the number of calls attribute of the node is used to evaluate the communication structure of the system, and the development author attribute of the node reflects the organizational structure of the system.

[0014] As an improvement of the present invention, in step S3, a weight parameter is added before the correlation matrix constructed by the results of the feature splitting of different systems to help different fields to migrate flexibly as needed, specifically:

[0015] corr_Matrix=α*corr_Pf+βcorr_Pt+γ*corr_Pa+δ*corr_Pw, where the values ​​of α, β, γ and δ are set by the architect as needed considering the importance of different system features, and α+β+γ+δ=1.

[0016] The above process is primarily due to the fact that when implementing domain-specific microservice decomposition, the characteristics of monolithic systems in different domains vary during reconstruction, potentially emphasizing certain characteristics while ignoring others. For example, when migrating to microservices, software systems in the commercial sector tend to prioritize business and performance over team organization and communication structures. Therefore, a domain-specific microservice decomposition framework needs to comprehensively consider the characteristics of different systems and provide suitable microservice candidates.

[0017] After completing the initial split, the NSGA-II multi-objective optimization algorithm is used to improve the quality of the microservice candidates, ensuring they adhere to the design principle of high cohesion and low coupling. Specifically, modularity is used as one of the optimization objectives to achieve a split with close internal connections and clear external boundaries for the microservice candidates. Referring to the definitions of fan-in coupling and fan-out coupling, the method of counting method calls between microservice candidates is used to measure the frequency of interaction between the two microservices and determine their degree of coupling.

[0018] As an improvement of the present invention, the objective functions Modularity and NoMC used in step S4 are:

[0019]

[0020]

[0021] Where p is the number of divided communities, 1≤u≤p, 1≤v≤p, M_Eu represents the number of edges within community u, M_Mu represents the number of entity methods contained in community u, M_Mv represents the number of entity methods contained in community v, and M_Eu,v represents the number of edges between communities u and v.

[0022] Compared to manual splitting, the present invention uses dynamic and static software analysis techniques to obtain system feature information from a monolith and utilizes community detection and machine learning algorithms to recommend microservice candidates. This domain-specific splitting improves efficiency while also providing objective splitting results. Compared to existing technologies, the present invention decomposes the complex microservice splitting task into two subtasks: splitting the node attribute network and performing multi-objective optimization based on the system features of interest in different domains. Corresponding splitting algorithms and objective functions are designed to improve the cohesion and coupling of microservice candidates. By mapping the behavioral characteristics of the monolithic system at the method granularity level to the node attribute network, detailed system information can be analyzed and visually split, achieving a balance between effectiveness and rationality, resulting in higher-quality microservice candidates and reducing the risk of failure caused by inappropriate splitting. Furthermore, based on the developer attributes of nodes in the node attribute network mapped from the monolithic system, corresponding recommendations for microservice candidate developers can be made, helping to address team organization issues encountered during monolithic system reconstruction and promoting the application of the present invention in industrial projects. Finally, the framework of the present invention is highly flexible and universal; its backbone and even the entire splitting framework can be adopted by other corresponding frameworks. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 It is a schematic diagram of the overall process of the present invention;

[0024] Figure 2 Schematic diagram of the data collection process of the present invention;

[0025] Figure 3 Schematic diagram of the node attribute network structure in the embodiment. DETAILED DESCRIPTION

[0026] In order to deepen the understanding of the present invention, this embodiment is described in detail below with reference to the accompanying drawings.

[0027] Example 1: Figure 1 As shown, the microservice splitting method based on system characteristics of the present invention includes the following steps:

[0028] Step (1): Given a single application with separated front-end and back-end, use a combination of dynamic analysis and static analysis techniques to obtain the entity method behavior feature data of the single application, and map the data to a node attribute network with dynamic data as the main and static data as the supplement. The node attribute network is marked as G.

[0029] Step (2): For G obtained in step (1), use community detection algorithm and clustering algorithm to divide its topological structure and attribute data, obtain the results of the split from the perspective of system non-functional characteristics (performance), communication structure and organizational structure, and mark the above split results as Pf, Pt, Pa, Pw respectively. Different split results reflect the degree of association between nodes under different system characteristics;

[0030] Step (3): Use the different splitting results obtained in step (2) to create node correlation matrices, denoted as corr_Pf, corr_Pt, corr_Pa, and corr_Pw. Based on the above four matrices, set the importance of different features as needed to create a comprehensive node correlation matrix, denoted as corr_Matrix. Finally, use the clustering algorithm based on the similarity matrix to cluster the corr_Matrix and obtain preliminary microservice candidate results.

[0031] Step (4): Use the NSGA-II multi-objective optimization algorithm to improve the splitting result obtained in step (3) to generate a microservice splitting result with higher quality.

[0032] This invention is based on the task of achieving domain-oriented microservice splitting. It uses dynamic and static analysis techniques of software systems to generate relatively comprehensive entity method behavior characteristics of monolithic applications. This data is mapped to a node attribute network to intuitively display the system information of the monolithic application and perform visual splitting. After analyzing the system split results under different system characteristics, the weight parameters of the system characteristics can be set as needed to create a comprehensive association matrix, which is then clustered to generate preliminary microservice candidates. Finally, a multi-objective optimization algorithm is used to improve the results, enhance the internal independence of microservice candidates, reduce the external coupling of microservice candidates, and achieve flexible and high-quality microservice candidates for the domain.

[0033] like Figure 2 As shown in the figure, the data collection process of the present invention includes two steps: dynamic analysis and static analysis. After collecting the data, duplicate records in the static data are deleted based on the dynamic data, and interaction frequency and average response time elements are added to the static data, with their values ​​set to 1 and 0 by default. Then, the code hosting system is used to manage the single application, analyze its historical version information, and obtain the latest submission author information corresponding to each entity method. Finally, the data in a unified format is merged to create the corresponding node attribute network, as shown in the figure. Figure 3 shown.

[0034] Example 2:

[0035] This example uses the JPetStore application. JPetStore is a classic monolithic application that is often used as a verification project for microservice decomposition methods.

[0036] JPetStore is a web application based on Mybatis 3, Spring 3, and Stripes technologies. It follows a classic three-tier architecture consisting of a business layer, a presentation layer, and a data layer. It consists of 2,059 lines of code and 24 classes. The project's business layer is unclear, and its scalability and maintainability are low if business growth surges, making it suitable for refactoring into microservices. The parameters of the NSGA-II algorithm used in this implementation are as follows: the population size is set to 40, the crossover rate is 1, the mutation rate is 0.125, and the number of iterations is 150. The number of microservices in JPetStore is set to 4, and the number of genes in each individual ranges from 1 to 4.

[0037] To facilitate quantitative evaluation, this embodiment uses three evaluation indicators, where k is the number of microservice candidates, M_Mi is the number of entity methods contained in microservice i, M_Mj is the number of entity methods contained in microservice j, and M_Ei is the number of edges contained in microservice i.

[0038] (1) M_Ch (Cohesion in method-level) is used to measure the average connection density within the microservice candidate object based on the method granularity to reflect the functional cohesion and performance similarity of the current service object. It is a variant of connectivity in system components. The value of M_Ch ranges from 0 to 1. When there is no connection between the entity methods in the microservice candidate object, the value of M_Ch is 0. M_Ch is defined as:

[0039]

[0040] (2) The M_Cp (Coupling at method-level) metric is used to measure the average connection sparsity coupling between microservice candidate objects based on method granularity, reflecting the functional coupling and performance differences of the current service objects. It is a variant of the interconnection between system components. The value of M_Cp ranges from 0 to 1. When there is no relationship between microservice candidate objects, the value of M_Cp is 0. M_Cp is defined as:

[0041]

[0042] (3) Density is used to indicate the degree of correlation within each microservice candidate. The Density formula is as follows:

[0043]

[0044] Where E represents the total number of edges in the microservice splitting result. A higher density value indicates a better microservice splitting quality.

[0045] Example 3:

[0046] The technical solution of the present invention is compared with other existing microservice splitting technologies.

[0047] This example compares the results of the technical solution of the present invention with four other microservice splitting methods.

[0048] The comparison methods include the baseline method (manual splitting), functional-oriented microservice candidate identification (FoSCI), denoted as comparison method 1, the dataflow-driven method (DFD), denoted as comparison method 2, and the method of using a neural network model (code2vec) to create code embeddings from the source code of a monolithic application to achieve microservice splitting, denoted as comparison method 3. All results are generated from the code provided by the authors.

[0049] Quantitative comparison:

[0050] The specific comparative test results of this embodiment are shown in Table 1. Compared with the baseline method and other splitting methods, the method of the present invention outperforms other methods in terms of evaluation metrics. Compared with the best-performing comparison method 2, it improves the M_Ch metric by 1.35% and the Density metric by 10.14%, while maintaining consistency in the M_Cp metric. This verifies that the microservice splitting framework proposed in this paper can generate effective microservice candidates.

[0051] Table 1 Schematic diagram of comparison of evaluation indicators

[0052]

[0053] Qualitative evaluation:

[0054] The comparison results show that the proposed method significantly improves upon the baseline methods across all evaluation metrics. While both methods can perform domain-specific microservice splitting, the baseline methods are susceptible to the subjective thinking of the architect. The proposed method, on the other hand, can scientifically and efficiently perform microservice splitting tailored to the system requirements of different domains, facilitating the reconstruction of monolithic systems. The proposed method shares the same advantages as Comparative Methods 1 and 2 in terms of the M_Cp metric, demonstrating that all three methods effectively achieve loose coupling between microservices when used for monolithic system reconstruction, providing microservice candidates with independent business functions. All methods use system business analysis as the basis for splitting, effectively achieving the independence of microservice responsibilities. However, the proposed method significantly outperforms the other comparative methods in terms of M_Ch and Density. The proposed method leverages detailed system information to achieve effective microservice splitting, effectively meeting the splitting requirements of different domains. Comparative Method 3 performed poorly during the verification process because its microservice splitting based on semantic similarity in code relies on the strict adherence to standard coding standards during the development of the monolithic system. Inaccurate variable naming in the system source code during development can significantly negatively impact the splitting results.

[0055] It can be seen from the above embodiments that the method of the present invention can effectively alleviate the problem of the lack of a more efficient domain-oriented monolithic system reconstruction method, and reduce the risk of failure due to inappropriate decomposition during the actual migration of microservices.

[0056] It should be noted that the above embodiments are not intended to limit the scope of protection of the present invention, and equivalent changes or substitutions made on the basis of the above technical solutions fall within the scope of protection of the claims of the present invention.

Claims

1. A microservice splitting method based on system characteristics, characterized in that: The method comprises the following steps: Step S1: For the code program of the single system, use a combination of dynamic analysis and static analysis techniques to obtain the characteristic information of the system at the method granularity level. Dynamic analysis can better reflect the flow details of the system business. Therefore, the data obtained by dynamic analysis is mainly used, and the data of static analysis is supplemented to create a node attribute network corresponding to the single system. This network is marked as G; Step S2: For the node attribute network G obtained in step S1, use the classic community detection algorithm to divide its topological structure, obtain the results of splitting from the perspective of system functional characteristics, and then use the clustering algorithm to cluster the different attribute data of the nodes of G respectively, obtain the results of splitting from the perspective of system non-functional characteristics, communication structure and organizational structure, and mark the above split results as Pf, Pt, Pa, and Pw respectively; Step S3: Using the results of splitting G under different system characteristics generated in step S2, analyze the correlation density between nodes in G and establish node correlation matrices under different system characteristics, which are represented as corr_Pf, corr_Pt, corr_Pa and corr_Pw respectively. Based on the above four matrices, create a comprehensive node correlation matrix, represented as corr_Matrix. Then, use a clustering algorithm based on similarity matrix to cluster the nodes in corr_Matrix, placing related network nodes, that is, entity methods, in one cluster, and assigning unrelated nodes to different clusters to obtain preliminary microservice candidate results. Step S4: Use the NSGA-II multi-objective optimization algorithm to improve the microservice candidates obtained in step S3 to generate a microservice splitting result with higher quality; In step S1, the software system dynamic and static analysis tools use Kieker and java-callgraph to collect the dynamic and static behavior characteristics of the entity methods of the monomer system, including the calling relationship, number of calls, response time and development author of the entity methods. The unified format of the generated system feature data is expressed as follows: They represent the calling method e, the average response time of e, the submitter of e, the called method f, the average response time of f, the submitter of f, and the interaction frequency of e calling f respectively. These entity methods constitute the nodes of G, the calling relationships between methods constitute the directed edges of G, and the characteristics of the methods constitute the attributes of the nodes of G; The division of the topological structure of G in step S2 needs to ignore the attributes of the nodes of G. In the division of the attributes of the nodes of G, the response time attribute of the node is used as a reference for measuring the non-functional characteristics of the system, the call count attribute of the node is used to evaluate the communication structure of the system, and the developer attribute of the node reflects the organizational structure of the system. In step S3, weight parameters are added before the correlation matrix constructed by the results of the feature splitting of different systems to help different fields to migrate flexibly as needed, specifically: corr_Matrix=α*corr_Pf+β*corr_Pt+γ*corr_Pa+δ*corr_Pw, where the values ​​of α, β, γ and δ are set by the architect as needed considering the importance of different system features, and α+β+γ+δ=1.

2. The microservice splitting method according to claim 1 is characterized in that: The objective functions Modularity and NoMC used in step S4 are: Among them, p is the number of divided communities, 1≤u≤p, 1≤v≤p, M_E u represents the number of edges within community u, M_M u Indicates the number of entity methods contained in community u, M_E u,v It represents the number of edges between community u and community v.

Images