Micro-service Identification Method Based on Dynamic and Static Call Relationships and Reflecting Business Capabilities

Abstract

The present invention relates to a method for identifying and migrating software architectures, specifically a method and device for microservice identification based on dynamic and static call relationships and reflecting business capabilities. The present invention comprehensively analyzes the functional characteristics of a monolithic system from two aspects of dynamic and static call relationships. The functional characteristics collected in this way will be more comprehensive than single characteristics. The present invention processes the collected functional characteristics, filters the dynamic execution traces and streamlines the static call relationships, removing elements irrelevant to business capabilities. In this way, the processed functional characteristics can better reflect business capabilities. The present invention calculates the co-occurrence times between elements in the monolithic system and uses it as the basis for microservice identification. The present invention uses a clustering algorithm to obtain a clustering result to migrate the elements in the monolithic system to a microservice architecture.

Description

Technical Field

[0001] The present invention relates to a method for identifying and migrating software architectures, and the applicable object of the present invention is the software architecture in software engineering. The present invention collects functional features based on dynamic and static call relationships and reflects business capabilities. Specifically, it migrates the traditional monolithic software architecture into a microservices architecture, making the entire migration process highly automated and requiring less human participation. Background Art

[0002] A monolithic software system encapsulates all resources in a single program. In a single program, if a problem occurs somewhere, it will render the entire system unusable. Although monolithic applications are easy to deploy and develop, as the software scale continues to expand, monolithic applications will become difficult to maintain and extend.

[0003] Currently, the vast majority of microservices identification methods usually look for the functional features of a monolithic system and classify the elements of the monolithic system into different microservices according to the principles of high cohesion and low coupling. However, most existing microservices identification methods do not consider that microservices are built based on business capabilities (business capabilities are observed from the external perspective of the software system and are an intuitive manifestation of the real world), and a pure functional perspective (the functional perspective considers what purpose the software system has achieved from the level of monolithic software deployment and development) cannot well reflect the characteristics of microservices. In fact, an important design principle of microservices is that microservices are built based on business capabilities.

[0004] If the microservices identification method only considers the functional perspective, then the microservices architecture may degenerate into a service-oriented architecture or a distributed architecture, and thus the unique advantages of microservices, such as independent deployment, technology heterogeneity, fast iteration, etc., cannot be fully utilized. In addition, the lack of software design documents also brings difficulties to such methods. Generally speaking, the current microservices identification methods cannot well migrate the monolithic software architecture into the microservices architecture. Summary of the Invention

[0005] Based on this, it is necessary to provide a microservices identification method based on dynamic and static call relationships and reflecting business capabilities to address the problem that most current microservices identification methods do not consider actual business capabilities.

[0006] The present invention is implemented by adopting the following technical solutions:

[0007] In a first aspect, the present invention discloses a microservices identification method based on dynamic and static call relationships and reflecting business capabilities, which is used for identifying and migrating software architectures.

[0008] S1. Obtain the original dynamic execution trace and the original static call relationship of the monomer system, filter the original dynamic execution trace to obtain the processed dynamic execution trace, and streamline the original static call relationship to obtain the processed static call relationship;

[0009] Among them, the method for filtering the original dynamic execution trace is: determine whether each original dynamic execution trace contains a method for operating on the database / operation entity class; if so, retain this trace; if not, delete this trace;

[0010] The method for streamlining the original static call relationship is: start constructing the call relationship from the starting point method at the bottom, and find out which other methods call each method; continuously construct upward until no active call can be found, and retain the found call relationship;

[0011] Among them, the processed dynamic execution trace and the processed static call relationship are used to reflect the business capabilities;

[0012] S2. Statistically analyze the co-occurrence times of the elements in the processed dynamic execution trace and the processed static call relationship, and construct an association matrix;

[0013] S3. Based on the association matrix, use a clustering recognition algorithm to obtain the microservice recognition result.

[0014] The microservice recognition method based on dynamic and static call relationships and reflecting business capabilities implements the method or process according to the embodiments of the present disclosure.

[0015] In a second aspect, the present invention discloses a microservice recognition device based on dynamic and static call relationships and reflecting business capabilities, which uses the microservice recognition method based on dynamic and static call relationships and reflecting business capabilities in the first aspect. The microservice recognition device includes:

[0016] An acquisition module, which is used to obtain the original dynamic execution trace and the original static call relationship of the monomer system, filter the original dynamic execution trace to obtain the processed dynamic execution trace, and streamline the original static call relationship to obtain the processed static call relationship;

[0017] A statistics module, which is used to statistically analyze the co-occurrence times of the elements in the processed dynamic execution trace and the processed static call relationship, and construct an association matrix; and

[0018] A calculation module, which is used to obtain the microservice recognition result based on the association matrix using a clustering recognition algorithm.

[0019] The microservice recognition device based on dynamic and static call relationships and reflecting business capabilities implements the method or process according to the embodiments of the present disclosure.

[0020] In a third aspect, the present invention discloses a readable storage medium storing computer program instructions, which, when read and executed by a processor, implement the above-mentioned microservice identification method based on dynamic and static call relationships and reflecting business capabilities.

[0021] Compared with the prior art, the present invention has the following beneficial effects:

[0022] 1. The present invention comprehensively analyzes the functional characteristics of a monolithic system from two aspects of static and dynamic call relationships. The functional characteristics collected in this way will be more comprehensive than single characteristics. The present invention processes the collected functional characteristics (i.e., dynamic execution traces and static call relationships), filters the dynamic execution traces, streamlines the static call relationships, and removes elements irrelevant to business capabilities. In this way, the processed functional characteristics can better reflect business capabilities. The present invention calculates the co-occurrence times between elements in the monolithic system and uses them as the basis for microservice identification. The present invention uses a clustering algorithm to obtain a clustering result to migrate the elements in the monolithic system to a microservice architecture. Among them, the present invention sets clear initial center points for iterative operations, which can reduce the algorithm cycle and load and obtain better calculation results.

[0023] 2. The present invention only needs the original engineering code and the runnable instance of the monolithic system to be implemented, and the code and instance of a software system are usually easy to obtain. Compared with other microservice identification methods, such as the time-consuming and laborious manual microservice identification method, the present invention brings an improvement in efficiency. For some microservice identification methods that require collecting software design documents, such as collecting data flow diagrams and flowcharts in the software to identify microservices, these design documents are usually difficult to obtain and it is impossible to ensure the non-deviation of these design documents. Compared with these microservice identification methods, the original data required by the present invention is relatively easy to obtain, bringing a certain degree of convenience to microservice identification. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 is a flowchart of the microservice identification method based on dynamic and static call relationships and reflecting business capabilities in the present invention;

[0025] Figure 2 is Figure 1 the schematic diagram of filtering the dynamic execution trace in;

[0026] Figure 3 is the schematic diagram of constructing relationships from top to bottom in the prior art;

[0027] Figure 4 is Figure 1 the schematic diagram of searching the static call relationship from bottom to top in;

[0028] Figure 5 For Figure 1 Example of static call relationship in

[0029] Figure 6 For Figure 1 Example of dynamic execution trace in Specific implementation manner

[0030] The following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present invention.

[0031] It should be noted that when a component is referred to as "installed on" another component, it can be directly on the other component or there may also be an intermediate component. When a component is considered to be "set on" another component, it can be directly set on the other component or there may be an intermediate component at the same time. When a component is considered to be "fixed to" another component, it can be directly fixed to the other component or there may be an intermediate component at the same time.

[0032] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those of ordinary skill in the technical field to which the present invention belongs. The terms used in the description of the present invention in this specification are only for the purpose of describing specific embodiments and are not intended to limit the present invention. The term "or / and" used herein includes any and all combinations of one or more of the related listed items.

[0033] Embodiment 1

[0034] Please refer to Figure 1 , Figure 1 is a flowchart of a microservice identification method based on dynamic and static call relationships and reflecting business capabilities in the present invention. This embodiment discloses a microservice identification method based on dynamic and static call relationships and reflecting business capabilities, which is used to identify and migrate software architectures.

[0035] The microservice identification method based on dynamic and static call relationships and reflecting business capabilities includes the following steps:

[0036] S1. Obtain the original dynamic execution trace and original static call relationship of the monolithic system, filter the original dynamic execution trace to obtain the processed dynamic execution trace, and streamline the original static call relationship to obtain the processed static call relationship;

[0037] The purpose of S1 is to obtain the dynamic and static call relationships that can reflect the business capabilities, namely the processed dynamic execution traces and the processed static call relationships.

[0038] On the one hand, a dynamic execution trace collection tool (such as kieker) plus test cases are used to collect the dynamic execution traces of the monolithic system. When the original dynamic execution traces of the monolithic system are collected, the original dynamic execution traces are filtered to collect the processed dynamic execution traces. Among them, dynamic traces are generated only when the program runs, so test cases are needed to make the monolithic system run to achieve the collection of dynamic execution traces.

[0039] See Figure 2 , which is the schematic diagram for filtering the dynamic execution traces. Specifically, for each dynamic execution trace, it may include some methods that are not related to the business capabilities. If these dynamic execution traces are not deleted and filtered, it will cause deviation in the results of microservice identification.

[0040] The method for filtering the original dynamic execution traces in this embodiment is:

[0041] By judging whether each original dynamic execution trace contains a method of operating on the database / operating on the entity class; if so, this trace is retained; if not, this trace is deleted.

[0042] As Figure 2 shown, Figure 2 the dashed circle 5 in represents the method of operating on the database / operating on the entity class. According to the above method, the trace where 5 is located should be retained, that is, the solid circle 1 passes through the solid circle 2, the solid circle 3, the solid circle 4 to the dashed circle 5.

[0043] On the other hand, a static call analysis tool (such as Java call graph) is used to analyze the monolithic system to obtain the original static call relationship. When necessary, irrelevant third-party libraries, internal class calls, and self-loop calls are removed. Among them, for third-party libraries, since the package names of the analysis project are known, it can be removed by judging whether the caller or the callee contains the package name of the project: if it contains, it is retained; if not, it is removed. Internal classes are converted into the form of external classes. Here, to be precise, it is not removal but conversion. For example, the class A$B in the present invention is converted into the class A, converting the internal class into an external class. Self-loop calls mainly judge whether the caller and the callee are methods in the same class: if so, it is deleted, otherwise it is retained.

[0044] Then, for the original static call relationship, it is refined to obtain the processed static call relationship. Among them, static calls can be obtained by analyzing the source code of the program without running the program.

[0045] Briefly speaking, after determining the starting search point, a bottom-up search and construction of the call relationship is performed to obtain the call relationship that is most relevant to the business capabilities. This method is more concise than the traditional top-down construction and is more focused on method calls related to the business.

[0046] It should be noted that referring to Figure 3 , it is a schematic diagram of constructing the relationship from top to bottom in the prior art, that is, starting from the call entry point, constructing from top to bottom.

[0047] Referring to Figure 4 , it is a schematic diagram of a bottom-up search for the static call relationship: starting from the starting point method at the bottom, constructing the call relationship, and finding which other methods call each method; continuously constructing upward until no active call can be found, and retaining the found call relationship.

[0048] As Figure 3 shown, A represents the entry point of the call relationship. Starting from the call relationship entry point A, continuously construct downward until the method no longer calls other methods, and thus the call process ends. As Figure 4 shown, G represents the starting point method. Starting from G, construct the static call relationship, find which other methods call each method, and continuously construct upward until no actively called method can be found. In this way, the bottom-up process in this embodiment will remove some methods that are not relevant to the starting point method G. Specifically, referring to Figure 3 , 4 , Figure 4 the methods C, E, and B in Figure 3 will not enter the subsequent process. Compared with

[0049] Therefore, based on the processed dynamic execution trace and the processed static call relationship obtained from the above processing, the business capabilities can be reflected;

[0050] S2. Count the co-occurrence times of the elements in the processed dynamic execution trace and the processed static call relationship, and construct an association matrix;

[0051] The purpose of S2 is to obtain the relevance between all elements in the monolithic system, that is, the total co-occurrence times of any pair of elements. The total co-occurrence times include the co-occurrence times of the pair of elements under the processed dynamic execution trace and the co-occurrence times under the processed static call relationship.

[0052] For the static call relationship, as long as a pair of elements exists in the same static call relationship, it is considered that there is a certain correlation between this pair of elements, and the co-occurrence times N1 of each pair of elements under the static call relationship are counted.

[0053] For the dynamic trace, as long as a pair of elements appears simultaneously in the same trace, it is considered that there is a correlation between this pair of elements, and the co-occurrence times N2 of each pair of elements under the dynamic trace are counted.

[0054] The co-occurrence times N1 and the co-occurrence times N2 are superimposed to obtain the correlation between all elements in the single-body system and form a correlation matrix.

[0055] See Figure 1 , the correlation matrix is expressed as: where n is the total number of all elements in the single-body system, and 1 < k1 < k2 < n.

[0056] and are the same, both representing the total co-occurrence times of the k1-th element and the k2-th element; it should be noted that this matrix is a symmetric matrix with w 11 、…、 …、 …、w nn as the symmetry line.

[0057] Among them, the total co-occurrence times between two different elements are what we need to care about. Therefore, here, w 11 、…、 …、 …、w nn are set to a fixed value, generally set to 0, which represents no practical significance and avoids affecting subsequent calculations.

[0058] S3. Based on the correlation matrix, use the clustering recognition algorithm to obtain the microservice recognition result.

[0059] The purpose of S3 is to obtain the final microservice recognition result.

[0060] Before using the clustering recognition algorithm, it is necessary to specify the number N of microservice recognitions as the number of initial center points of the clustering recognition algorithm.

[0061] In a microservice architecture system, an ideal recognition result is that the elements in different services have great differences. Since the clustering algorithm adopted in this embodiment needs to select initial center points, the variability between the initial center points must be large enough to make the differences of the elements added to the clustering clusters large enough.

[0062] The first step in S3 is to select the initial center points. Based on the relevance between elements, when selecting the initial center points, the differences between the initial center points should be fully magnified. Therefore, first, an element with the least relevance to other elements is selected as one of the initial center points. When selecting subsequent elements, not only the relevance between this element and other elements is considered, but also the relevance between it and the existing center points is considered. Since it is necessary to magnify the differences between different center points, the element with less relevance to the existing center points is more likely to become a center point, thus fully magnifying the differences between the center points of different clusters, which conforms to the design principle of microservices.

[0063] Since the number N of microservice identifications has been specified, that is, the number of clustering clusters is determined, the number of initial center points is also determined.

[0064] Among them, the initial center points are obtained according to the correlation matrix, with a total of N, and there is sufficient difference between different initial center points.

[0065] Specifically, first select the first initial center point C1. The selection of the first initial center point C1 is based on the formula:

[0066]

[0067] Among them, represents the i1-th row in the correlation matrix; I1 is the value of i1 when

[0068] is the largest;

[0069] It should be noted that the I1 obtained here corresponds to the element subscript of the correlation matrix, representing the I1-th element. In this way, the corresponding element can be obtained according to I1, which is the first initial center point C1;

[0070] Here, the sum of the weights of the first initial center point obtained and all other elements is the largest. N ;

[0071] Among them, the selection of the N-th initial center point C N is based on the formula:

[0072]

[0073] Among them, represents the i N -th column in the correlation matrix; I N is when N is the largest, the value of i N ; referring to the above, I N represents the I N -th element.

[0074] According to I N The corresponding element is obtained, which is the Nth initial center point C N .

[0075] That is to say, the subsequent initial center points need to meet the following conditions: select an element and substitute it into a formula (i.e., formula 2). The numerator of the formula is the sum of the weights between this element and other elements The denominator of the formula is the sum of the weights between this element and the already obtained initial center points Plus the constant 1. It should be noted that adding the constant 1 to the denominator is to avoid the situation of zero in the denominator

[0076] When the numerator is larger and the denominator is smaller, it means that this element is more likely to be selected as the initial center point

[0077] The second step in S3 is to perform clustering division on non-center point elements after selecting the initial center points, that is, cluster selection: add non-center point elements to the cluster to which the center point with the greatest association with it belongs to form specific clusters

[0078] The third step in S3 is to select subsequent center points. For each specific cluster, select an element with the greatest association with other elements as the clustering center point

[0079] Then, clustering division is performed again according to the clustering center points to form new specific clusters and new clustering center points. Continuously perform clustering division of elements and selection of center points until a maximum number of iterations is reached or each center point no longer changes. In this way, the microservice recognition clustering algorithm ends, and N groups of element clusters can be obtained

[0080] The last step in S3 is to identify the element features in the element clusters to determine the service name of the microservice. This step can be simply identified and named manually or can be matched and classified by a program

[0081] Embodiment 2

[0082] A specific example is described according to the method of Embodiment 1

[0083] Take the well-known jpstore software project as an example to illustrate the method of the present invention

[0084] First, obtain the source code and runnable instances of the software project from the website https: / / github.com / mybatis / jpetstore-6

[0085] For the source code of the jpetstore project, the present invention packages the jpetstore project into a compressed package in jar format as the input to be passed into the static analysis tool. Running the static analysis tool can obtain the corresponding method call relationships. In this embodiment, a program static analysis tool is used to obtain the corresponding method call relationships. As Figure 5 shown, the updateAccount method on the left represents the calling method, and the getName method on the right is the called method. After the static analysis of the entire jpetstore is completed, many classes and Figure 5 the same call relationships will be obtained. Each line of the call relationship corresponds to a Figure 5 such example.

[0086] For the jpetstore project, it is determined whether a method is an operation database method by judging whether the method contains "persistence", and it is determined whether a method is an operation entity class method by judging whether the method contains "domain".

[0087] After the static analysis of the jpetstore project is completed, this embodiment first identifies the entity class methods and operation database methods that appear in the static relationships. This process is achieved by filtering the full path names of the files, and these methods are regarded as the starting point methods. Different from the usual construction of static call relationships starting from the entry point method of the software system, this embodiment constructs from specific starting point methods and adopts the breadth-first search method to search from the callee to the caller. In this way, the obtained static call relationships are closely related to the starting point methods. After the static call relationships for each special starting point method are completed, it is considered that the elements appearing in the static call relationships constructed by the same starting point method have a certain relevance. For any one starting point method, a relevant set will be constructed. All the methods in this set are relevant. For any two methods, such as A and B, as long as they appear in any static call relationship set constructed by the starting point method, the relevance between them is incremented by one.

[0088] Use a dynamic trace collection tool to perform dynamic analysis on the jpetstore project. Specifically, by adding some Kieker-related dependencies to the jpetstore project and writing the Kieker-related configurations on the jpetstore project. Subsequently, start the jpetstore project, and Kieker will automatically save the dynamic traces of the program execution to a pre-set directory on the disk. The collected dynamic traces are consecutive sequences of methods, starting from the entry point to the end of the overall method flow. If there is no starting point method in this trace, then this trace has no effect on the present invention and is deleted; otherwise, it will be retained.

[0089] As Figure 6 shown, the dynamic trace is on the left and the methods are on the right. Since each test case in the software system triggers the generation of a dynamic trace, in Figure 6 the left-side dynamic trace identifier of each line represents each trace. Use the dynamic trace identifier to distinguish different dynamic traces. If the dynamic trace identifiers of two lines in the dynamic trace are the same, it proves that these two methods exist in the same trace, and the elements appearing in the same trace are considered to have a certain correlation. For any trace, as long as two methods appear in the same trace, the correlation between these two methods is incremented by one.

[0090] Since the correlations obtained currently are all at the method level, but the result of microservice identification is at the class level, it is necessary to convert the correlations at the method level into correlations between classes. Specifically, the correlation between two classes is equal to the sum of the correlations between all their internal methods.

[0091] After obtaining the correlations between all elements (i.e., classes) in the jpetstore project, store the correlations between all elements in an association matrix, and use the association matrix as the input of the clustering algorithm. And determine that the number of microservices is 4 and the maximum number of clustering iterations is 200.

[0092] At the same time, this embodiment adopts an improved k-means-based clustering algorithm. The traditional k-means requires artificial or random selection of the initial center points, resulting in a large number of iterations of the clustering algorithm and poor clustering results. Therefore, this embodiment makes some improvements in the process of selecting the center points.

[0093] Specifically, since the elements in the jpetstore project have different importance levels, when selecting the initial center points, this embodiment takes into account the correlation between each element and other elements. When selecting the first initial center point, the node with the least correlation with other elements is regarded as the initial center point and kept fixed. When selecting subsequent initial center points, not only the correlation with other elements is considered, but also, due to the requirement of the clustering algorithm that the difference between different clusters should be large enough, the correlation with the existing initial center points is added to the consideration of selecting the initial center point. In this way, the difference between the selected initial center points is large enough, which conforms to the principle of the clustering algorithm. After the initial center points are selected, all the elements in the jpetstore project are clustered according to a certain number of iterations. When the center points no longer change or the maximum number of iterations is reached, the overall algorithm process ends.

[0094] Finally, the microservice recognition results of the jpestore project are shown in Table 1 below. The right part of Table 1 is the 4 clusters, and based on the element characteristics in the clusters, the microservice names on the left part of Table 1 are defined.

[0095] Table 1 Microservice Recognition Results of the jpestore Project

[0096]

[0097]

[0098] Embodiment 3

[0099] This embodiment discloses a microservice recognition device based on dynamic and static call relationships and reflecting business capabilities, which uses the microservice recognition method based on dynamic and static call relationships and reflecting business capabilities in Embodiment 1.

[0100] The microservice recognition device includes an acquisition module, a statistics module, and a calculation module. The acquisition module is used to acquire the original dynamic execution trace and the original static call relationship of the monolithic system, filter the original dynamic execution trace to obtain the processed dynamic execution trace, and streamline the original static call relationship to obtain the processed static call relationship. The statistics module is used to count the co-occurrence times of the elements in the processed dynamic execution trace and the processed static call relationship, and construct an association matrix. The calculation module is used to obtain the microservice recognition result based on the association matrix using a clustering recognition algorithm.

[0101] For the specific recognition principle, refer to Embodiment 1 and will not be elaborated here.

[0102] This embodiment also discloses a readable storage medium, in which computer program instructions are stored. When the computer program instructions are read and run by a processor, the above-mentioned microservice identification method based on dynamic and static call relationships and reflecting business capabilities is executed.

[0103] When the method of Embodiment 1 is applied, it can be applied in the form of software, such as designed as a program that can run independently on a computer-readable storage medium. The computer-readable storage medium can be a USB flash drive, designed as a USB key, and designed as a program that starts the entire method through external triggering via the USB flash drive.

[0104] The technical features of the above-mentioned embodiments can be combined arbitrarily. For the sake of brevity of description, not all possible combinations of the technical features in the above-mentioned embodiments are described. However, as long as there is no contradiction in the combination of these technical features, it should be considered as the scope described in this specification.

[0105] The above-mentioned embodiments only represent several implementation manners of the present invention, and the description is relatively specific and detailed. However, it should not be understood as a limitation to the scope of the invention patent. It should be noted that for those of ordinary skill in the art, without departing from the concept of the present invention, several deformations and improvements can still be made, and these all belong to the protection scope of the present invention. Therefore, the protection scope of the invention patent should be subject to the appended claims.

Claims

1. A microservice identification method based on dynamic and static call relationships and reflecting business capabilities, which is used to identify and migrate software architectures, characterized in that, The microservice identification method includes the following steps: S1. Obtain the original dynamic execution trace and the original static call relationship of the monolithic system, filter the original dynamic execution trace to obtain the processed dynamic execution trace, and streamline the original static call relationship to obtain the processed static call relationship; Among them, the method for filtering the original dynamic execution trace is: determine whether each original dynamic execution trace contains a method for operating on the database / operating entity class; if so, retain this trace; if not, delete this trace; The method for streamlining the original static call relationship is: start constructing the call relationship from the starting point method at the bottom, and find which other methods call each method; continuously construct upward until no active call can be found, and retain the found call relationship; Among them, the processed dynamic execution trace and the processed static call relationship are used to reflect the business capabilities; S2. Count the co-occurrence times of the elements in the processed dynamic execution trace and the processed static call relationship, and construct an association matrix; S3. Based on the association matrix, use a clustering recognition algorithm to obtain the microservice identification result.

2. The microservice identification method based on dynamic and static call relationships and reflecting business capabilities according to claim 1, characterized in that In S1, run the test case, and obtain the original dynamic execution trace through the dynamic execution trace collection tool; Obtain the original static call relationship through the static call analysis tool.

3. The microservice identification method based on dynamic and static call relationships and reflecting business capabilities according to claim 2, characterized in that The dynamic execution trace collection tool generates the original dynamic execution trace through program operation; The static call analysis tool analyzes the source code of the program to generate the original static call relationship.

4. The microservice identification method based on dynamic and static call relationships and reflecting business capabilities according to claim 1, characterized in that In S2, count the co-occurrence times N1 of each pair of elements under the processed static call relationship, and count the co-occurrence times N2 of each pair of elements under the processed dynamic execution trace; Superimpose the co-occurrence times N1 and the co-occurrence times N2 to obtain the correlation between all elements in the monolithic system and form an association matrix.

5. The microservice identification method based on dynamic and static call relationships and reflecting business capabilities according to claim 4, characterized in that The associated matrix is expressed as where n is the total number of all elements in the monomer system, and 1 < k1 < k2 < n; Same as , both representing the total co-occurrence times of the k1-th element and the k2-th element; w 11 , …, w kk , …, w nn are set as fixed values.

6. The microservice identification method based on dynamic and static call relationships and reflecting business capabilities according to claim 1, characterized in that In S3, before using the clustering algorithm, specify the number N of microservice identifications as the number of initial center points of the clustering recognition algorithm.

7. The microservice identification method based on dynamic and static call relationships and reflecting business capabilities according to claim 6, characterized in that S3 includes the following steps: S301. Select the initial center points; among them, the initial center points are obtained according to the association matrix, there are N in total, and there is sufficient difference between different initial center points; S302. Perform clustering division on non-center point elements; among them, add non-center point elements to the cluster belonging to the center point with the greatest correlation with it to form specific clusters; S303. Select subsequent center points; among them, for each specific cluster, select an element with the greatest correlation with other elements as the new center point; S304. Repeat S302 and S303 until a maximum number of iterations is reached or the center points no longer change each time, and the microservice clustering algorithm ends and N groups of element clusters are obtained; S305. Identify the element characteristics in the element cluster and determine the service name of the microservice.

8. The microservice identification method based on dynamic and static call relationships and reflecting business capabilities according to claim 1, characterized in that The method for obtaining the initial center points is: First select the first initial center point C1, and the selection of the first initial center point C1 is based on the formula: Among them, represents the i1-th row in the incidence matrix; I1 is the value of i1 when it is the maximum; Obtain the corresponding element according to I1, which is the first initial center point C1; If N > 1, then successively select the other N - 1 initial center points C2, …, C N ; Among them, the initial center point C of the Nth N is selected according to the formula: Among them, represents the i-th N row in the incidence matrix; I N is when it is the maximum, the value of i N is taken; According to I N The corresponding element is obtained, which is the Nth initial center point C N .

9. A microservice identification device based on dynamic and static call relationships and reflecting business capabilities, characterized in that, It uses the microservice identification method based on dynamic and static call relationships and reflecting business capabilities as described in any one of claims 1-8; the microservice identification device includes: An acquisition module, which is used to acquire the original dynamic execution trace and original static call relationship of the monolithic system, filter the original dynamic execution trace to obtain the processed dynamic execution trace, and streamline the original static call relationship to obtain the processed static call relationship; A statistics module, which is used to count the co-occurrence times of elements in the processed dynamic execution trace and processed static call relationship, and construct an association matrix; and A calculation module, which is used to obtain the microservice identification result based on the association matrix using a clustering identification algorithm.

10. A readable storage medium, characterized in that, Computer program instructions are stored in the readable storage medium, and when the computer program instructions are read and run by a processor, they execute the microservice identification method based on dynamic and static call relationships and reflecting business capabilities as described in any one of claims 1-8.

Images