CN112925709A - Micro-service maintainability assessment method based on multi-source characteristic space - Google Patents
Micro-service maintainability assessment method based on multi-source characteristic space Download PDFInfo
- Publication number
- CN112925709A CN112925709A CN202110217627.2A CN202110217627A CN112925709A CN 112925709 A CN112925709 A CN 112925709A CN 202110217627 A CN202110217627 A CN 202110217627A CN 112925709 A CN112925709 A CN 112925709A
- Authority
- CN
- China
- Prior art keywords
- service
- services
- micro
- opr
- dsm
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3604—Software analysis for verifying properties of programs
- G06F11/3608—Software analysis for verifying properties of programs using formal methods, e.g. model checking, abstract interpretation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3604—Software analysis for verifying properties of programs
- G06F11/3616—Software analysis for verifying properties of programs using software metrics
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Debugging And Monitoring (AREA)
Abstract
The invention discloses a micro-service maintainability assessment method based on a multi-source characteristic space, which comprises the following steps: s1: carrying out multi-source feature space modeling on Design elements of a software system, representing a binary relation between the Design elements by using a Design Structure Matrix (DSM), and generating a corresponding Design structure matrix DSM according to a binary mapping function sigma between different Design elements; s2, generating a micro-service maintainability evaluation index based on the multi-source feature space based on the DSM generated in the step S1 by using the micro-service maintainability evaluation method based on the multi-source feature space. Based on the multi-source characteristic space of the software system, the maintainability evaluation is carried out on the micro-service system, and the maintainability evaluation accuracy is improved.
Description
Technical Field
The invention relates to the field of micro-service and software maintainability assessment, in particular to a multi-source characteristic space-based micro-service maintainability assessment method.
Background
With the maturity of cloud computing technology and the continuous increase of business requirements of enterprises, the enterprises migrate the legacy software systems into (micro) service-based architectures, so as to fully utilize cloud infrastructure, flexibly perform business expansion and performance expansion, and reduce maintenance cost. Compared with a single framework which is a paradigm of uniformly managing and packaging all modules of the system into a single application program, the micro-service framework is composed of independent services, dynamic interaction is carried out among the services through a lightweight communication protocol, and each service is independently modified, developed, deployed and maintained. However, the micro-service splitting (or decoupling) process for the legacy system is complex and costly. Obtaining better Maintainability (Maintainability) is one of the main drivers that enterprises are willing to invest high costs for microservice splitting.
The micro service code maintainability measurement still has the following difficulties:
heterogeneous and multi-source data. The microservice splitting process uses data such as data streams, software structures, interface information, running traces, etc. that originate from different artifacts such as source code, code revision history, running logs of code, etc. And data of different sources have heterogeneous characteristics, so that the maintainability measurement of the micro-service code is difficult to consider the multi-source heterogeneous data simultaneously.
Code maintainability concerns diversification. According to the ISO25010 software quality model, maintainability is represented by a number of concerns, such as the degree to which software can be efficiently and effectively modified, the degree of reusability, the degree of modularity, the degree to which it can be efficiently and effectively analyzed at the time of modification or troubleshooting, and the like. However, due to the difficulty in considering multi-source heterogeneous data, the micro-service code maintainability metric also has difficulty in taking into account the various concerns of evaluating the aforementioned maintainability.
Disclosure of Invention
In order to solve the difficulty of the micro-service code maintainability measurement, the invention aims to provide a micro-service maintainability assessment method based on a multi-source feature space, which can assess the maintainability index of a micro-service system respectively from four aspects of modularity, functionality, repairability and interaction complexity based on a multi-source feature space model of a software system.
In order to achieve the purpose, the invention adopts the technical scheme that:
the micro-service maintainability assessment method based on the multi-source feature space comprises the following steps:
step S1: and expressing the characteristics of the software system into a multi-source characteristic space, and performing multi-source characteristic space modeling on the software system. And generating a corresponding design structure matrix DSM according to a binary mapping function sigma between different design elements.
Step S101-Generation of DSMs (Structure DSMs): the binary relational mapping function of the DSMs is σ structure (classi, classj), which computes the structural dependencies of classi and classj in the source code. Structural dependencies between classes, such as inheritance, interface implementation, invocation, parameter type reference, return value type reference, and the like, are extracted by analyzing an abstract syntax tree of the source code. If slave classiTo classjIf there is any of the above structural dependencies, then the value of cell (i, j) in DSM is 1, otherwise the value is null.
Step S102-generating DSMsc(concept DSM): generating DSMsc(concept DSM) a binary relational mapping function of σconcept(classi, classj), the mapping function computes classiAnd classjSimilarity in semantics. Semantic similarity exists between the two classes if the intersection of the words of text identifiers that make up the two classes is not null, with the cell (i, j) having a value of 1 in the DSM, and null otherwise.
Step S103 — generate dsmc (evolution dsm): the binary mapping function that generates DSMc is σ Evolution (fileei, filej), and the mapping function calculates the common modification degree of fileei and filej in the code Evolution process. Referring to the method of M, the number of submissions (commit) in the software revision history that both filei and filej have been modified together may be taken as the value of cell (i, j) in the DSM.
Step S104-Generation of DSMm (message DSM): the binary mapping function that generates DSMm is (opri, oprj), which computes the similarity of opri and oprj at the message granularity. The similarity of message granularity is the average of the similarity between the input messages (i.e., parameters) of opri and oprj and the similarity between the output messages (i.e., return values). The calculation formula is as follows:
wherein retiAnd pariAre each opriA set of return values and a set of input parameters.
Step S105-generating DSMsd(Domain DSM): generating DSMsdIs (opri, oprj), the mapping function calculates opriAnd oprjSimilarity at message granularity. The similarity of the domain sizes is opriAnd oprjThe method of (3) similarity between signatures. The calculation formula is as follows:
wherein f isterm(opri) represents operation opriThe signature of (2) comprises a collection of domain words.
Step S106-generating DSMsu(update DSM): generating DSMsuHas a binary relation mapping function ofupdation(gi,filej) The mapping function is calculated at a maintenance function giTime pair filejThe commit number of the update operation such as addition or modification is performed. These commit are accompanied by a number ID and this ID is identified as "new feature" in the Issue Tracking System (Issue Tracking System) for the item of software. And grouping the submitted records in the revision history according to the ID, and counting the commit number of the file filej in the submitted record set corresponding to each function ID.
Step S107-Generation of DSMb(Behavior DSM) Generation of DSMbThe binary relation mapping function of is sigma behavior (t)i,(opri,oprj) T) is calculated by the mapping functioniFortune ofIncluded in the row track is (opr)i,oprj) And (4) counting. t is tiBy inter-method or inter-operation call actions (opr)i,oprj) The sequence of the composition. A software tracking tool such as a Kieker is used for monitoring the running of a software system to obtain a running track, and the tracking technology is characterized in that an inlet and an outlet of a method or an operation are inserted, an execution log is recorded before and after the method or the operation is executed, and the execution track of the system is recovered from the execution log.
Step S108-generating DSMsp(interactionprobabilitic DSM): generating DSMspHas a binary relation mapping function ofprobability(SCi, SCj), the mapping function calculates the service SC in the trajectory TiUnder the participation condition, SCjProbability of participating in the interaction as well. The larger the mapping value, the greater the likelihood that two services are simultaneously involved in performing an interaction, meaning that the two services are coupled to a greater degree.
Step S2: and generating a micro-service maintainability evaluation index based on the multi-source feature space based on the DSM generated in the step S1 by using the micro-service maintainability evaluation method based on the multi-source feature space.
Step S201: the Modularity of the microservice system is measured separately from the Structural Modularity (SMQ) and the Conceptual Modularity (CMQ). The degree of structural modularity refers to the degree of modularity of a service measured in the structural dimension. The larger the structure modularity value is, the higher the modularity degree of the service is. Concept modularity refers to the degree to which a service is modular in either the concept or semantic dimension. The larger the conceptual modularity value, the higher the modularity of the service. The structural modularity is calculated using the following formula:
scoh measures the degree of cohesion, scop, of a servicei,jMeasure the coupling degree between services, and count out u based on DSMsiAnd vi,j,uiIs the number of edges between all entities within a service i, vi,jIs the number of edges between the entity within service i and the entity within service j. N is a radical ofiOr NjIndicating the number of entities contained in service i or service j. The larger the scoh value and the smaller the scop value, the better the structural modularity of the service.
The conceptual modularity is calculated using the following formula:
the calculation formulas of ccoh and ccop are similar to scoh and scop in SMQ respectively. In contrast, CMQ is the statistic of u according to DSMciAnd vi,jThe value of (c).
Step S202: the functionality of the microservice system is measured from three aspects of InterFace granularity (IFN), coherence of an InterFace Message layer (CHM), coherence of an InterFace Domain layer (CHD), and the like. Number of open interfaces for IFN metric service. The smaller the IFN, the smaller the interface granularity for the service, and the more likely it will have a single role. The IFN metric formula is as follows:
ifnj=|Ij|
chm measure the degree of cohesion of the exposed interface of the service at the message layer. The larger the chm value, the more consistent and cohesive the interface provided to the outside. CHM is the average of the cohesion degree of all services, and the measurement formula is as follows:
chd measures the degree of cohesion of the external interface at the domain level. The larger the chd value is, the more cohesive the external interface provided by the service is in the field. Similarly, CHD is the average of CHD of all services in the microservice system, and its metric formula is as follows:
step S203: the repairable modification of the micro-service system is evaluated from three aspects of Intra Co-change Frequency (ICF), cross service Co-change Frequency (ECF) and Ratio of cross service entity to Intra service entity covariant Frequency (Ratio of ECF to ICF, REI). icf measures the frequency of co-modification by entities within a candidate service. Higher icf values mean that entities within the service are more likely to modify the evolution together. ICF is the average of all ICFs in the system, and its metric formula is as follows:
ecf measure the frequency with which entities assigned to different services change together. A lower value of ecf means that entities crossing service boundaries are more likely to modify independently. The ECF is the average of all services ECF in the system and is measured as follows:
REI measures the ratio of the co-modification frequency across service entities to the co-modification frequency of entities within a service. If the common modifications occur more frequently within the service than between services, the REI value will be less than 1.0. The smaller the value, the lower the probability of modifying different services together, and the more likely the services will evolve independently and be maintained independently, the metric formula of which is as follows:
step S204: the interaction complexity describes the complexity of the interaction behavior between services, and the higher the interaction complexity, the higher the difficulty of analysis activities such as fault diagnosis and fault repair may be. The step is to evaluate the interaction complexity of the micro-Service system from five aspects of the Number of services (ISG) for processing the user request, the Inter-Service call Chain Length (ICL) for processing the user request, the Number of Service Cyclic calls (SCN) for processing the user request, the Degree of Dependence on other services (In-dependent density, IDD) and the Degree of Dependence on other services (Out-dependent density, ODD) and the like based on a multi-source feature space model. The ISG refers to the number of different services passing through when the user request is processed, the interaction between the services is more complex when the ISG is larger, and the measurement formula is as follows:
the larger the cross-service call chain length ICL when processing a user request, the higher the interaction complexity between services. The ICL is measured in a similar manner to the ISG described above. The difference is that the number of different services passed by the ISG metric processing request and the number of cross-service calls passed by the ICL metric processing request are as follows:
icli=|S|,S={(oprm,oprn)}
the service loop call is the inverse of the microservice design. A larger SCN value indicates a higher degree of complex interaction between services and a poorer analyzability. Based on the MFS DSMp, the formula for measuring SCN is as follows:
SCN=|S|,S={(i,j)|(i,j)≠None∧σprobability(j,i)≠None∧i<j}
IDD measures the degree to which one service is invoked by other services. The larger the IDD value, the higher the degree of coupling and the higher the degree of dynamic interaction between services. MFS-based DSMpThe formula for the metric IDD is as follows:
ODD measures the degree to which one service invokes another service. The larger the ODD value is, the higher the degree of coupling of the service with other services is, and the degree of dynamic interaction between the services is high. Similar to IDD, the ODD metric is based on DSMpThe formula for measuring ODD is as follows:
compared with other existing methods for evaluating maintainability measurement of the micro-service system, the method provided by the invention considers the problems of heterogeneous and multiple sources of data and diversified attention points of code maintainability in the evaluation of the micro-service system, and carries out maintainability evaluation on the micro-service system based on the multi-source characteristic space of the software system, thereby improving the maintainability evaluation accuracy.
Drawings
FIG. 1 is a basic flow diagram of maintainability assessment based on a multi-source feature space;
FIG. 2 is a detailed flow chart of maintainability assessment based on multi-source feature space, focusing on the input parameters and output metrics at various stages of the method;
FIG. 3: IFN value box chart of Train-Ticket system
FIG. 4: Train-Ticket system CHM, CHD boxplot
FIG. 5: Train-Ticket system ICF, ECF and REI box line diagram
FIG. 6: REI curve diagram of each micro-service of Train-Ticket system
FIG. 7: ISG (Integrated Circuit Package) and ICL (Integrated Circuit Package) box diagram of Train-Ticket system
FIG. 8: ISG curve diagram of each micro-service operation track of Train-Ticket system
FIG. 9: ICL curve diagram of each micro-service operation track of Train-Ticket system
FIG. 10: ODD and IDD box line diagram of Train-Ticket system
FIG. 11: ODD (ODD-inverse discrete Difference) and IDD (inverse discrete Difference) curve chart of each micro-service in Train-Ticket system
Detailed Description
The left dashed box of fig. 1 represents the specific input to the evaluation process: software source code, software running track and revision history; the middle process represents a multi-element feature space modeling process, namely step S1 of the specification, and the output of the step is a multi-source feature space of the software system, corresponding to various design structure matrixes DSM of FIG. 2; the final process represents a maintainability assessment process with the multivariate feature space as input, corresponding to step S2 of the specification, where a multisource feature space-based microservice maintainability assessment index is generated, corresponding to various indexes of the maintainability measurement process of fig. 2 that produce measures of modularity, functionality, modifiable, and interactive complexity.
Fig. 3 to 11 are calculation result diagrams for showing the respective steps of the embodiment.
In order to make the objects, features and advantages of the present invention more apparent and understandable, embodiments of the present invention are described in detail below with reference to the accompanying drawings and examples.
The open source microservice reference system Train-packet is used as an experimental object of the evaluation method, and the evaluation is carried out by using the method.
Step S1: the software system is subjected to multi-source feature space modeling, and a Design Structure Matrix (DSM) is used for representing binary relations among Design elements.
Obtaining entity number E of microservicesserInterface number I, operand O. And analyzing the source code of the Train-packet by using a SCITOOL Understand tool, and counting the entity Eser, the interface I and the operation O of each micro-service. The data obtained are as follows.
Microservice statistics for Train-Ticket system
And acquiring source code, revision history and a running track. The Train-Ticket project provides source codes and revision history, and because the Train-Ticket system integrates Jacger monitoring, the system is deployed as required and then tested according to the test scene provided by a maintainer, and the running track can be obtained.
Data collection results
From the collected data, a design structure matrix of the software system is calculated using the calculation method mentioned in steps S101 to S108 in the specification, representing a binary relationship between design elements.
Step S2: the method for evaluating the maintainability of the micro-service based on the multi-source characteristic space generates the maintainability evaluation index of the micro-service based on the multi-source characteristic space based on the DSM generated in the step S1
Step S201: respectively measuring the Modularity of the microservice system from the Structural modulation, SMQ and the Conceptual modulation, CMQ, respectively, using the calculation formula in the instruction step S201, combining the Structural design matrix DSMsAnd DSMcThe SMQ and CMQ values for each service are calculated.
Step S202: the functionality of the microservice system is measured from three aspects of InterFace granularity (IFN), coherence of an InterFace Message layer (CHM), coherence of an InterFace Domain layer (CHD), and the like. Using the calculation formula in step S202 of the specification, the design matrix DSM is combined with the structuremAnd DSMdCalculating IFN, CHM and CHD of each service, and the calculated box diagram of the IFN of the micro-service system is shown in figure 3, and the box diagram of the CHM and the CHD is shown in figure 4.
Step S203: the repairability of the micro-Service system is evaluated from five aspects of Intra-Service Co-change Frequency (ICF), cross-Service Co-change Frequency (ECF), Ratio of cross-Service entity to Intra-Service entity covariant Frequency (Ratio of ECF to ICF, REI), InStability of Service Interface in function modification (IIS) and degree of cross-Service function Evolution (ISE). Using the calculation formula in S203 in the specification step, the structural design matrix DSM can be utilizedeFig. 5 shows a box diagram of ICF, ECF and REI of each service, ICF, ECF and REI values of the micro service system, and fig. 6 shows a graph of each micro service REI of the micro service system.
Step S204: the Number of services (ISG) required by a user, the Length of Inter-Service call Chain (ICL) required by the user, the Number of Service cycle calls (SCN) required by the user, the Degree of Dependence on other services (In-Degree Dependence, IDD) and the Degree of Dependence on other services (Out-Degree Dependence)Science, ODD) evaluates the interaction complexity of the microservice system. Using the calculation formula in S204 in the specification step, the structural design matrix DSM can be utilizedbAnd DSMpThe ISG, ICL, SCN, IDD and ODD are calculated, the graphs of the ISG and ICL boxlines of the micro service system are shown in fig. 7, the graph of each ISG of the micro service system is shown in fig. 8, the graph of each ICL of the micro service system is shown in fig. 9, the graphs of the ODD and IDD boxlines of the micro service system are shown in fig. 10, and the graphs of each ODD and IDD of the micro service system are shown in fig. 11.
And finishing the maintainability evaluation of the micro service system Train-packet based on the multivariate feature space.
Claims (9)
1. The micro-service maintainability assessment method based on the multi-source feature space is characterized by comprising the following steps of:
step S1: representing the characteristics of a software system as a multi-source characteristic space, carrying out multi-source characteristic space modeling on the software system, using a Design Structure Matrix Design Matrix, DSM (Design Structure Matrix) to represent a binary relation between Design elements, and generating a Design Structure Matrix Structure Design Matrix (Design Structure Matrix, DSM) corresponding to the Design Structure Matrix according to a binary mapping function sigma between different Design elements;
step S2: and generating a micro-service maintainability evaluation index based on the multi-source feature space based on the DSM generated in the step S1 by using the micro-service maintainability evaluation method based on the multi-source feature space.
2. The multi-source Feature Space-based micro-service maintainability assessment according to claim 1, wherein step S1 requires representing the Feature extension of the software system as multi-source Feature Space (MFS), the multi-source Feature Space containing the design elements of the software and the binary relationship between the design elements.
3. The multi-source feature space-based micro-service maintainability assessment according to claim 1, wherein step S1 represents the features of the software system as a multi-source feature space, and the multi-source feature space should take into account at least the following multi-source spatial characteristics: the code, text, interface information, revision history and operation track of the software system extract diversified design elements and binary relations from the multi-source data, and the multi-source feature space MFS is expressed as:
MFS=<D,DSM,σ:(D,D)→DSM>
wherein D represents a set of design elements, D ═ E utoug uto. E represents a collection of entity elements of the software, the entity elements including method/operation (opr), class (class), interface (interface), file (file),
e ═ ClassSet @ FileSet @
The software is provided with an operation set, a ClassSet, an InterfaceSet, a FileSet, a function set provided by the software, a function set provided<(opr1,opr2),(opr3,opr4),...,(oprm-1,oprm)>,(opri,oprj) Representing call behavior between methods.
4. The multisource feature space-based micro-service maintainability assessment according to claim 1, wherein step S1 is to uniformly model these multisource heterogeneous data into multisource feature space by analyzing different data sources such as syntax structure, code text information, revision history, and operation track of the source code, and form a mapping function σ related to elements D and a corresponding structural design matrix DSM, and its specific steps are as follows:
step S101-Generation of DSMs (Structure DSMs): the binary relation mapping function of the DSMs is sigmastructure(classi,classj) The mapping function calculates classiAnd classjStructural dependencies in the source code;
step S102-generating DSMsc(concept DSM): generating DSMsc(concept DSM) a binary relational mapping function of σconcept(classi,classj) The mapping function calculates classiAnd classjSimilarity in semantics;
step S103-generating DSMsc(Evolution DSM): generating DSMscIs a binary mapping function ofEvolution(filei,filej) The mapping function calculates the fileiAnd filejCommon modification degree in the code evolution process;
step S104-generating DSMsm(Message DSM): generating DSMsmIs (opr) as the binary mapping functioni,oprj) The mapping function calculates opriAnd oprjSimilarity at message granularity;
step S105-generating DSMsd(Domain DSM): generating DSMsdIs (opr) as the binary mapping functioni,oprj) The mapping function calculates the similarity of opri and oprj in message granularity;
step S106 — generate dsmu (update dsm): the binary relation mapping function that generates the DSMu is σ update (gi, file)j) The mapping function calculates commit numbers of update operations such as addition or modification to filej when maintaining the function gi;
step S107-Generation of DSMb(Behavior DSM) Generation of DSMbThe binary relation mapping function of is sigma behavior (t)i,(opri,oprj) T) is calculated by the mapping functioniIs included in the trajectory of (opr)i,oprj) Number, tiBy inter-method or inter-operation call actions (opr)i,oprj) (ii) the sequence of (a);
step S108-generating DSMsp(interactionprobabilitic DSM): generating a binary relational mapping function of DSMp as σprobability(SCi,SCj) The mapping function calculates the service SC in the operation track TiUnder the participation condition, SCjAnd the greater the mapping value, the greater the probability that two services are simultaneously involved in performing an interaction, meaning the greater the degree to which the two services are coupled.
5. The multi-source feature space-based micro-service maintainability assessment according to claim 1, wherein in step S2, the micro-service code maintainability is comprehensively assessed from four points of interest, such as modularity, functionality, modifiability, and interaction complexity, using the multi-source feature space representing the software system features constructed in step S1, and the maintainability index of the micro-service system is calculated through four aspects, namely modularity, functionality, modifiability, and interaction complexity index, using the maintainability definition in the ISO25010 software quality model as the standard. The method specifically comprises the following steps:
step S201: respectively measuring Modularity of a micro-service system from Structural Modularity, SMQ and concept Modularity, CMQ, wherein the Structural Modularity refers to the Modularity of service measured on a Structural dimension, the larger the Structural Modularity is, the higher the Modularity of the service is indicated, the larger the concept Modularity refers to the Modularity of the service measured on a concept or semantic dimension, and the larger the concept Modularity is, the higher the Modularity of the service is indicated;
step S202: from three aspects of InterFace granularity Interface Number, IFN, InterFace Message layer CoHesion degree CoHesion at Message level, CHM and InterFace field layer CoHesion degree CoHesion at Domain level, CHD, respectively measuring modularity of the micro-service system, IFN measuring Number of public interfaces of the service, IFN being smaller to indicate that the InterFace granularity of the service is smaller and more likely to have single duty, CHM measuring the CoHesion degree of the public interfaces of the service in the Message layer, CHM value being larger to indicate that the externally provided interfaces are more consistent and cohesive, CHM being the mean value of the CoHesion degrees of all services, CHD measuring the CoHesion degree of the externally connected interfaces of the service in the field layer, CHD value being larger to indicate that the externally connected interfaces provided by the service are more cohesive in the field, and similarly, CHD being the mean value of CHD of all services in the micro-service system;
step S203: the modifiable nature of the microservice system is evaluated from three aspects of Intra-service Co-variant Frequency Intra-Co-change Frequency, ICF, inter-service Co-variant Frequency, ECF, Ratio of inter-service entity to Intra-service entity Co-variant frequencies, Ratio of ECF to ICF, REI, ICF measures the Frequency of entity Co-modification within candidate services, higher ICF values mean that entities within a service are more likely to modify evolution together, ICF is the average of all ICF in the system, ECF measures the Frequency of entity Co-modification distributed at different services, lower ECF values mean that entities across service boundaries are more likely to modify independently, ECF is the average of all services ECF in the system, REI measures the Ratio of inter-service entity Co-modification Frequency across service entities to Intra-service entity Co-modification, if Co-modification occurs more frequently within a service than between services, the REI value is less than 1.0, the smaller the value is, the lower the possibility that different services are modified together is, the more likely the services are to evolve independently and maintain independently, the IIS measures the average number of modifications to the service interface when one function is increased or modified, frequent modification of the service interface means that the designed service boundary is unclear and unstable, such a fuzzy and unstable interface is likely to be caused by unreasonable service division and unreasonable service interface design, the smaller the IIS value is, the more stable the service interface is, the degree of ISE evolution across service functions is measured by ISE, if modification or increase of the function involves modification of different services, it is considered that cross-service function evolution occurs, the larger the ISE value is, the more different services are involved in one function, and the function is more difficult to modify and maintain independently;
step S204: the interaction complexity describes the complexity of interaction between services, and the higher the interaction complexity, the higher the difficulty of analysis activities such as fault diagnosis and fault repair may be, this step evaluates the interaction complexity of the micro-Service system from five aspects such as the Number of services (Inter-Service Length, ISG) processing a user request, the Length of cross-Service call Chain (ICL) processing the user request, the Number of Service cycle calls (SCN) processing the user request, the Degree of Dependence on other services (In-Degree Dependence, IDD), and the Degree of Dependence on other services (Out-Degree Dependence, ODD) based on a multi-source feature space model.
6. The multi-source feature space-based micro-service maintainability assessment according to claim 1, wherein in step S201, the modularity of the micro-service system needs to be measured by the structural modularity and the conceptual modularity, respectively, and the specific formula for calculating the structural modularity is as follows:
wherein scoh measures the degree of cohesion, scop, of the servicei,jMeasure the coupling degree between services, and count out u based on DSMsiAnd vi,j,uiIs the number of edges between all entities within a service i, vi,jIs the number of edges between entities within service i and entities within service j, NiOr NjIndicates the number of entities contained in service i or service j,
the specific formula adopted for calculating the concept modularity is as follows:
the calculation formulas of ccoh and ccop are similar to scoh and scop in SMQ respectively, except that CMQ counts u according to DSMciAnd vi,jThe value of (c).
7. The multi-source feature space-based micro-service maintainability assessment according to claim 1, wherein in step S202, the modularity of the micro-service system needs to be measured from three aspects of InterFace granularity (IFN), InterFace Message level (CHM) and InterFace Domain level (CHD), respectively, where IFN is as follows:
ifnj=|Ij|
chm, measuring the cohesion degree of the public interface of the service at the message layer, and the specific measurement formula is as follows:
measuring the cohesion degree of the external interface of the service in the field layer by the chd, wherein the specific measurement formula is as follows:
8. the multisource feature space-based micro-Service maintainability assessment according to claim 1, wherein the step S203 needs to calculate five aspects of Intra-Service Co-change Frequency (ICF), Inter-Service Co-change Frequency (ECF), Ratio of Inter-Service entity to Intra-Service entity Co-change Frequency (Ratio of ECF to ICF, REI), InStability of Service Interface in function modification (Interface InStability, IIS) and degree of Inter-Service function Evolution (ISE), and the micro-Service system maintainability assessment is evaluated by ICF measuring the Frequency of entity Co-modification inside the candidate Service, and its specific measurement formula is as follows:
ecf, the specific measurement formula of the frequency of the change of the entities distributed in different services is as follows:
REI measures the ratio of the co-modification frequency of the entities across the service to the co-modification frequency of the entities within the service, and its specific measurement formula is as follows:
9. the multi-source feature space-based micro-Service maintainability assessment according to claim 1, wherein step S204 needs to calculate the interaction complexity of the software model, the interaction complexity describes the complexity of the interaction behavior between services, and step S204 needs to assess the interaction complexity of the micro-Service system based on the multi-source feature space model from five aspects of the Number of services (Inter-Service Length, ISG) processing the user request, the cross-Service call Chain Length (ICL) processing the user request, the Number of Service cycle calls (SCN) processing the user request, the Degree of Dependence on other services (In-Degree Dependence, IDD) and the Degree of Dependence on other services (Out-Degree Dependence, ODD), wherein ISG refers to the Number of different services passing through when processing the user request, the specific measurement formula is as follows:
the measurement mode of the ICL is similar to the ISG, except that the number of different services passed by the ISG when measuring the request and the number of cross-service calls passed by the ICL when measuring the request are as follows:
icli=|S|,S={(oprm,oprn)}
SCN refers to the number of service cycle calls to process a user request, and the measurement formula of SCN is as follows:
SCN=|S|,S={(i,j)|(i,j)≠None∧σprobability(j,i)≠None∧i<j}
IDD measures how much a service is called by other services, the IDD measure being based on DSM of MFSpThe specific metric formula for IDD is as follows:
wherein L represents the number of cells whose cell value in the j-th column is not empty, iddjRepresenting a service SCjThe average probability of being depended on by all other services, and N is the number of the services;
ODD measures the degree to which one service calls other services, and the larger the ODD value, the higher the degree to which the service is coupled with other services, and the serviceHas high dynamic interaction degree, and similar to IDD, the measurement of ODD is based on DSMpThe formula for measuring ODD is as follows:
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110217627.2A CN112925709A (en) | 2021-02-26 | 2021-02-26 | Micro-service maintainability assessment method based on multi-source characteristic space |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110217627.2A CN112925709A (en) | 2021-02-26 | 2021-02-26 | Micro-service maintainability assessment method based on multi-source characteristic space |
Publications (1)
Publication Number | Publication Date |
---|---|
CN112925709A true CN112925709A (en) | 2021-06-08 |
Family
ID=76172250
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202110217627.2A Pending CN112925709A (en) | 2021-02-26 | 2021-02-26 | Micro-service maintainability assessment method based on multi-source characteristic space |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN112925709A (en) |
Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100125474A1 (en) * | 2008-11-19 | 2010-05-20 | Harmon J Scott | Service evaluation assessment tool and methodology |
US20130152044A1 (en) * | 2011-12-07 | 2013-06-13 | Jürgen Salecker | Software Quality Evaluating System And Methods For Determining An Extent Of Software Code Changes |
US20140282406A1 (en) * | 2013-03-14 | 2014-09-18 | Microsoft Corporation | Automatic risk analysis of software |
US20180060066A1 (en) * | 2016-07-12 | 2018-03-01 | Accenture Global Solutions Limited | Application Centric Continuous Integration and Delivery With Automated Service Assurance |
US20180374024A1 (en) * | 2015-12-18 | 2018-12-27 | Drexel University | Identifying and quantifying architectural debt and decoupling level: a metric for architectural maintenance complexity |
US20190158361A1 (en) * | 2017-11-21 | 2019-05-23 | Accenture Global Solutions Limited | Cloud-native network function assessment tool |
CN109961204A (en) * | 2017-12-26 | 2019-07-02 | 中国移动通信集团浙江有限公司 | Quality of service analysis method and system under a kind of micro services framework |
CN111651451A (en) * | 2020-04-25 | 2020-09-11 | 复旦大学 | Scene-driven single system micro-service splitting method |
CN112241350A (en) * | 2019-07-16 | 2021-01-19 | 中国移动通信集团浙江有限公司 | Micro-service evaluation method and device, computing device and micro-service detection system |
US20210028991A1 (en) * | 2019-07-24 | 2021-01-28 | Cisco Technology, Inc. | Ai-driven capacity forecasting and planning for microservices apps |
-
2021
- 2021-02-26 CN CN202110217627.2A patent/CN112925709A/en active Pending
Patent Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100125474A1 (en) * | 2008-11-19 | 2010-05-20 | Harmon J Scott | Service evaluation assessment tool and methodology |
US20130152044A1 (en) * | 2011-12-07 | 2013-06-13 | Jürgen Salecker | Software Quality Evaluating System And Methods For Determining An Extent Of Software Code Changes |
US20140282406A1 (en) * | 2013-03-14 | 2014-09-18 | Microsoft Corporation | Automatic risk analysis of software |
US20180374024A1 (en) * | 2015-12-18 | 2018-12-27 | Drexel University | Identifying and quantifying architectural debt and decoupling level: a metric for architectural maintenance complexity |
US20180060066A1 (en) * | 2016-07-12 | 2018-03-01 | Accenture Global Solutions Limited | Application Centric Continuous Integration and Delivery With Automated Service Assurance |
US20190158361A1 (en) * | 2017-11-21 | 2019-05-23 | Accenture Global Solutions Limited | Cloud-native network function assessment tool |
CN109961204A (en) * | 2017-12-26 | 2019-07-02 | 中国移动通信集团浙江有限公司 | Quality of service analysis method and system under a kind of micro services framework |
CN112241350A (en) * | 2019-07-16 | 2021-01-19 | 中国移动通信集团浙江有限公司 | Micro-service evaluation method and device, computing device and micro-service detection system |
US20210028991A1 (en) * | 2019-07-24 | 2021-01-28 | Cisco Technology, Inc. | Ai-driven capacity forecasting and planning for microservices apps |
CN111651451A (en) * | 2020-04-25 | 2020-09-11 | 复旦大学 | Scene-driven single system micro-service splitting method |
Non-Patent Citations (4)
Title |
---|
晋武侠: "基于多源特征空间的微服务可维护性评估", 《HTTP://WWW.JOS.ORG.CN》 * |
王纪军等: "云环境中Web应用的微服务架构评估", 《计算机系统应用》 * |
王鹏等: "基于源代码的软件可维护性质量度量方法", 《电脑编程技巧与维护》 * |
陈建海等: "基于微服务架构B/S系统的性能分析", 《计算机系统应用》 * |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN111526060B (en) | Method and system for processing service log | |
EP2831767B1 (en) | Method and system for processing data queries | |
CN111737033B (en) | Microservice fault positioning method based on runtime pattern analysis | |
Etesami et al. | Learning minimal latent directed information polytrees | |
CN116911671A (en) | Data asset operation efficiency evaluation method and system | |
CN115168443A (en) | Anomaly detection method and system based on GCN-LSTM and attention mechanism | |
CN115309575A (en) | Micro-service fault diagnosis method, device and equipment based on graph convolution neural network | |
CN117891458A (en) | SQL sentence generation method, device, equipment and storage medium | |
Morichetta et al. | Demystifying deep learning in predictive monitoring for cloud-native SLOs | |
CN112000478B (en) | Method and device for distributing operation resources | |
Choi et al. | The Quantum Tortoise and the Classical Hare: A simple framework for understanding which problems quantum computing will accelerate (and which it will not) | |
Almeida et al. | Requirements traceability in model-driven development: Applying model and transformation conformance | |
CN112925709A (en) | Micro-service maintainability assessment method based on multi-source characteristic space | |
Li et al. | Logspy: System log anomaly detection for distributed systems | |
CN115757053A (en) | Micro-service system architecture evaluation method based on runtime trajectory data | |
Sandhu et al. | Modeling of reusability of object oriented software system | |
Ehrenstein | Scalability benchmarking of kafka streams applications | |
Marvasti et al. | Pattern detection in unstructured data: An experience for a virtualized IT infrastructure | |
Liu et al. | Roots-tracing of communication network alarm: A real-time processing framework | |
CN109976805B (en) | Event-driven architecture mode identification method based on ontology | |
Zakir Khan et al. | An enhanced multifactor multiobjective approach for software modularization | |
Malhotra et al. | Micro Level Source Code Summarization of Optimal Set of Object Oriented Classes. | |
Zhao et al. | A cloud platform architecture recovery metric method | |
CN116821374B (en) | Event prediction method based on information | |
Hussain et al. | Research Article An Enhanced Multifactor Multiobjective Approach for Software Modularization |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
WD01 | Invention patent application deemed withdrawn after publication | ||
WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20210608 |