Candidate microservice identification method and system based on gravity map clustering

Abstract

The application provides a candidate micro-service identification method and system based on gravity map clustering, constructs a class relationship graph, fully considers the trade-off between the design principle of the micro-service and the performance of the reconstructed system, clusters the constructed class relationship graph according to the diversity of user requirements, and the obtained initial candidate micro-service set can be highly consistent with the actual requirements of the user, thereby providing more optimized support for the application and maximizing the business target and user value.

Description

TECHNICAL FIELD

[0001] The application belongs to the related technical field of microservice identification, and particularly relates to a candidate microservice identification method and system based on a gravity diagram clustering. BACKGROUND

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

[0003] Due to the advantages of strong scalability, fast update iteration, high reliability and the like of the microservice architecture and the problems such as slow startup speed and poor scalability faced in the operation and maintenance process of the monolithic architecture system, more and more enterprises gradually migrate their monolithic architecture systems to the microservice architecture. In the process of refactoring the monolithic architecture into the microservice architecture, accurate candidate microservice identification can help developers efficiently complete the migration work.

[0004] For how to refactor the monolithic architecture into the microservice architecture, some developers completely abandon the original monolithic architecture and start to build a new application based on the microservice architecture, but this not only has a huge workload, but also has a great risk of failure. To solve this problem, researchers have proposed different methods to automatically identify service candidates, such as a data flow driven method and a service candidate identification framework based on service execution trajectory. However, most of the researches on migrating the monolithic architecture to the microservice architecture start from the design principles of the microservice (such as fine granularity, low coupling, and single responsibility), without considering the application scenarios of the system and the actual needs of the users for the refactored system.

[0005] In the actual refactoring process, different enterprises have different requirements and indicators for the refactored microservice, and the refactoring should not be simply based on the design principles of the microservice, but should consider the characteristics of the system and the needs of the developers for the refactored system. For example, for some Internet companies with frequent business changes and large user base, they need high reliability and flexibility of the refactored system, which requires the monolithic architecture system to be split into smaller granularity microservices, and for traditional enterprises with stable business and high performance requirements, they may need higher manageability and performance, which may require the monolithic architecture system to be split into larger granularity microservices.

[0006] In summary, in the process of refactoring the monolithic architecture into the microservice architecture, the application scenarios of the system and the actual needs of the users for the refactored system are not considered, resulting in the refactored microservice architecture not meeting the needs of the users. SUMMARY

[0007] In order to overcome the above deficiencies of the prior art, the application provides a candidate microservice identification method and system based on gravity diagram clustering, which considers the trade-off between the design principles of microservices and the performance of the reconstructed system, dynamically clusters the constructed class relationship diagram according to the diversity of user requirements, and identifies a candidate microservice set meeting the user requirements.

[0008] In order to achieve the above purpose, the application adopts the following technical solutions:

[0009] In the first aspect, the application provides a candidate microservice identification method based on gravity diagram clustering, comprising:

[0010] obtaining system data of an original monolithic architecture; wherein the system data comprises source code, running logs and commit history data;

[0011] based on the obtained system data of the original monolithic architecture, representing class entities in the source code as vertices and representing the association relationship between the class entities as edges to construct a class relationship diagram;

[0012] based on the trade-off requirement of the user between the design principles of microservices and the performance of the reconstructed system, clustering the constructed class relationship diagram through a gravity diagram clustering algorithm to obtain an initial candidate microservice set;

[0013] splitting or merging the services with abnormal granularity in the initial candidate microservice set to eliminate the outlier data in the initial candidate microservice set, and obtaining a final candidate microservice set.

[0014] In the second aspect, the application provides a candidate microservice identification system based on gravity diagram clustering, comprising:

[0015] a data acquisition module configured to obtain system data of an original monolithic architecture; wherein the system data comprises source code, running logs and commit history data;

[0016] a diagram construction module configured to represent class entities in the source code as vertices and represent the association relationship between the class entities as edges based on the obtained system data of the original monolithic architecture to construct a class relationship diagram;

[0017] a diagram clustering module configured to cluster the constructed class relationship diagram through a gravity diagram clustering algorithm based on the trade-off requirement of the user between the design principles of microservices and the performance of the reconstructed system to obtain an initial candidate microservice set;

[0018] an optimization adjustment module configured to split or merge the services with abnormal granularity in the initial candidate microservice set to eliminate the outlier data in the initial candidate microservice set, and obtain a final candidate microservice set.

[0019] In a third aspect, the present application provides an electronic device comprising a memory and a processor, and computer instructions stored in the memory and running on the processor, when the computer instructions are run by the processor, the method of the first aspect is completed.

[0020] In a fourth aspect, the present application provides a computer readable storage medium for storing computer instructions, when the computer instructions are executed by a processor, the method of the first aspect is completed.

[0021] The above one or more technical solutions have the following beneficial effects:

[0022] In the present application, the class relationship diagram is constructed, the trade-off between the design principle of microservices and the performance of the reconstructed system is fully considered, the constructed class relationship diagram is clustered according to the diversity of user demand, and the obtained initial candidate microservice set is highly consistent with the actual demand of users, so that more optimized support is provided for the application, and the maximization of business goals and user value is realized.

[0023] In the present application, the candidate microservices are automatically identified through the source code, running logs and submission history of the original monomer architecture, the efficiency of migrating from the monomer architecture to the microservice architecture is improved, and the complexity and error rate of manual analysis are effectively reduced.

[0024] The advantages of the additional aspects of the present application will be partially given in the following description, partially will become obvious from the following description, or will be known by the practice of the present application. BRIEF DESCRIPTION OF DRAWINGS

[0025] The drawings accompanying the specification of the present application form a part thereof and serve to provide further understanding of the present application, the illustrative embodiments of the present application and its description serve to explain the present application, and do not constitute improper limitations on the present application.

[0026] Figure 1 A whole flowchart of a candidate microservice identification based on gravity diagram clustering in the embodiment one of the present application is shown in the figure.

[0027] Figure 2 A system architecture diagram of a candidate microservice identification based on gravity diagram clustering in the embodiment two of the present application is shown in the figure. DETAILED DESCRIPTION

[0028] It should be noted that the following detailed description is exemplary, and is intended to provide further explanation of the present application. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as generally understood by those skilled in the art to which the present application belongs.

[0029] It should be noted that the terms used herein are only for the purpose of describing the specific embodiments, and are not intended to limit the exemplary embodiments according to the present application.

[0030] In the case of no conflict, the embodiments in the present application and the features in the embodiments can be combined with each other.

[0031] Embodiment one

[0032] The embodiment discloses a candidate microservice identification method based on gravity map clustering, comprising:

[0033] Obtaining system data of the original monolithic architecture; wherein the system data includes source code, running logs, and commit history information data;

[0034] Based on the obtained system data of the original monolithic architecture, the class entities in the source code are represented as vertices, and the association relationship between the class entities is represented as edges, to construct a class relationship graph; wherein the association relationship between the class entities includes the class relationship in the source code, that is, the extends relationship or the implements relationship between the classes, the method invocation relationship in the execution logs, and the common modification relationship in the commit history;

[0035] Based on the trade-off requirement between the user's design principle of microservice and the performance of the reconstructed system, the class relationship graph constructed is clustered through a gravity map clustering algorithm to obtain an initial candidate microservice set;

[0036] Splitting or merging the services with abnormal granularity in the initial candidate microservice set, to eliminate the outlier data in the initial candidate microservice set, and obtain a final candidate microservice set.

[0037] The embodiment identifies the candidate microservice through the system data of the original monolithic architecture, improves the efficiency of migrating from the monolithic architecture to the microservice architecture, and effectively reduces the complexity and error rate of manual analysis; the embodiment fully considers the trade-off between the design principle of microservice and the performance of the reconstructed system, considers the diversity of user demand, and comprehensively considers the key factors such as service maintainability, reliability, and response speed, so that the identified candidate microservice can be highly consistent with the actual demand of the user, thereby providing more optimized support for the application and maximizing the business goal and user value.

[0038] The following will be combined Figure 1 The candidate microservice identification method based on gravity map clustering proposed in the embodiment will be described in detail, specifically comprising:

[0039] Step 1: obtaining system data of the original monolithic architecture; wherein the system data includes source code, running logs, and commit history information data.

[0040] In this embodiment, the system data extraction of the original monolithic architecture includes three parts: source code, operation log and submission history. Among them, the source code part directly extracts the code file of the original monolithic system and analyzes its code class information, belonging functions, number of code lines, class relationship and calling information between methods, etc.; the operation log information is based on the tracking tool (such as kiker) to analyze the operation log and call trace information generated after the operation of the original system, and extract the calling information between methods; the submission history data is based on the source code version management system (such as git, SVN and other tools) to collect the submission history data of the system to analyze and extract the code file information that is jointly modified during each submission.

[0041] Of course, in other embodiments, the monitoring tool is not limited to the examples given above.

[0042] Similarly, in some embodiments, data such as operation logs and submission history can also be obtained from other channels.

[0043] Step 2: Based on the obtained system data of the original monolithic architecture, class entities in the source code are represented as vertices, and the association relationships between class entities are represented as edges to construct a class relationship graph.

[0044] In step 2, specifically including: abstracting all classes of the original monolithic architecture system into a vertex set V = {v1, v2, ..., v n}, where n is the number of classes in the original monolithic architecture system, v n Represents the nth class entity in the original monolithic architecture.

[0045] For each vertex, analyze its size and function, and randomly initialize its position in the two-dimensional coordinate system. Therefore, for any vertex v in the vertex set V i , which can be expressed as: i {s i , f i ,(x i ,y i )}, where s i Indicates the class size, calculated by the number of lines of code; f i For the function of the class; (x i ,y i ) represents the position of the vertex in the two-dimensional coordinate system.

[0046] Secondly, we analyze the relationship between vertices. The relationship between vertices includes class relationship (extends or implements relationship between classes), method call relationship and common modification relationship. i and v j There is an association relationship between these two vertices, and there is an edge e between them. ij .

[0047] For any edge, the attention is on its connected vertices and weight, so for any edge e ij , it can be represented as: e ij {v i , v j , W ij}. Wherein v i , v j are two elements in vertex set V, representing two vertices of the edge; W ij represents the weight of the edge, which represents the strength of the association between the two vertices. The greater the weight value, the stronger the association between the two vertices.

[0048] For any edge e ij , its weight W ij is composed of class relationship weight, method call relationship weight and common modification relationship weight, that is:

[0049] W ij = We ij +Wf ij +Wc ij (1)

[0050]

[0051]

[0052]

[0053] Wherein Wf ij represents the method call relationship weight, which is based on the analysis of the execution trace in the log; We ij represents the class relationship weight, which is 0 or constant c; Wc ij represents the common modification relationship weight, which is based on the analysis of the commit history; f_num ij is the number of calls between vertices v i , v j in the log, and f_total is the total number of method calls in the log; c_num ij is the number of records containing vertices v i , v j in all commit histories, and c_total is the total number of records.

[0054] Step 3: Based on the trade-off requirements of the user's design principles and the performance of the refactored system, the class relationship graph constructed is clustered by the gravity diagram clustering algorithm to obtain an initial candidate micro-service set.

[0055] In step 3, it specifically includes:

[0056] According to the design principle of microservice fine granularity and single responsibility, there is repulsion between any two vertices, and the size of the repulsion is related to the size of the vertex and the function to which the vertex belongs.

[0057] Specifically, according to the design principle of microservice fine granularity, the size of the repulsion between vertices is proportional to the size of the vertex and inversely proportional to the distance between vertices; according to the design principle of microservice single responsibility, the repulsion between vertices belonging to the same function is smaller than the repulsion between vertices belonging to different functions.

[0058] In summary, for any two vertices v i {s i , f i , (x i , y i )} and v j {s j , f j , (x j , y j )}, the vertex v i experiences repulsion from the vertex v j The size of the repulsion is calculated as follows:

[0059]

[0060] Where g is a constant in the interval [0, 1]; The direction of the repulsion is the direction of the vertex v j pointing to the vertex v i , i.e., the direction of the vector (x i -x j , y i -y j ).

[0061] According to the design principle of high cohesion and low coupling and the user's demand for the performance and management difficulty of the reconstructed system, there is an attractive force between the two vertices of the edge, and the size of the attractive force is related to the weight of the edge, i.e., the association between vertices. To increase the cohesion of services, reduce the coupling between services, and improve the performance of the reconstructed system, the size of the attractive force is proportional to the weight of the edge and proportional to the distance between vertices.

[0062] Specifically, for any two vertices v i {s i , f i , (x i , y i )} and v j {s j , f j , (x j , y​​j )}, if there is an edge e between them ij , then vertex v i Influenced by vertex v j Gravity Its size The calculation formula is as follows

[0063]

[0064] in, The direction is the vertex v in the coordinate system i Point to vertex v j The direction of the vector (x j -x i ,y j -y i ) direction.

[0065] For any vertex v i , the net force it receives For all the repulsive forces acting on it and gravity The weighted vector sum added together is:

[0066]

[0067] Among them, α∈(0,1) is a user-defined parameter, which represents the user's trade-off weight between microservice design principles and refactored performance. When 0<α<0.5, it means that the user pays more attention to microservice design principles, and when 0.5<α<1, it means that the user pays more attention to the performance of the refactored system.

[0068] According to the combined force Vertex v i In the meeting along The distance moved in the direction of the current position is location.

[0069] Through rounds of iterations, vertices move towards vertices that are closely related to themselves. Eventually, clusters of vertices are formed, and vertices with greater dependencies are clustered in the same cluster.

[0070] The result of clustering is the initial set of candidate microservices, namely:

[0071] SC={SC1,SC2,…,SC m}

[0072] in, m represents the number of microservices in the initial candidate microservice set.

[0073] Step 4: Split or merge services with abnormal granularity in the initial candidate microservice set, eliminate outlier data in the initial candidate microservice set, and obtain the final candidate microservice set.

[0074] In step 4, the specific steps for processing outlier data are as follows:

[0075] First, the granularity of the required microservices, the average granularity of the candidate microservice set, and the coupling degree of the candidate microservice set are defined.

[0076] For the candidate microservice set SC = {SC1, SC2, ..., SC m Any candidate microservice set SC in i , the granularity is calculated as follows:

[0077]

[0078] Based on the granularity of all candidate microservices, calculate the average granularity of the candidate microservice set:

[0079]

[0080] The coupling degree of the candidate microservice set is obtained by accumulating the weights of the cross-service edges, that is:

[0081]

[0082]

[0083] Based on the above definition, abnormal candidate microservices are identified and processed.

[0084] First, the granularity of all candidate services in the candidate microservice set is analyzed by the box plot method to find out the outliers and identify the candidate services with abnormal granularity.

[0085] According to the identified abnormal candidate services, the abnormal candidate services are divided into two categories: maximum services and minimum services. According to the box plot, for any candidate service SC i If its granularity is greater than Q3+1.5*IQR, it is called a maximum service; if its granularity is less than Q1-1.5*IQR, it is called a minimum service; among them, Q1 and Q3 represent the first quartile and third quartile of the microservice granularity, and IQR=Q3-Q1.

[0086] Based on the box plot, the maximum service set SCK and the minimum service set SCG in the candidate microservice set SC are obtained.

[0087] In order to adjust the maximum service and the minimum service, the benefit of the adjusted candidate micro-service set is calculated by changing the benefit formula, and the calculation method of the changed benefit score is as follows:

[0088]

[0089] SC" represents the candidate micro-service set before the current maximum service is changed, that is, the candidate micro-service set after the last maximum service optimization, or the candidate micro-service set before the current minimum service is combined, that is, the candidate micro-service set after the last minimum service optimization; SC' represents the candidate micro-service set after the current maximum service is changed, or the candidate micro-service set after the current minimum service is combined.

[0090] For any maximum service SC in the maximum service set SCK k , first of all, it is divided into two candidate micro-services SC kk and SC' kk by the minimum cut algorithm, and for the candidate micro-service set SC" and the changed candidate micro-service set SC' (SC' = SC k - SC kk + SC' kk ), the change benefit score is calculated according to formula (13).

[0091] When score>0, it means that the change is beneficial overall, the changed candidate micro-service set SC' is more suitable for user demand than the candidate micro-service set SC" before the change, and the change can be performed; on the contrary, when score<0, it means that the changed candidate micro-service set becomes worse, and it is more beneficial to keep the candidate micro-service set before the change.

[0092] score>0 means that the granularity of the service is greatly improved, and the coupling degree increased due to service segmentation is also within the user's acceptable range, in which case segmentation is beneficial, and SC' can replace SC". score<0 means that although the service granularity is improved to a certain extent, the inter-service coupling degree is greatly increased, which may affect the performance of the reconstructed system, in which case segmentation is harmful, and SC' cannot replace SC.

[0093] It can be understood that after the first maximum service SC k is segmented, the SC" in formula (13) is the original candidate micro-service set SC when the change benefit score is calculated by formula (13), and after the second maximum service SC k is segmented, the SC" in formula (13) is the first maximum service SC kThe candidate micro-service set after optimization is calculated according to the change benefit, and so on.

[0094] Each maximal service in the maximal service set SCK is processed in sequence by the above method, and finally the candidate micro-service set after optimization of the maximal service is obtained. The execution flow of this part can be represented by the following pseudo code:

[0095]

[0096]

[0097] For the minimal service set SCG, sort it according to granularity, and select the minimal service SC g with the smallest granularity. Calculate the change benefit score of merging it with other candidate micro-services in the candidate micro-service set SC by formula (13), then select the micro-service with the largest score to merge, update the minimal service set SCG and the candidate micro-service set SC after merging, and obtain the merged candidate micro-service set SC"; then select the minimal service SC g with the second smallest granularity. Calculate the change benefit score of merging it with other candidate micro-services in the candidate micro-service set SC" by formula (13), then select the micro-service with the largest score to merge, and so on, repeat the above steps until all minimal services are processed.

[0098] Through the above process, after all the maximal services and minimal services are processed, the final candidate micro-service set SC = {SC1, SC2, …, SC M} is obtained, where M≤m.

[0099] Based on the source code, running logs and commit history of the original monolithic architecture, the original monolithic architecture system is abstracted into a class relationship graph, where the vertex represents the class entity in the source code, and the edge represents the relationship between classes such as dependency, call and common modification; for the constructed graph, based on the user's demand parameters, the initial candidate micro-service set is obtained by using the gravity graph clustering algorithm; the services with abnormal granularity in the initial candidate micro-service set are split or merged, and the outlier data in the initial candidate micro-service set is eliminated, and the final candidate micro-service set is obtained. This method fully considers the trade-off between the design principles of micro-services and the performance of the reconstructed system, and comprehensively considers the key factors such as service maintainability, reliability and response speed according to the diversity of user demand, so that the identified candidate micro-services can be highly consistent with the actual demand of users, thereby providing more optimized support for applications and maximizing business goals and user value.

[0100] Embodiment two

[0101] The purpose of the embodiment is to provide a candidate microservice identification system based on gravity map clustering, comprising:

[0102] A data acquisition module configured to acquire system data of the original monolithic architecture; wherein the system data comprises source code, running logs and commit history data;

[0103] A graph construction module configured to represent class entities in the source code as vertices and represent association relationships between the class entities as edges based on the acquired system data of the original monolithic architecture, and construct a class relationship graph;

[0104] A graph clustering module configured to cluster the constructed class relationship graph through a gravity map clustering algorithm based on user requirements for trade-offs between design principles of microservices and performance of the reconstructed system, and obtain an initial candidate microservice set;

[0105] An optimization adjustment module configured to split or merge services with abnormal granularity in the initial candidate microservice set, eliminate outliers in the initial candidate microservice set, and obtain a final candidate microservice set.

[0106] In more embodiments, there are also provided:

[0107] An electronic device comprising a memory and a processor, and computer instructions stored in the memory and running on the processor, when the computer instructions are run by the processor, the method described in Embodiment I is completed. For brevity, this will not be repeated here.

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

[0109] The memory can include read-only memory and random access memory, and provide instructions and data to the processor, and a part of the memory can also include non-volatile random access memory. For example, the memory can also store device type information.

[0110] A computer readable storage medium for storing computer instructions, when the computer instructions are executed by a processor, the method described in Embodiment I is completed.

[0111] The method in the embodiment one can be directly embodied as being completed by a hardware processor or being completed by a combination of hardware and software modules in the processor. The software modules can be located in a storage medium in the art, such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, an electrically erasable programmable memory, a register, or the like. The storage medium is located in a memory, and the processor reads information in the memory and completes the steps of the above method in combination with the hardware. To avoid repetition, no further detailed description is given here.

[0112] A computer program product includes a computer program, which, when executed by a processor, implements the method described in the embodiment one.

[0113] The present application also provides at least one computer program product tangibly stored on a non-transitory computer readable storage medium. The computer program product includes computer executable instructions, for example, instructions embodied in program modules, executed by devices at the destination, real or virtual processors, to perform processes / methods as described above. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform particular tasks or implement particular abstract data types. In various embodiments, the functions of the program modules can be combined or divided as desired in various embodiments. Machine executable instructions for program modules can be executed within a local or distributed device. In a distributed device, program modules can be located in local and remote storage media.

[0114] Computer program code for carrying out the methods of the present application can be written in one or more programming languages. These computer program codes can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus, so that the program codes, when executed by the computer or other programmable data processing apparatus, cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The program codes can be executed entirely on the computer, partially on the computer, as a standalone software package, partially on the computer and partially on a remote computer, or entirely on a remote computer or server.

[0115] In the context of the present application, computer program code or related data can be carried by any suitable carrier to enable the device, apparatus or processor to perform the various processes and operations described above. Examples of the carrier include a signal, a computer readable medium, and the like. Examples of the signal can include an electrical, optical, radio, sound or other forms of propagated signals, such as a carrier wave, an infrared signal, and the like.

[0116] Those skilled in the art can understand that the units and algorithm steps of each example described in combination with the present embodiment can be realized in electronic hardware or a combination of computer software and electronic hardware. Whether the functions are realized in hardware or software manner depends on the specific application and design constraints of the technical solution. The skilled person can use different methods to realize the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0117] Although the specific embodiments of the present application are described above in combination with the drawings, it is not a limitation on the scope of protection of the present application. Those skilled in the art should understand that various modifications or variations made by those skilled in the art on the basis of the technical solutions of the present application without creative labor are still within the scope of protection of the present application.

Claims

1. A candidate microservice identification method based on gravity graph clustering, characterized in that: include: Obtaining system data of the original monolithic architecture; wherein the system data includes source code, operation logs, and submission history data; the source code is obtained by extracting code files of the original monolithic system and analyzing their code class information, affiliated functions, number of lines of code, class relationships, and inter-method call information; the operation log information is obtained by analyzing the operation logs and call trace information generated by the operation of the original monolithic system using a tracking tool, and extracting inter-method call information; the submission history data is obtained by analyzing the submission history data of the source code version management system and collecting information of the code files that were commonly modified during each submission; Based on the obtained system data of the original monolithic architecture, class entities in the source code are represented as vertices, and the association relationships between class entities are represented as edges to construct a class relationship graph; the association relationships between vertices are determined by the class relationship weights, method call relationship weights, and common modification relationship weights between the vertices; for any two vertices, the corresponding method call relationship weights are obtained by analyzing the execution paths in the log files; for any two vertices, their common modification relationship weights are calculated based on the commit history; Based on the user's trade-off requirements between microservice design principles and system performance after reconstruction, the constructed class relationship graph is clustered using the gravity graph clustering algorithm to obtain the initial candidate microservice set; specifically: Based on the fine-grained microservice design principles and the single-responsibility microservice design principle, the repulsive force between vertices is determined. According to the fine-grained microservice design principle, the conditions that must be met are: the repulsive force between vertices is proportional to the vertex size, and the repulsive force between vertices is inversely proportional to the distance between vertices. According to the single-responsibility microservice design principle, the conditions that must be met are: the repulsive force between vertices with the same function is smaller than the repulsive force between vertices with different functions. To increase service cohesion, reduce coupling between services, and improve the performance of the reconstructed system, the conditions that must be met are: the attractive force between vertices is proportional to the edge weight, and the attractive force between vertices is proportional to the distance between vertices. Determine the attraction between vertices based on the design principle of high cohesion and low coupling and the user's requirements for the reconstructed system; Based on the user's trade-off requirements between microservice design principles and the performance of the reconstructed system, different weights are assigned to the repulsive and attractive forces acting on vertices. Vertex clusters are formed through multiple rounds of iterations to determine the initial set of candidate microservices. Split or merge services with abnormal granularity in the initial candidate microservice set, eliminate outlier data in the initial candidate microservice set, and obtain the final candidate microservice set; specifically: Based on the granularity of candidate microservices in the initial candidate microservice set, abnormal candidate services are identified using a box plot method; wherein the abnormal candidate services include extremely large services and extremely small services; For each of the maximal services, split it into two candidate microservices using a minimum cut algorithm, calculate the change benefit of the candidate microservice set after the split and adjustment, and determine whether the candidate microservice set after the split and adjustment should replace the initial candidate microservice set or the candidate microservice set after the previous maximal service is optimized based on the change benefit of the candidate microservice set after the split and adjustment; Sort the minimal services by granularity, start with the minimal service with the smallest granularity, calculate the change benefits generated by merging it with all other candidate microservices, and determine the merging result of the minimal services based on the change benefits generated by the merging; The calculation method of the change benefit is: in, Represents the set of candidate microservices before the current maximum service is changed, that is, the set of candidate microservices after the previous maximum service is optimized, or the set of candidate microservices before the current minimum service is merged, that is, the set of candidate microservices after the previous minimum service is optimized; Indicates the set of candidate microservices after the current maximum service is changed, or the set of candidate microservices after the current minimum service is merged.

2. A candidate microservice identification system based on gravity graph clustering, characterized by: include: The data acquisition module is configured to: acquire system data of the original monolithic architecture; wherein the system data includes source code, operation logs, and submission history data; the source code is obtained by extracting code files of the original monolithic system and analyzing their code class information, functions, number of lines of code, class relationships, and inter-method call information; the operation log information is obtained by analyzing the operation logs and call trace information generated by the tracking tool after the operation of the original monolithic system, and extracting inter-method call information; the submission history data is obtained by analyzing the submission history data of the source code version management system and collecting the information of the code files that were commonly modified during each submission; A graph construction module is configured to: based on the obtained system data of the original monolithic architecture, represent the class entities in the source code as vertices and the association relationships between the class entities as edges to construct a class relationship graph; determine the association relationships between vertices by using the class relationship weights, method call relationship weights, and common modification relationship weights between the vertices; wherein, for any two vertices, the corresponding method call relationship weights are obtained by analyzing the execution paths in the log files; and for any two vertices, the common modification relationship weights are calculated based on the commit history; The graph clustering module is configured to cluster the constructed class relationship graph using the gravity graph clustering algorithm based on the user's requirements for the trade-off between microservice design principles and the performance of the reconstructed system to obtain an initial set of candidate microservices. Specifically: Based on the fine-grained microservice design principles and the single-responsibility microservice design principle, the repulsive force between vertices is determined. According to the fine-grained microservice design principle, the conditions that must be met are: the repulsive force between vertices is proportional to the vertex size, and the repulsive force between vertices is inversely proportional to the distance between vertices. According to the single-responsibility microservice design principle, the conditions that must be met are: the repulsive force between vertices with the same function is smaller than the repulsive force between vertices with different functions. To increase service cohesion, reduce coupling between services, and improve the performance of the reconstructed system, the conditions that must be met are: the attractive force between vertices is proportional to the edge weight, and the attractive force between vertices is proportional to the distance between vertices. Determine the attraction between vertices based on the design principle of high cohesion and low coupling and the user's requirements for the reconstructed system; Based on the user's trade-off requirements between microservice design principles and the performance of the reconstructed system, different weights are assigned to the repulsive and attractive forces acting on vertices. Vertex clusters are formed through multiple rounds of iterations to determine the initial set of candidate microservices. The optimization and adjustment module is configured to split or merge services with abnormal granularity in the initial candidate microservice set, eliminate outlier data in the initial candidate microservice set, and obtain the final candidate microservice set; specifically: Based on the granularity of candidate microservices in the initial candidate microservice set, abnormal candidate services are identified using a box plot method; wherein the abnormal candidate services include extremely large services and extremely small services; For each of the maximal services, split it into two candidate microservices using a minimum cut algorithm, calculate the change benefit of the candidate microservice set after the split and adjustment, and determine whether the candidate microservice set after the split and adjustment should replace the initial candidate microservice set or the candidate microservice set after the previous maximal service is optimized based on the change benefit of the candidate microservice set after the split and adjustment; Sort the minimal services by granularity, start with the minimal service with the smallest granularity, calculate the change benefits generated by merging it with all other candidate microservices, and determine the merging result of the minimal services based on the change benefits generated by the merging; The calculation method of the change benefit is: in, Represents the set of candidate microservices before the current maximum service is changed, that is, the set of candidate microservices after the previous maximum service is optimized, or the set of candidate microservices before the current minimum service is merged, that is, the set of candidate microservices after the previous minimum service is optimized; Indicates the set of candidate microservices after the current maximum service is changed, or the set of candidate microservices after the current minimum service is merged.

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

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

Images