A microservice architecture identification method based on multi-class features and multiple metrics

Abstract

The present invention discloses a microservice architecture identification method based on multiple types of features and multiple metrics. A decision model for microservice architecture identification is constructed based on the characteristics of microservice architecture relative to other software architectures. The characteristic metric information of the microservice architecture in the target software project is obtained through static analysis technology. Finally, the probability of the input project using the microservice architecture is calculated using the decision model. Compared with the existing architecture identification method, the method of the present invention expands the characteristics of the microservice architecture, and designs a calculation function that conforms to its characteristics for each metric, so the identification accuracy is higher and the identification result contains richer content.

Description

Technical Field

[0001] The present invention belongs to the field of architecture pattern recognition in software engineering reverse engineering, and in particular to a microservice architecture recognition method based on multiple types of features and multiple metrics. Background Art

[0002] A software system of a certain scale is likely to have a complex evolution process, and during the evolution of the system, the system architecture information may not be updated in time or the documentation may be missing, which will cause deviations in the real architecture information of the software system, thus bringing a huge burden to the subsequent maintenance. Therefore, in the field of software engineering reverse engineering, it is an important task to identify the architecture of the software system and try to obtain the real architecture information of the system.

[0003] In the research of architecture identification technology, in addition to the traditional software clustering technology, which clusters entities in the software system into components of a certain abstract granularity based on the principle of high cohesion and low coupling in software development to obtain a system structure view, helping the developers and maintainers of the target system to understand the status of the system architecture, genetic algorithms, pattern matching, concept analysis and other technologies are also gradually being used in architecture identification. However, like software clustering, these architecture identification technologies are more targeted at general scenarios and do not consider the characteristics of specific architectures. The results obtained by these methods are likely to lose a lot of information related to the actual architecture, making the identification results differ greatly from the actual results. Therefore, it is very necessary to design targeted architecture identification methods for different software architectures.

[0004] Currently, the most commonly used software architectures include layered architecture, event-driven architecture, microservice architecture, etc. In recent years, the academic community has proposed many identification methods for layered architecture, and the identification effect has also made great progress; in comparison, there is much less research material on event-driven architecture identification. In 2019, relevant scholars proposed an ontology-based event-driven program architecture pattern recognition method, which to a certain extent provided new ideas for related research; and as the microservice architecture has been increasingly widely used in recent years, there has been no relevant targeted research results.

[0005] The popularity of microservice architecture is closely related to its architectural features. It breaks away from traditional monolithic applications and advocates dividing a single application into a group of small services. Each service is built around a specific business, uses specific components to complete specific functions, and can be independently deployed in the production environment. Services use lightweight communication mechanisms to communicate, coordinate and cooperate with each other to provide ultimate value to users. Based on the above characteristics, the microservice architecture embodies the characteristics of controllable complexity, flexible technology selection, high fault tolerance, and strong scalability.

[0006] Therefore, in the identification of microservice architecture, in addition to applying existing architecture identification and architecture recovery technologies, the characteristics of the architecture itself should also be combined to make the identification effect more in line with the actual situation. Summary of the invention

[0007] The purpose of the present invention is to provide a decision model for identifying a microservice architecture based on the constructed one and the metric information of the input project that conforms to the typical characteristics of the microservice architecture obtained, and to obtain the overall probability of the identified input project using the microservice architecture and the reasons for non-compliance through calculation through the metric information and the decision model.

[0008] In order to achieve the above object, the technical solution of the present invention is as follows: a microservice architecture identification method based on multiple types of features and multiple metrics, comprising the following steps:

[0009] Step 1) Construct a decision model P for microservice architecture identification based on the characteristics of the microservice architecture a , used to calculate the probability P of the target software project using the microservice architecture, where a is the metric in the decision model;

[0010] Step 2) Input the source code of a target software project, pre-process the target software project to obtain a granularity size that may be a single sub-service entity b i The set B = {b1, b2, ..., b n};

[0011] Step 3) Based on the entity set B obtained in step 2), each entity b in B is i Perform static analysis to detect whether it uses components related to the metrics in the decision model, and store the relevant information in the microservice information and component library L;

[0012] Step 4) Based on the microservice information and component library L established in step 3), obtain the subservice quantity information x related to each metric in the decision model;

[0013] Step 5) Based on the metric-related sub-service quantity information x obtained in step 4), the probability value calculation function and decision model function corresponding to each indicator are used to calculate the probability value P of the target software project using the microservice architecture.

[0014] Furthermore, the specific content of the decision model constructed in step 1) is as follows:

[0015] (1) Summarize and summarize the characteristics of microservice architecture and divide them into three categories: scale characteristics, component characteristics and topology characteristics. Select representative and universal characteristics as the measurement indicators for microservice architecture identification and construct the measurement indicator set A = {a1, a2, a3, a4}, where a1 is the measurement indicator of the number of subservices in the scale characteristic, a2 and a3 are the measurement indicators of the service registration and discovery component and load balancing component in the component characteristic, and a4 is the measurement indicator of the gateway component in the topology characteristic.

[0016] (2) According to each metric a i The characteristics of each metric define a probability value calculation function f i (x), this calculation function calculates the additional probability value P for the microservice architecture decision model based on the relevant quantity information x of the metric in the target software project i The details are as follows:

[0017] a) The probability value calculation function of the sub-service quantity measurement indicator is:

[0018]

[0019] Where x is the number of sub-services obtained from the microservice information and component library, and P1=f1(x) is the added probability value of the sub-service quantity metric in the decision model calculated based on the number of sub-services;

[0020] b) The probability value calculation function of the service registration and discovery component metric is:

[0021]

[0022] Where x is the number of sub-services including the service registration and discovery component obtained from the microservice information and component library, and P2=f2(x) is the additional probability value of the service registration and discovery component metric in the decision model calculated based on the number of sub-services including the service registration and discovery component;

[0023] c) The probability value calculation function of the load balancing component metric is:

[0024]

[0025] Where x is the number of sub-services containing the load balancing component obtained from the microservice information and component library, and P3=f3(x) is the added probability value of the load balancing component metric in the decision model calculated according to the number of sub-services containing the load balancing component;

[0026] d) The probability value calculation function of the gateway component metric is:

[0027] f4(x)=IA(x)

[0028] Where x is the number of sub-services containing gateway components obtained from the microservice information and component library.

[0029] P4=f4(x) is the added probability value of the gateway component metric in the decision model calculated based on the number of sub-services that include the gateway component;

[0030] (3) According to the importance of each metric, a specific weight is assigned to the added probability value of each metric in the final decision model to obtain the final decision model function. Let the weights of the added probability values ​​of the four metric indicators, namely the number of sub-services, service registration and discovery components, load balancing components, and gateway components, in the final decision model function be represented by w1, w2, w3, and w4, respectively, w1 = 0.3, w2 = 0.5, w3 = 0.1, and w4 = 0.1. The final decision model function is:

[0031] P=w1*P1+w2*P2+w3*P3+w4*P4;

[0032] Where P is the probability value of the input target software project using the microservice architecture.

[0033] Furthermore, in step 2), the specific process of preprocessing the target software project to obtain a set of sub-service entities with a granularity that may be a single sub-service entity is as follows:

[0034] Traverse all folder directories in the input project, where the parent folder directory of the src folder may contain a single sub-service, and save the parent folder directory path of these src folders to the storage that may be a single sub-service entity b i The set B = {b1, b2, ..., b n}middle.

[0035] Furthermore, in step 3), the specific process of statically analyzing each entity to detect whether it uses the components related to the metrics in the decision model and storing the relevant information in the microservice information and component library is as follows:

[0036] (1) Detect entity b in set B obtained in step 2) respectively i Whether it contains pom.xml file or build.gradle file;

[0037] (2) If entity b i The pom.xml file is contained in the repository, indicating that the entity uses the Maven build tool to manage dependencies. Therefore, the third-party dependencies introduced by the dependencies node are obtained by parsing the pom.xml file. Based on these third-party dependencies, it can be determined whether the entity uses the service registration and discovery component, the load balancing component, and the gateway component.

[0038] (3) If entity b i The build.gradle file is included, indicating that the entity uses the gradle build tool to manage dependencies. Therefore, by parsing the build.gradle file to obtain third-party dependencies, we can find out whether the entity uses the service registration and discovery component, load balancing component, and gateway component.

[0039] (4)Entity b i The name of the entity, the path of the folder directory where it is located, and the component information used by the entity are stored in the microservice information and component library L.

[0040] Furthermore, the specific process of obtaining the sub-service quantity information related to each metric in the decision model in step 4) is as follows:

[0041] (1) Count the number of entities x1 that contain at least one type of component from the microservice information and component library L established in step 3), and this value is the number of sub-services;

[0042] (2) Count the number of entities containing service registration and discovery components x2 from the microservice information and component library L established in step 3), which is the number of sub-services containing service registration and discovery components;

[0043] (3) Count the number of entities that include the load balancing component x3 from the microservice information and component library L established in step 3), which is the number of sub-services that include the load balancing component;

[0044] (4) Count the number of entities containing the gateway component from the microservice information and component library L established in step 3) x 4, which is the number of sub-services containing the gateway component.

[0045] Furthermore, in step 5), the specific process of calculating the probability value P of the target software project using the microservice architecture according to the probability value calculation function and the decision model function is as follows:

[0046] (1) Substitute the sub-service quantity value x1 obtained from step 4) into the probability value calculation function f1(x) of the sub-service quantity measurement indicator to obtain the added probability value P1 of the sub-service quantity measurement indicator in the decision model;

[0047] (2) Substitute the number of sub-services x2 including the service registration and discovery component obtained from step 4) into the probability value calculation function f2(x) of the service registration and discovery component metric to obtain the added probability value P2 of the service registration and discovery component metric in the decision model;

[0048] (3) Substitute the number of sub-services including the load balancing component x3 obtained from step 4) into the probability value calculation function f3(x) of the load balancing component metric to obtain the added probability value P3 of the load balancing component metric in the decision model;

[0049] (4) Substituting the number of sub-services including the gateway component x4 obtained from step 4) into the probability value calculation function f4(x) of the gateway component metric to obtain the added probability value P4 of the gateway component metric in the decision model;

[0050] (5) Substitute the added probability values ​​calculated in the above four steps into the final decision model function

[0051] P=w1*P1+w2*P2+w3*P3+w4*P4

[0052] Among them, w1=0.3, w2=0.5, w3=0.1, w4=0.1, and the probability value P of the target software project using the microservice architecture is calculated.

[0053] Beneficial effects: The method of the present invention constructs a decision model for architecture identification based on the characteristics of the microservice architecture. The model is combined with the metric information related to the microservice architecture in the target software project obtained through static analysis to calculate the overall probability of judging whether the target software project uses the microservice architecture. Compared with the prior art, the method of the present invention has the following advantages:

[0054] (1) The features of the microservice architecture are expanded, the recognition effect is better, and the recognition accuracy is higher. The microservice architecture recognition method based on multi-category features and multiple metrics proposed in the present invention deeply considers the characteristics of the microservice architecture, and specifically selects universal metrics that can effectively reflect the characteristics of the microservice architecture. A calculation function that can represent the characteristics of each metric is designed to calculate its added probability value for the microservice architecture decision model. In addition, according to the importance of each metric, the weight value of the metric in the final architecture recognition probability calculation function is assigned to it. Therefore, compared with the existing architecture recognition methods, the recognition accuracy is higher.

[0055] (2) The identification results contain richer content. The microservice architecture identification method based on multiple categories of features and multiple metrics proposed in the present invention extracts the components that reflect the microservice architecture characteristics used by the service entity during the identification process. Compared with the identification results of the existing architecture identification methods, it contains richer content and can better restore the microservice characteristics within the target software project.

[0056] (3) The microservice architecture identification method proposed in the present invention is fully automated. The method of the present invention takes the target software project as input, and the remaining steps are completed automatically. After the identification is completed, the probability value of the identified microservice architecture and the component information used by each sub-service are automatically given. BRIEF DESCRIPTION OF THE DRAWINGS

[0057] Figure 1 It is a flow chart of the present invention.

[0058] Figure 2 It is a data flow diagram of the present invention, which represents the connection between the functional modules and data information involved in the present invention.

[0059] Figure 3 It is a function model diagram of the probability value calculation function of the sub-service quantity measurement indicator.

[0060] Figure 4 It is a function model diagram of the probability value calculation function of the service registration and discovery component metric indicator.

[0061] Figure 5 It is a function model diagram of the load balancing component metric probability value calculation function. DETAILED DESCRIPTION

[0062] In order to deepen the recognition and understanding of the present invention, the technical solution of the present invention is described in detail below with reference to the accompanying drawings:

[0063] Figure 1 A flowchart of the present invention is given, in which the architecture identification process mainly includes four steps: preprocessing, static analysis, indicator information acquisition and probability calculation. The probability calculation requires the decision model we constructed.

[0064] According to the steps we mentioned above, implement them one by one:

[0065] The first step is to build a decision model.

[0066] (1) Definition of the probability value calculation function of the sub-service quantity measurement indicator:

[0067] Microservice projects are different from general monolithic Java projects. Monolithic Java projects generally only have one src source code directory, but microservices are different. The collaborative work of multiple subservices is an important feature of microservice projects. This is reflected in the target software project where there may be multiple subservices containing src folders within the project. Comprehensive analysis shows that the probability value calculation function of the subservice quantity measurement indicator should have the following characteristics: ① When the number of subservices is small, the function value approaches 0; ② When the number of subservices is large and the more subservices there are, the closer the function value approaches 1. When the number of subservices reaches a certain value, the probability addition caused by the indicator tends to be flat, that is, the function value changes tend to be flat. Therefore, we define the probability value calculation function of the subservice quantity measurement indicator as

[0068]

[0069] Function model such as Figure 3 shown.

[0070] (2) Definition of the probability value calculation function for service registration and discovery component metrics:

[0071] We regard entities with service registration and discovery components as real sub-services and mark them. They are core members of the microservice architecture. The more marked sub-services are detected, the more beneficial it is for the identification of the microservice architecture. Therefore, the number of marked sub-services and the final probability value are positively correlated, but the impact of the number of marked sub-services on the final probability value cannot be a simple linear relationship. When the number of marked sub-services reaches a certain value, the probability bonus corresponding to the indicator should be close to the peak value and tend to be stable. Comprehensive analysis of the probability value calculation function of the service registration and discovery component metric indicator should have the following characteristics: ① If the number of sub-services with service registration and discovery components is 0, the function value is 0; ② If there is a sub-service with service registration and discovery components, the function value approaches 1, and the more sub-services of this type, the closer the function value is to 1, but the probability bonus tends to be flatter in the future, that is, the function value changes tend to be flat. Therefore, we define the probability value calculation function of the service registration and discovery component metric indicator as

[0072]

[0073] Function model such as Figure 4 shown.

[0074] (3) Definition of the load balancing component metric probability value calculation function:

[0075] Load balancing is also a common component in microservice projects. Usually in microservices, a service can be supported by a cluster to support many servers, so load balancing is very necessary, which is also a manifestation of high availability of microservice projects. Although other non-microservice projects may also have load balancing, the deployment scale is far less than that of microservice projects. That is, whether a project uses a microservice architecture is highly related to the scale of load balancing. The function characteristics are similar to the probability value calculation function of the service registration and discovery component metric indicator, so we define the load balancing component metric indicator probability value calculation function as

[0076]

[0077] Function model such as Figure 5 shown.

[0078] (4) Gateway component metric probability value calculation function definition:

[0079] The gateway component is a commonly used component in microservice projects. The gateway component may not be necessary, but if it is used, it is beneficial for the identification of the microservice architecture. Unlike the above indicators, the existence of the gateway component is generally a yes-or-no relationship for the microservice architecture, that is, it either exists or does not exist. Therefore, we use an indicator function to correspond to this relationship and define the probability value calculation function of the gateway component metric as

[0080] f4(x)=IA(x)

[0081] That is, when the number of sub-services with gateway components is 0, the function value is 0; otherwise, the function value is 1.

[0082] Regarding the weight distribution of each metric, since the service registration and discovery component is the core component in the microservice project, each sub-project needs to register and discover the service if it needs to provide its own services to the outside world or request other services. Therefore, in the process of identifying the microservice architecture, the detection of the service registration and discovery component is crucial, so we assign a larger weight of 0.5 to identify this indicator; and the load balancing component and the gateway component are both commonly used components of microservices, but they are not required. In order to weaken the probability of identifying some microservice projects that do not have these two types of components, we assign a smaller weight of 0.1 to identify these two indicators; the remaining 0.3 weight is given to the sub-service quantity metric.

[0083] The second step is preprocessing.

[0084] The main task of preprocessing is to detect the src folder of the input target software project, and regard the parent folder of the detected src folder directory as an entity that may be a single sub-service and store it in the entity collection.

[0085] The third step is static analysis.

[0086] The main task of static analysis is to analyze each entity b in the entity set B obtained by preprocessing. i Components related to metrics are tested separately. The testing process first determines the build tool used by the entity based on the configuration file type, and then uses different methods to parse the configuration file according to different build tools to obtain the dependency package information of each component, thereby determining whether the relevant components are used, and storing the judgment results and entity information in the microservice information and component library L.

[0087] The fourth step is to obtain indicator information.

[0088] The main task of obtaining indicator information is to count the number of sub-services related to the metrics in the decision model from the microservice information and component library.

[0089] Step 5: Probability calculation.

[0090] The main task of probability calculation is to calculate the probability of the target software project using the microservice architecture based on the indicator information obtained from the quantity information of sub-services related to each indicator and the framework model.

[0091] Example:

[0092] For the convenience of description, we take the identification process of the ruoyi-cloud open source project as an example. The ruoyi-cloud project is an open source microservice project based on the SpringCloud framework, integrating core microservice components such as eureka, gateway, and feign.

[0093] According to the steps mentioned above, implement them in sequence (because building a decision model is independent of a specific target software project, we will not introduce this part of the steps in the embodiment):

[0094] The first step is preprocessing.

[0095] After preprocessing the ruoyi-cloud project, we will get an entity set B, which contains 15 entities b that may be sub-services i, entity set B = {ruoyi-common-auth, ruoyi-common-core, ruoyi-common-log, ruoyi-common-redis, ruoyi-common-swagger, ruoyi-config, ruoyi-eureka, ruoyi-gateway, ruoyi-activiti, ruoyi-auth, ruoyi-dfs, ruoyi-gen, ruoyi-system, ruoyi-system-api, ruoyi-monitor}.

[0096] The second step is static analysis.

[0097] By performing static analysis on the entity set B obtained after preprocessing, we will obtain the microservice information and component library L of the ruoyi-cloud project, among which the entities using the service registration and discovery component Eureka are recorded as ruoyi-config, ruoyi-eureka, ruoyi-gateway, ruoyi-activiti, ruoyi-auth, ruoyi-dfs, ruoyi-gen, ruoyi-system, and ruoyi-monitor; the entities using the load balancing component Feign are ruoyi-auth, ruoyi-dfs, and ruoyi-system; the entities using the gateway component Zuul are ruoyi-auth, and the entities using the gateway component SpringCloud Gateway are ruoyi-gateway.

[0098] The third step is to obtain indicator information.

[0099] Based on the microservice information and component library L, the number of sub-services related to the metric indicators is counted. There are 9 entities in the ruoyi-cloud project that have at least one type of component, namely ruoyi-config, ruoyi-eureka, ruoyi-gateway, ruoyi-activiti, ruoyi-auth, ruoyi-dfs, ruoyi-gen, ruoyi-system, and ruoyi-monitor, so the number of sub-services x1=9; there are 9 sub-services with service registration and discovery components, so the number of sub-services including service registration and discovery components is x2=9; there are 3 sub-services with load balancing components, so the number of sub-services including load balancing components is x3=3; there are 2 sub-services with gateway components, so the number of sub-services including gateway components is x4=2.

[0100] Step 4: Probability calculation.

[0101] Combined with the information obtained above, the probability that the ruoyi-cloud project uses the microservice architecture is P = w1*P1+w2*P2+w3*P3+w4*P4 = w1*f1(x1)+w2*f2(x2)+w3*f3(x3)+w4*f4(x4)≈0.9406=94.06%.

[0102] It should be noted that the above embodiments are only preferred embodiments of the present invention. For ordinary technicians in this technical field, several improvements and equivalent substitutions can be made without departing from the principles of the present invention. These technical solutions after improvements and equivalent substitutions to the claims of the present invention all belong to the protection scope of the present invention.

Claims

1. A microservice architecture identification method based on multiple features and multiple metrics, characterized in that: The method comprises the following steps: Step 1) Construct a decision model P for microservice architecture identification based on the characteristics of the microservice architecture a , used to calculate the probability P of the target software project using the microservice architecture, where a is the metric in the decision model; Step 2) Input the source code of a target software project, pre-process the target software project to obtain a granularity size that may be a single sub-service entity b i The set B = {b1, b2, ..., b n }; Step 3) Based on the entity set B obtained in step 2), each entity b in B is i Perform static analysis to detect whether it uses components related to the metrics in the decision model, and store the relevant information in the microservice information and component library L; Step 4) Based on the microservice information and component library L established in step 3), obtain the subservice quantity information x related to each metric in the decision model; Step 5) Based on the information x on the number of sub-services related to the metric obtained in step 4), the probability value calculation function and decision model function corresponding to each metric are used to calculate the probability value P of the target software project using the microservice architecture; The construction of the decision model in step 1) is as follows: (1) Summarize and summarize the characteristics of microservice architecture and divide them into three categories: scale characteristics, component characteristics and topology characteristics. Select representative and universal characteristics as the measurement indicators for microservice architecture identification and construct the measurement indicator set A = {a1, a2, a3, a4}, where a1 is the measurement indicator of the number of subservices in the scale characteristic, a2 and a3 are the measurement indicators of the service registration and discovery component and load balancing component in the component characteristic, and a4 is the measurement indicator of the gateway component in the topology characteristic. (2) According to each metric a i The characteristics of each metric define a probability value calculation function f i (x), this calculation function calculates the additional probability value P for the microservice architecture decision model based on the relevant quantity information x of the metric in the target software project i , as follows: a) The probability value calculation function of the sub-service quantity measurement indicator is: Where x is the number of sub-services obtained from the microservice information and component library, and P1=f1(x) is the added probability value of the sub-service quantity metric in the decision model calculated based on the number of sub-services; b) The probability value calculation function of the service registration and discovery component metric is: Where x is the number of sub-services including the service registration and discovery component obtained from the microservice information and component library, and P2=f2(x) is the additional probability value of the service registration and discovery component metric in the decision model calculated based on the number of sub-services including the service registration and discovery component; c) The probability value calculation function of the load balancing component metric is: Where x is the number of sub-services containing the load balancing component obtained from the microservice information and component library, and P3=f3(x) is the added probability value of the load balancing component metric in the decision model calculated according to the number of sub-services containing the load balancing component; d) The probability value calculation function of the gateway component metric is: f4(x)=IA(x) Where x is the number of sub-services containing the gateway component obtained from the microservice information and component library, and P4=f4(x) is the added probability value of the gateway component metric in the decision model calculated based on the number of sub-services containing the gateway component; (3) According to the importance of each metric, a specific weight is assigned to the added probability value of each metric in the final decision model to obtain the final decision model function. Let the weights of the added probability values ​​of the four metric indicators, namely the number of sub-services, service registration and discovery components, load balancing components, and gateway components, in the final decision model function be represented by w1, w2, w3, and w4, respectively. w1 = 0.3, w2 = 0.5, w3 = 0.1, and w4 = 0.

1. The final decision model function is: P=w1*P1+w2*P2+w3*P3+w4*P4 Where P is the probability value of the input target software project using the microservice architecture.

2. The microservice architecture identification method based on multiple features and multiple metrics according to claim 1 is characterized in that: The specific process of preprocessing the target software project in step 2) to obtain a set of sub-service entities with a granularity that may be a single sub-service entity is as follows: Traverse all folder directories in the input project, where the parent folder directory of the src folder may contain a single sub-service, and save the parent folder directory path of these src folders to the storage that may be a single sub-service entity b i The set B = {b1, b2, ..., b n }middle.

3. The microservice architecture identification method based on multiple features and multiple metrics according to claim 1 is characterized in that: The specific process of performing static analysis on each entity in step 3) to detect whether it uses the components related to the metrics in the decision model and storing the relevant information in the microservice information and component library is as follows: (1) Detect entity b in set B obtained in step 2) respectively i Whether it contains pom.xml file or build.gradle file; (2) If entity b i The pom.xml file is contained in the repository, indicating that the entity uses the Maven build tool to manage dependencies. Therefore, the third-party dependencies introduced by the dependencies node are obtained by parsing the pom.xml file. Based on these third-party dependencies, it is determined whether the entity uses the service registration and discovery component, the load balancing component, and the gateway component. (3) If entity b i The build.gradle file is included, indicating that the entity uses the gradle build tool to manage dependencies. Therefore, by parsing the build.gradle file to obtain third-party dependencies, we can find out whether the entity uses the service registration and discovery component, load balancing component, and gateway component. (4)Entity b i The name of the entity, the path of the folder directory where it is located, and the component information used by the entity are stored in the microservice information and component library L.

4. The microservice architecture identification method based on multiple features and multiple metrics according to claim 1 is characterized in that: The specific process of obtaining the sub-service quantity information related to each metric in the decision model in step 4) is as follows: (1) Count the number of entities x1 that contain at least one type of component from the microservice information and component library L established in step 3), and this value is the number of sub-services; (2) Count the number of entities containing service registration and discovery components x2 from the microservice information and component library L established in step 3), which is the number of sub-services containing service registration and discovery components; (3) Count the number of entities that include the load balancing component x3 from the microservice information and component library L established in step 3), which is the number of sub-services that include the load balancing component; (4) Count the number of entities containing the gateway component from the microservice information and component library L established in step 3) x 4, which is the number of sub-services containing the gateway component.

5. The microservice architecture identification method based on multiple features and multiple metrics according to claim 1 is characterized in that: The specific process of calculating the probability value P of the target software project using the microservice architecture according to the probability value calculation function and the decision model function in step 5) is as follows: (1) Substitute the sub-service quantity value x1 obtained from step 4) into the probability value calculation function f1(x) of the sub-service quantity measurement indicator to obtain the added probability value P1 of the sub-service quantity measurement indicator in the decision model; (2) Substitute the number of sub-services x2 including the service registration and discovery component obtained from step 4) into the probability value calculation function f2(x) of the service registration and discovery component metric to obtain the added probability value P2 of the service registration and discovery component metric in the decision model; (3) Substitute the number of sub-services including the load balancing component x3 obtained from step 4) into the probability value calculation function f3(x) of the load balancing component metric to obtain the added probability value P3 of the load balancing component metric in the decision model; (4) Substituting the number of sub-services including the gateway component x4 obtained from step 4) into the probability value calculation function f4(x) of the gateway component metric to obtain the added probability value P4 of the gateway component metric in the decision model; (5) Substitute the added probability values ​​calculated in the above four steps into the final decision model function P=w1*P1+w2*P2+w3*P3+w4*P4 Among them, w1=0.3, w2=0.5, w3=0.1, w4=0.1, and the probability value P of the target software project using the microservice architecture is calculated.

Images