Candidate micro-service identification method and system based on gravitational graph clustering

Abstract

According to the candidate micro-service identification method and system based on gravitational graph clustering, the class relation graph is constructed, the balance between the design principle of the micro-service and the performance of the reconstructed system is fully considered, the constructed class relation graph is clustered aiming at the diversity of user requirements, and the clustering efficiency is improved. And the initial candidate micro-service set obtained through identification can highly accord with the actual demand of the user, so that more optimized support is provided for application, and maximization of a business target and a user value is realized.

Description

Technical Field

[0001] The present invention belongs to the technical field related to microservice identification, and in particular, relates to a candidate microservice identification method and system based on gravity graph clustering. Background Art

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

[0003] Due to the advantages of microservice architecture, such as strong scalability, rapid update and iteration, high reliability, and the problems faced by monolithic architecture systems during operation and maintenance, such as slow startup and poor scalability, more and more companies are gradually migrating their monolithic architecture systems to microservice architecture. In the process of refactoring the monolithic architecture to the microservice architecture, accurate candidate microservice identification can help developers complete the migration work efficiently.

[0004] In order to refactor the monolithic architecture into a microservice architecture, some developers completely abandon the original monolithic architecture and start to build new applications based on the microservice architecture. However, this is not only a huge workload, but also has a high risk of failure. To address this problem, researchers have proposed different methods to automate service candidate identification, such as a data flow-driven method and a service candidate identification framework based on service execution traces. However, most of these studies on migrating the monolithic architecture to the microservice architecture are based on the design principles of microservices (such as fine-grained, low coupling, and single responsibility), without considering the application scenarios of the system and the actual needs of users for the refactored system.

[0005] In the actual reconstruction process, different companies have different requirements and indicators for the reconstructed microservices. Reconstruction should not be based solely on the design principles of microservices, but should consider the characteristics of the system and the needs of developers for the reconstructed system. For example, for some Internet companies with frequent business changes and a large number of users, they need higher reliability and flexibility in the reconstructed system, which requires splitting the monolithic architecture system into smaller microservices. For traditional companies with stable business and high requirements for responsiveness, due to hardware resources, development teams, etc., they may need higher manageability and performance requirements, which may require splitting the monolithic architecture system into larger microservices.

[0006] In summary, the current reconstruction of the monolithic architecture into a microservice architecture does not take into account the application scenarios of the system and the actual needs of users for the reconstructed system, resulting in the reconstructed microservice architecture not meeting user needs. Summary of the invention

[0007] In order to overcome the shortcomings of the above-mentioned prior art, the present invention provides a candidate microservice identification method and system based on gravity graph clustering, which considers the trade-off between the design principles of microservices and the performance of the system after reconstruction, dynamically clusters the constructed class relationship graph according to the diversity of user needs, and identifies a set of candidate microservices that meet user needs.

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

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

[0010] Obtaining system data of the original monolithic architecture; wherein the system data includes source code, operation logs, and submission history data;

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

[0012] Based on the user's trade-off requirements between the design principles of microservices and the performance of the reconstructed system, the constructed class relationship graph is clustered using the gravity graph clustering algorithm to obtain the initial candidate microservice set;

[0013] The services with abnormal granularity in the initial candidate microservice set are split or merged to eliminate the outlier data in the initial candidate microservice set and obtain the final candidate microservice set.

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

[0015] A 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;

[0016] 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, represent the association relationships between the class entities as edges, and construct a class relationship graph;

[0017] The graph clustering module is configured to: cluster the constructed class relationship graph through the gravitational graph clustering algorithm based on the user's design principles for microservices and the trade-off requirements between the performance of the reconstructed system, and obtain an initial set of candidate microservices;

[0018] 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 a final candidate microservice set.

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

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

[0021] One or more of the above technical solutions have the following beneficial effects:

[0022] In the present invention, a class relationship diagram is constructed, and the trade-off between the design principles of microservices and the performance of the reconstructed system is fully considered. According to the diversity of user needs, the constructed class relationship diagram is clustered, and the identified initial candidate microservice set can be highly consistent with the actual needs of users, thereby providing more optimized support for the application and maximizing business goals and user value.

[0023] In the present invention, the source code, operation log, submission history and other data of the original monolithic architecture are used to automatically identify candidate microservices, thereby improving the efficiency of migration from the monolithic architecture to the microservice architecture and effectively reducing the complexity and error rate of manual analysis.

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

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

[0026] Figure 1 This is an overall flow chart of candidate microservice identification based on gravity graph clustering in Embodiment 1 of the present invention;

[0027] Figure 2 This is an architecture diagram of a candidate microservice identification system based on gravity graph clustering in Embodiment 2 of the present invention. DETAILED DESCRIPTION

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

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

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

[0031] Embodiment 1

[0032] This embodiment discloses a candidate microservice identification method based on gravity graph clustering, including:

[0033] Obtain the system data of the original monolithic architecture; the system data includes source code, operation logs, submission history and other 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 associations between the class entities are represented as edges to construct a class relationship graph; wherein the associations between the class entities include the class relationships in the source code, i.e., the extends relationships or implements relationships between classes, the method call relationships in the execution logs, and the common modification relationships in the submission history;

[0035] Based on the user's trade-off requirements between the design principles of microservices and the performance of the reconstructed system, the constructed class relationship graph is clustered using the gravity graph clustering algorithm to obtain the initial candidate microservice set;

[0036] Services with abnormal granularity in the initial candidate microservice set are split or merged to eliminate outlier data in the initial candidate microservice set and obtain the final candidate microservice set.

[0037] This embodiment identifies candidate microservices through system data of the original monolithic architecture, thereby improving the efficiency of migration from a monolithic architecture to a microservice architecture and effectively reducing the complexity and error rate of manual analysis. This embodiment fully considers the trade-off between the design principles of microservices and the performance of the reconstructed system, and comprehensively considers key factors such as service maintainability, reliability, and response speed in view of the diversity of user needs. The identified candidate microservices can be highly consistent with the actual needs of users, thereby providing more optimized support for applications and maximizing business goals and user value.

[0038] Combine the following Figure 1 The candidate microservice identification method based on gravity graph clustering proposed in this embodiment is described in detail, including:

[0039] Step 1: Obtain the system data of the original monolithic architecture; the system data includes information data such as source code, operation logs, and submission history.

[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; 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 modified together 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 may also be obtained from other channels.

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

[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 is 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. ij .

[0047] For any edge, pay attention to the vertices and weights it connects, so for any edge e ij , which can be expressed as: ij {v i , v j , W ij}. Among them, v i , v j are two elements in the vertex set V, representing the two vertices of the edge; W ij Represents the weight of the edge, which is used to indicate the strength of the relationship between two vertices. The larger the weight value, the stronger the relationship between the two vertices.

[0048] For any edge e ij , whose weight W ij It consists of three parts: class relationship weight, method call relationship weight and common modification relationship weight, namely:

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

[0050]

[0051]

[0052]

[0053] Among them, Wf ij represents the method call relationship weight, which is obtained based on the analysis of execution traces in the log; ij Represents the class relationship weight, whose value is 0 or constant c; Wc ij Indicates the weight of the common modification relationship, which is obtained based on the analysis of the submission history; f_num ij is the vertex v in the log i , v j f_total is the number of calls in the log; c_num ij For all commit histories containing vertex v i , v j c_total is the total number of records.

[0054] Step 3: Based on the user's trade-off requirements between the design principles of microservices and the performance of the reconstructed system, the constructed class relationship graph is clustered using the gravity graph clustering algorithm to obtain the initial set of candidate microservices.

[0055] In step 3, it specifically includes:

[0056] According to the fine-grained and single-responsibility design principles of microservices, there is a repulsive force between any two vertices, and the size of the repulsive force is related to the size of the vertex and its function.

[0057] Specifically, according to the fine-grained design principle of microservices, the repulsion between vertices is proportional to the vertex size and inversely proportional to the distance between vertices; according to the single responsibility design principle of microservices, 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 ), vertex ν i Influenced by vertex v j The repulsive force Its size The calculation formula is as follows:

[0059]

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

[0061] According to the design principle of high cohesion and low coupling and the user's requirements for system performance and management difficulty after reconstruction, the design has gravity between the two vertices of the edge, and the magnitude of gravity is related to the weight of the edge, that is, the relationship between the vertices. In order to increase the cohesion of the service, reduce the coupling between services, and improve the performance of the reconstructed system, the magnitude of gravity is proportional to the weight of the edge and the distance between the 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 ,yj )}, if there is an edge e between them ij , then the 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 The distance moved in the direction of the current position is location.

[0069] Through rounds of iterations, vertices move toward 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:

[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 candidate services with abnormal granularity.

[0085] According to the identified abnormal candidate services, the abnormal candidate services are divided into two categories: extremely large services and extremely small services. According to the box-whisker plot, for any candidate service SC i If its granularity is greater than Q3+1.5*IQR, it is called a very large service; if its granularity is less than Q1-1.5*IQR, it is called a very small service; where Q1 and Q3 represent the first quartile and the 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 extremely large services and extremely small services, a change benefit formula is used to calculate the benefits of adjusting the candidate microservice set. The change benefit score is calculated as follows:

[0088]

[0089] Among them, SC″ 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; SC′ represents 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.

[0090] For any maximal service SC in the maximal service set SCK k , firstly divide it into two candidate microservices SC through the minimum cut algorithm kk and SC′ kk , for the candidate microservice set SC″ and the changed candidate microservice set SC′ (SC′=SC″-SC k +SC kk +SC′ kk ), and calculate the change benefit score according to formula (13).

[0091] When score>0, it means that the change is beneficial overall. The candidate microservice set SC′ after the change is more in line with user needs than the candidate microservice set SC″ before the change, and the change can be performed. On the contrary, when score<0, it means that the candidate microservice set after the change has become worse, and it is more beneficial to keep the candidate microservice set before the change.

[0092] Score>0 means that the granularity of the service has been greatly improved and the increased coupling due to service segmentation is within the user's acceptable range. In this case, segmentation is beneficial and SC′ can be used instead of SC″. Score<0 means that although the service granularity has been improved to a certain extent, this has greatly increased the coupling between services, which may affect the performance of the reconstructed system. In this case, segmentation is harmful and SC′ cannot be used instead of SC.

[0093] Understandably, in the first great service SC k After the segmentation, when the change benefit score is calculated by formula (13), SC″ in formula (13) is the original candidate microservice set SC. k After the split, when the change benefit score is calculated by formula (13), SC″ in formula (13) is the first maximum service SC kThe set of candidate microservices that are optimized after calculating the change benefits, and so on.

[0094] Each maximal service in the maximal service set SCK is processed in turn in the above manner, and finally a candidate microservice set after optimizing the maximal service is obtained. The execution process of this part can be represented by the following pseudo code:

[0095]

[0096]

[0097] For the minimal service set SCG, sort them by granularity and select the minimal service SC with the smallest granularity g , calculate the change benefit score generated by merging it with other candidate microservices in the candidate microservice set SC one by one through formula (13), then select the microservice with the largest score to merge, and after merging, update the minimal service set SCG and the candidate microservice set SC to obtain the merged candidate microservice set SC″; then select the minimal service SC with the second smallest granularity g , calculate the change benefit score generated by merging it with other candidate microservices in the candidate microservice set SC″ one by one through formula (13), then select the microservice 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 large services and the small services are processed, the final candidate microservice set SC = {SC1, SC2, ..., SC M}, where M≤m.

[0099] This embodiment is based on the source code, operation log, submission history and other data of the original monolithic architecture, and abstracts the original monolithic architecture system into a class relationship graph, in which vertices represent class entities in the source code, and edges represent dependencies, calls, and common modifications between classes; for the constructed graph, based on the user's demand parameters, it is clustered through the gravity graph clustering algorithm to obtain an initial set of candidate microservices; for services with abnormal granularity in the initial set of candidate microservices, the outlier data in the initial set of candidate microservices is split or merged, and the outlier data in the initial set of candidate microservices is eliminated to obtain the final set of candidate microservices. This method fully considers the trade-off between the design principles of microservices and the performance of the system after reconstruction. In view of the diversity of user needs, it comprehensively considers key factors such as service maintainability, reliability and response speed. The identified candidate microservices can be highly consistent with the actual needs of users, thereby providing more optimized support for applications and maximizing business goals and user value.

[0100] Embodiment 2

[0101] The purpose of this embodiment is to provide a candidate microservice identification system based on gravity graph clustering, including:

[0102] A 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;

[0103] 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, represent the association relationships between the class entities as edges, and construct a class relationship graph;

[0104] The graph clustering module is configured to: cluster the constructed class relationship graph through the gravitational graph clustering algorithm based on the user's design principles for microservices and the trade-off requirements between the performance of the reconstructed system, and obtain an initial set of candidate microservices;

[0105] 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 a final candidate microservice set.

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

[0107] An electronic device includes a memory and a processor, and computer instructions stored in the memory and executed on the processor, wherein when the computer instructions are executed by the processor, the method described in Embodiment 1 is performed. For the sake of brevity, no further description is given here.

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

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

[0110] A computer-readable storage medium is used to store computer instructions. When the computer instructions are executed by a processor, the method described in embodiment 1 is completed.

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

[0112] A computer program product includes a computer program, and when the computer program is executed by a processor, the method described in the first embodiment is implemented.

[0113] The present invention 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, such as instructions included in a program module, which are executed in a device on a real or virtual processor of the target to perform the process / method as described above. Typically, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform specific tasks or implement specific abstract data types. In various embodiments, the functions of program modules can be combined or divided between program modules as needed. Machine executable instructions for program modules can be executed in local or distributed devices. In distributed devices, program modules can be located in local and remote storage media.

[0114] The computer program code for implementing the method of the present invention can be written in one or more programming languages. These computer program codes can be provided to the processor of a general-purpose computer, a special-purpose computer or other programmable data processing device, so that the program code, when executed by the computer or other programmable data processing device, causes the function / operation specified in the flow chart and / or block diagram to be implemented. The program code can be executed completely on a computer, partially on a computer, as an independent software package, partially on a computer and partially on a remote computer or completely on a remote computer or server.

[0115] In the context of the present invention, computer program codes or related data may be carried by any appropriate carrier to enable a device, apparatus or processor to perform the various processes and operations described above. Examples of carriers include signals, computer readable media, etc. Examples of signals may include electrical, optical, radio, acoustic or other forms of propagation signals, such as carrier waves, infrared signals, etc.

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

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

Claims

1. A 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; Based on the obtained system data of the original monolithic architecture, class entities in the source code are represented as vertices, and association relationships between class entities are represented as edges to construct a class relationship graph; Based on the user's trade-off requirements between the design principles of microservices and the performance of the reconstructed system, the constructed class relationship graph is clustered using the gravity graph clustering algorithm to obtain the initial candidate microservice set; The services with abnormal granularity in the initial candidate microservice set are split or merged to eliminate the outlier data in the initial candidate microservice set and obtain the final candidate microservice set.

2. A candidate microservice identification method based on gravity graph clustering as claimed in claim 1, characterized in that: The association relationship between vertices is determined by the class relationship weight, method call relationship weight and common modification relationship weight between vertices; among them, for any two vertices, the corresponding method call relationship weight is obtained by analyzing the execution path in the log file; for any two vertices, their common modification relationship weight is calculated based on the submission history.

3. A candidate microservice identification method based on gravity graph clustering as claimed in claim 1, characterized in that: Based on the user's trade-off requirements between the design principles of microservices and the performance of the reconstructed system, the constructed class relationship graph is clustered using the gravity graph clustering algorithm to obtain the initial candidate microservice set, which is as follows: Determine the repulsion between vertices based on the fine-grained design principle of microservices and the single responsibility design principle of microservices; 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; According to the user's trade-off requirements between the design principles of microservices and the performance of the reconstructed system, different weights are assigned to the repulsive and attractive forces on the vertices. Vertex clusters are formed through multiple rounds of iterations to determine the initial set of candidate microservices.

4. A candidate microservice identification method based on gravity graph clustering as claimed in claim 3, characterized in that: According to the fine-grained design principle of microservices, the conditions to be satisfied are: the size of the repulsive force between vertices is proportional to the size of the vertices, and the size of the repulsive force between vertices is inversely proportional to the distance between vertices; according to the design principle of single responsibility of microservices, the conditions to be satisfied are: the repulsive force between vertices of the same function is smaller than the repulsive force between vertices belonging to different functions; in order to increase the cohesion of services, reduce the coupling between services, and improve the performance of the reconstructed system, the conditions to be satisfied are: the size of the attractive force between vertices is proportional to the weight of the edge, and the size of the attractive force between vertices is proportional to the distance between vertices.

5. The candidate microservice identification method based on gravity graph clustering according to claim 1, characterized in that: Split or merge the services with abnormal granularity in the initial candidate microservice set, eliminate the outlier data in the initial candidate microservice set, and obtain the final candidate microservice set, which is as follows: Based on the granularity of the candidate microservices in the initial candidate microservice set, the abnormal candidate services are identified by the box plot method; wherein the abnormal candidate services include extremely large services and extremely small services; For each of the maximal services, the minimum cut algorithm is used to divide it into two candidate microservices, and the change benefit of the candidate microservice set after the split adjustment is calculated. According to the change benefit of the candidate microservice set after the split adjustment, it is determined whether the candidate microservice set after the split adjustment replaces the initial candidate microservice set or the candidate microservice set after the previous maximal service is optimized; The minimal services are sorted according to granularity, starting from the minimal service with the smallest granularity, and the change benefits generated by merging it with all other candidate microservices are calculated, and the merging result of the minimal services is determined according to the change benefits generated by the merging.

6. A candidate microservice identification method based on gravity graph clustering as claimed in claim 5, characterized in that: The calculation method of the change benefit is: Among them, SC″ 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; SC′ represents 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.

7. A candidate microservice identification method based on gravity graph clustering as claimed in claim 1, characterized in that: The source code is obtained by extracting the code file of the original monomer system and analyzing its code class information, belonging functions, number of code lines, class relationship and calling information between methods; the operation log information is obtained by analyzing the operation log and calling trace information generated after the operation of the original monomer system based on the tracking tool, and extracting the calling information between methods; The submission history data is obtained by analyzing and extracting the code file information that is commonly modified during each submission based on the submission history data collected by the source code version management system.

8. A candidate microservice identification system based on gravity graph clustering, characterized in that: include: A 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; 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, represent the association relationships between the class entities as edges, and construct a class relationship graph; The graph clustering module is configured to: cluster the constructed class relationship graph through the gravitational graph clustering algorithm based on the user's design principles for microservices and the trade-off requirements between the performance of the reconstructed system, and obtain an 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 a final candidate microservice set.

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

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

Images