CN113961173B

CN113961173B - Domain event driven based monomer system micro-service splitting method

Info

Publication number: CN113961173B
Application number: CN202111190359.6A
Authority: CN
Inventors: 冯志勇; 王子轩
Original assignee: Tianjin University
Current assignee: Tianjin University
Priority date: 2021-10-13
Filing date: 2021-10-13
Publication date: 2024-04-30
Anticipated expiration: 2041-10-13
Also published as: CN113961173A

Abstract

The invention relates to a single system micro-service splitting method based on field event driving, which is technically characterized by comprising the following steps: constructing a domain event model and generating a multi-dimensional interface correlation comprehensive matrix; identifying candidate micro-services from the multi-dimensional interface correlation comprehensive matrix; constructing a micro-service interface call relation chain of each layer according to the candidate micro-service and performing decoupling treatment to obtain a micro-service result; each micro-server result is evolved from a three-tier architecture mode to a domain-driven design hierarchical architecture mode. The invention combines the concept of field driving design, does not depend on specific software components, directly digs needed related information from single application, and describes a single system into a field event diagram model, in the process, the invention focuses on the essence of micro service splitting rather than a specific software technology, so the splitting method is basically not limited by a specific development technology, and can be well applied to most application programs.

Description

Domain event driven based monomer system micro-service splitting method

Technical Field

The invention belongs to the technical field of micro-services, and particularly relates to a single system micro-service splitting method based on field event driving.

Background

Currently, micro-service architecture is the most popular architecture when enterprises create and upgrade applications, and is widely accepted in academia and industry due to its advantages of maintainability, reusability, scalability, availability, and automated deployment, such as google, eBay, amazon, netflix, etc., the internet industry has at a very large head transformed their applications from a single architecture to a micro-service architecture and benefited from many of its advantages.

However, the advent of micro-service architecture has also been accompanied by a number of problems to be solved. The micro-service splitting is one of the most complex tasks in the process from a monomer legacy system to micro-service migration, and a framework designer is required to manually realize the splitting process according to the previous development experience. The key to splitting the microservices is the need to find the appropriate modules, the appropriate size, the appropriate allocation of responsibilities, and the well-designed interfaces, which can lead to an increase in network traffic that can create a system that is unsuitable for its intended tasks due to poor performance and instability.

In the face of the dilemma of micro-service splitting, the idea of domain-driven design (DDD) for many years of falling asleep starts to explode, and the micro-service endows the DDD with new vitality, so that the micro-service meets the own age. When software designers conduct micro-service design, they find that a DDD design method can be used to build a domain model, divide domain boundaries, and then divide micro-service boundaries from a business perspective according to the domain boundaries. Thus, more and more large internet enterprises begin to take DDD as a guiding idea for micro-service splitting design. However, there is no field that can be quantified and no partitioning criteria that bound the context from the present point of view. It relies primarily on the experience of domain experts and the project team is constantly weighted and analyzed during event storms. Improper domain boundary partitioning can be costly, and DDD lacks guided architecture migration theory ideas and ignores the specific floor specifications of the micro-service architecture model.

Disclosure of Invention

The invention aims to overcome the defects of the prior art and provide a monomer system micro-service splitting method based on field event driving, which is reasonable in design, rapid, accurate and wide in application.

The invention solves the technical problems in the prior art by adopting the following technical scheme:

A monomer system micro-service splitting method based on domain event driving comprises the following steps:

step 1, constructing a domain event model and generating a multi-dimensional interface correlation comprehensive matrix;

Step 2, identifying candidate micro-services from the multi-dimensional interface correlation comprehensive matrix;

Step 3, constructing a micro-service interface call relation chain of each layer according to the candidate micro-service and performing decoupling treatment to obtain a micro-service result;

And 4, evolving each micro-service result from a three-layer architecture mode to a domain-driven design hierarchical architecture mode.

Further, the method for constructing the domain event model in the step 1 comprises the following steps:

⑴ Analyzing the logic flow of the service scene, mining potential domain events and corresponding entity objects in the service scene, and defining a domain event model as a 5-tuple comprising the domain events, commands, entity objects, value objects and context ontology;

⑵ The transaction stream arranged according to a certain function stream forms a scene domain, and the scene domain is: s= < TSet, FSet >; wherein TSet is a transaction set, FSet is composed of a set of functional sequences representing the functional flows on the transaction set; the transaction flow is a basic functional unit forming a scene domain and is formed by a request instruction block arranged according to a certain control flow, wherein the transaction flow is T= < TID, function >, the TID is a transaction name, and the Function is a Function of the transaction described by natural language;

⑶ Carrying out dynamic link tracking on an event state conversion process by using an APM tool, analyzing the interface calling details of an application presentation layer in the process, and adding the interface information into a field event model;

⑷ And analyzing and summarizing the constructed domain event model in three dimensions of a request instruction block, a transaction stream and a scene domain, and constructing a domain event model of a multi-dimensional interface calling information version.

Further, the command is represented by the following two-tuple:

the Interface is the system presentation layer Interface calling detail contained in the Command, the presentation layer is positioned at the uppermost layer of the three-layer framework, is in direct contact with a user, and the calling order is the calling order among interfaces.

Further, the upper text body and the lower text body are represented by the following two groups:

Where concept= Request CommandBlock u Transaction Flow u Scenario Field is a domain context Concept set, relation is a set of inter-Concept relationships;

Request CommandBlock is a triggering condition, and the interior of the triggering condition is formed by sequentially arranging and combining a group of interface calls and corresponds to command elements in the domain event model;

the Transaction flow is a Transaction flow and consists of one or more instruction blocks and domain events;

scenario field is a scene field, is formed by sequentially arranging and combining a series of transaction streams, and is a relatively independent sub-field in a closed range;

Relation include domain-context association, transaction-context association, instruction-transaction association, control flow association, instruction-entity association, function flow association, transaction-function association, transaction-name association.

Further, the method for generating the multi-dimensional interface correlation comprehensive matrix comprises the following steps: taking a domain event model as input, defining the correlation degree among the request instruction block, the transaction stream and the scene domain from three dimensions for two presentation layer interfaces I _a,I_b:

⑴ Define Com (I _i) as the set of request instruction blocks that invoke presentation layer interface I _i, the correlation of the two interfaces of I _a,I_b in the request instruction block dimension is denoted as C _Com(I_a,I_b), equal to the total number of request instruction block types that invoke both interfaces of I _a,I_b simultaneously:

C_Com(I_a,I_b)＝card(Com(I_a)∩Com(I_b))

⑵ Defining Tra (I _i) as the transaction flow set that invokes presentation layer interface I _i, the correlation of the two interfaces of I _a,I_b in the transaction flow dimension is denoted as C _Tra(I_a,I_b), equal to the total number of transaction flow types that invoke both interfaces of I _a,I_b simultaneously:

C_Tra(I_a,I_b)＝card(Tra(I_a)∩Tra(I_b))

⑶ Defining Sce (I _i) as a set of fields that invoke presentation layer interface I _i, the relevance of the two interfaces of I _a,I_b in the field dimension is denoted as C _Sce(I_a,I_b), equal to the total number of field types that invoke both interfaces of I _a,I_b simultaneously:

C_Sce(I_a,I_b)＝card(Sce(I_a)∩Sce(I_b))

⑷ The interface correlation in three dimensions is weighted and accumulated according to the following formula to obtain the comprehensive correlation C _Total(I_a,I_b of the interface I _a,I_b):

C_Total(I_a,I_b)＝α₁·C_Com(I_a,I_b)+α₂·C_Tra(I_a,I_b)+α₃·C_Sce(I_a,I_b).

Further, the specific implementation method of the step2 is as follows:

Firstly, carrying out matrix vectorization conversion on a multi-dimensional interface correlation comprehensive matrix, mapping the converted set of high-dimensional vectors to a series of points in an n-dimensional space, carrying out clustering processing based on the distances of the points, and obtaining a proper clustering result through a plurality of iterations;

And then, dividing the system presentation layer interface into a plurality of clusters with different sizes according to a clustering result, wherein each cluster corresponds to one micro service, and sequentially designing a corresponding business logic layer and data access layer interface and independent databases of each service from top to bottom to finish domain event-driven micro service-oriented splitting.

Further, the specific implementation method of the step 3 is as follows:

Firstly, describing three-layer interface call chains of all presentation layer interfaces of an original system, and finding out all Controller interfaces- & gt Service interfaces- & gt DAO interface call chains of each presentation layer interface; combining the best clustering result of the presentation layer interfaces, aggregating the Controller interfaces in the same cluster into one micro Service, separating the Controller interfaces which are not in the same cluster, and respectively grouping the Service interfaces and the DAO interfaces into the micro Service where the corresponding upstream interfaces are located to obtain a preliminary micro Service result;

And carrying out decoupling treatment on interface call among services in the primary micro-service results to obtain each micro-service result which shows the characteristics of loose coupling among services and high cohesion in the services.

Further, the specific implementation method of the step 4 is as follows:

Firstly, separating a storage interface of an original data access layer from storage realization, uniformly placing a third party tool kit, a driver, a common public tool and configuration files which are common to the original three-layer architecture in a base layer, dividing the storage interface into field layers, and decoupling business logic and database resource logic by relying on an inversion principle;

secondly, the original business logic layer interface is divided into two parts, on one hand, a persistent object in the data access layer is converted into a corresponding entity object, a service interface related to the assembly and arrangement of the original business logic layer and an entity or entity method is classified into a domain layer to be converted into a domain service interface, and a plurality of entity objects and domain services which are dependent closely form aggregation to bear the basic core business logic of the system; on the other hand, the interfaces for combining and arranging the domain services in the original business logic layer are extracted into the application layer, so that the interfaces realize coarse-grained business behaviors according to the front-end requirements;

and finally, converting all view objects originally positioned in the business logic layer into data transmission objects, and forming a user interface layer together with an original presentation layer interface, wherein the user interface layer is used for data assembly and transmission between a front-end application and a micro-service or between the front-end application and the micro-service and serves as a carrier for data transmission.

The invention has the advantages and positive effects that:

1. The invention combines the concept of Domain Driven Design (DDD), does not depend on specific software components, directly excavates needed related information from single application, and describes a single system into a domain event diagram model, in the process, the invention focuses on the essence of micro service splitting rather than a specific software technology, so the splitting method is basically not limited by a specific development technology, and can be well applied to most application programs.

2. The invention adopts a semi-automatic splitting mechanism to consider important splitting factors such as micro-service splitting granularity and the like, perfects the splitting mechanism from multiple aspects, and designs an algorithm supporting two-stage automation in the splitting method: (1) Abstracting the multi-dimensional interface call information version of the DED into a multi-dimensional interface correlation comprehensive matrix; (2) Identifying candidate micro-services from the multi-dimensional interface correlation comprehensive matrix, and considering important micro-service advantage characteristics such as coupling, cohesion and the like in an evaluation link; the resolution result with the cohesive coupling characteristic related index shows that the method can effectively provide a reasonable and high-quality micro-service candidate scheme.

Drawings

FIG. 1 is a process flow diagram of the present invention;

FIG. 2 is a schematic diagram of a domain event model (DED) of the present invention;

FIG. 3 is a diagram of a multi-dimensional interface correlation comprehensive matrix algorithm constructed according to the present invention;

FIG. 4 is a diagram of a micro-service algorithm constructed in accordance with the present invention;

FIG. 5 is a schematic diagram of a preliminary micro-attendant according to the present invention;

FIG. 6 is a schematic diagram of a micro inter-service decoupling process according to the present invention;

FIG. 7 is a schematic diagram of a micro-service architecture mode evolution process according to the present invention;

FIG. 8 is a micro-service splitting result evaluation index according to the present invention;

FIG. 9 is a graph showing SSE trend with K value;

fig. 10 is a diagram of core business usage of an embodiment (intelligent care service platform) of the present invention;

fig. 11 is a ten-large coarse-grained scenario area of an embodiment of the invention (intelligent endowment service platform);

FIG. 12 is a DED diagram corresponding to an embodiment of the invention (Intelligent endowment service platform);

fig. 13 is a schematic diagram of clustering results under the weka tool in an embodiment of the invention (intelligent endowment service platform);

fig. 14 shows the results of micro-servitization splitting in an embodiment of the invention (intelligent care service platform).

Detailed Description

Embodiments of the present invention are described in further detail below with reference to the accompanying drawings.

A method for splitting a monomer system micro-service based on domain event driving is shown in fig. 1, and comprises the following steps:

and 1, constructing a domain event model (DED) and generating a multi-dimensional interface correlation comprehensive matrix.

In the step, firstly, the logic flow of the business scene is analyzed according to the product landscape and the natural language description of the user. The main purpose of the product landscape is to design the top layer value of the product, so that information such as target users, core value, differential competition points and the like of the product are agreed, and the deviation direction of the product is avoided. Listening to the user's natural language description makes us stand in the user's perspective to generalize and summarize the behavior of different types of system users, making the process of building DEDs next more natural.

By analyzing the logic flow of the service scene, potential domain events and corresponding entity objects in the service scene are mined, and modeling work of DEDs is carried out by combining the service logic flow based on the potential domain events and the corresponding entity objects. The specific method comprises the following steps:

FIG. 2 is a schematic diagram of DED, which we define as a 5-tuple < Domain Event, command, entityObject, value Object, context Ontology >, the meaning of each parameter is described below.

(1) Domain Event: domain events are a very important part of the domain model to represent events occurring in the domain, one domain event possibly leading to further business operations. For example, the domain event may be a step of a business process, such as triggering an action of applying a policy to change a policy after the payment of the insurance application is completed; events occurring in the process of timing batch processing, such as batch processing generation of a season payment premium notification bill, and triggering of a payment mail notification operation; or a subsequent action triggered after an event occurs, such as the password being continuously input for three times, triggering the action of locking the account.

(2) Command (Command): commands refer to business operations that handle changes in the state of system data. In the view, a command is generally described as a form having a verb or verb phrase. Command may be expressed as the following doublet:

The Interface is the system expression layer Interface calling detail contained in the Command, the expression layer is positioned at the uppermost layer of the three-layer framework and is in direct contact with a user, the main function is to realize the input and output of system data, the data can be transmitted to the system for data processing without the aid of logic judgment operation in the process, and the application system can feed back the processing result to the expression layer again. In other words, the presentation layer is to implement the user interface function to communicate and feed back the user's needs. Dynamic link tracking is carried out on the domain event state transition process, and the interface calling condition of the corresponding related command to the presentation layer in the process can be analyzed. The Application Performance Management (APM) tool is used for capturing and recording the interface information of the presentation layers called by the inter-event commands one by one, and the interface information corresponding to the commands is added into the Command to perfect the DED. The calling order of interfaces under the same command is that the interfaces are called from left to right in turn, namely serial call, and the interfaces in the same column indicate that the interfaces are called by the left adjacent interfaces, namely parallel call, at the same time. It is worth noting that it is convenient for a domain expert or architect to identify different granularity of micro-services through a domain model with a corresponding degree of interface detail. However, this does not mean that the more detailed the interface call information is exposed. Micro-services with too fine a granularity may negatively impact the performance of the overall system due to communication overhead between micro-services. In order to clearly describe our method without introducing too much complexity in a limited space, we only analyze and build DED models on the presentation layer, putting focus on the business functions related to interface adaptation, and temporarily not concerning the complicated layer-to-layer interface call situation.

(3) Entity Object: there are a class of objects in the prototype view that possess unique identifiers and that remain consistent after undergoing various state changes. For these objects, not their properties, but their continuations and identifications, which can span or even extend beyond the lifecycle of the software, are important. We refer to such objects as entities.

(4) Value Object: an object identified by an object attribute value that combines a plurality of related attributes into a conceptual ensemble. A value object describes an item in the domain that is immutable and that combines different related attributes into a conceptual whole. When the metrics and descriptions change, another value object may be substituted. It can be compared with other value objects for equality without causing side effects to the collaboration object. The domain event may contain both a value object and an entity, and the value object and the entity may be interchanged in some scenarios, and in these scenarios, it is very difficult for many domain modeling experts to actually determine whether to design the domain object into the entity or the value object. It can be said that the value object has good value in some scenes, but not all scenes fit the value object, and we need to select the most suitable method for the specific practical situation.

(5) Context Ontology (upper and lower text volume): the context body describes the concept set of the application domain context and the relation between them and gives the details of the division of the business functions. The context ontology may be represented as the following binary group:

Wherein:

Concept= Request CommandBlock. U. Transaction Flow. U. Scenario Field is a set of domain context concepts. Relation is a collection of inter-concept relationships, and the primary concepts and primary associations in the context ontology are shown in tables 1 and 2, respectively.

TABLE 1 concept of context ontology

Table 2 association of context ontology

The context domain is composed of transaction streams arranged in a certain functional stream, and according to the above concepts and associations, the context domain is described as s= < TSet, FSet >. TSet is a transaction set, FSet made up of a set of functional sequences, representing the flow of functions on the transaction set. The transaction flow is a basic functional unit constituting a scenario domain, and is composed of request instruction blocks arranged according to a certain control flow, and according to the above concept and association, the transaction flow is described as t= < TID, function >. Where TID is the name of the transaction and Function is the Function of the transaction described in natural language.

On the basis of building the DED, an Application Performance Management (APM) tool is used for carrying out dynamic link tracking on an event state conversion process in the DED, application presentation layer interface calling details in the process are analyzed, and interface information is added into the DED, so that the building work of the DED is perfected. In order to realize more effective micro-service splitting, the constructed DEDs are further analyzed and summarized in three dimensions of a request instruction block, a transaction stream and a scene domain, and finally the DEDs of a multi-dimensional interface calling information version are constructed. The multidimensional interface call information version of the DED further decomposes, analyzes and generalizes the DED in different dimensions, inherits all interface call core information of the DED, and removes redundant information such as entities, value objects and the like.

Finally, using DED as input, automatically constructing a multi-dimensional interface correlation comprehensive matrix by constructing a multi-dimensional interface correlation comprehensive matrix algorithm (algorithm 1) as shown in fig. 3. The algorithm extracts all interface sets (presentation layers) participating in the business process from the constructed DEDs, and further calculates the association degree between the interfaces under different dimensions. The algorithm is described below:

For the two presentation layer interfaces I _a,I_b, the correlation between them is defined below from the three dimensions of the request instruction block, the transaction stream, and the context domain.

(1) Define Com (I _i) as the set of request instruction blocks that invoke presentation layer interface I _i, the correlation of the two interfaces of I _a,I_b in the request instruction block dimension is denoted as C _Com(I_a,I_b), equal to the total number of request instruction block types that invoke both interfaces of I _a,I_b simultaneously:

C_Com(I_a,I_b)＝card(Com(I_a)∩Com(I_b)) (1)

(2) Defining Tra (I _i) as the transaction flow set that invokes presentation layer interface I _i, the correlation of the two interfaces of I _a,I_b in the transaction flow dimension is denoted as C _Tra(I_a,I_b), equal to the total number of transaction flow types that invoke both interfaces of I _a,I_b simultaneously:

C_Tra(I_a,I_b)＝card(Tra(I_a)∩Tra(I_b)) (2)

(3) Defining Sce (I _i) as a set of fields that invoke presentation layer interface I _i, the relevance of the two interfaces of I _a,I_b in the field dimension is denoted as C _Sce(I_a,I_b), equal to the total number of field types that invoke both interfaces of I _a,I_b simultaneously:

C_Sce(I_a,I_b)＝card(Sce(I_a)∩Sce(I_b)) (3)

The interface correlation in three dimensions is weighted and accumulated according to the following formula to obtain the comprehensive correlation C _Total(I_a,I_b of the interface I _a,I_b):

C_Total(I_a,I_b)＝α₁·C_Com(I_a,I_b)+α₂·C_Tra(I_a,I_b)+α₃·C_Sce(I_a,I_b) (4)

And 2, identifying candidate micro-services from the multi-dimensional interface correlation comprehensive matrix.

In this step, firstly, the interface correlation comprehensive matrix generated in the algorithm 1 is subjected to vectorization conversion by using a construction micro-service algorithm (algorithm 2) shown in fig. 4, the set of high-dimensional vectors obtained by conversion are mapped into n-dimensional space (n is equal to the vector dimension), the set of vectors are mapped into a series of points in the n-dimensional space, clustering processing is performed based on the distances of the points (here, k-means clustering based on the distances) is performed, and a proper clustering result is finally obtained through a plurality of iterations. The algorithm 2 can be well in seamless connection with the DED constructed before, and can autonomously perform corresponding micro-service splitting operation to generate theoretically reasonable micro-service candidates.

And then dividing the system presentation layer interface into a plurality of clusters with different sizes according to a final clustering result, wherein one cluster corresponds to one micro service, improving each micro service, and sequentially designing a corresponding business logic layer and data access layer interface and independent databases of each service from top to bottom. The separation of the modules is ultimately completed, depicting a domain event driven micro-service oriented split, with each module representing a potential micro-service that the software architect needs to consider.

And step 3, constructing a call relation chain of interfaces of each layer of the micro-service and performing decoupling treatment to obtain a micro-service result.

In the step, aiming at obtaining ideal clustering results, in order to ensure the service consistency in the micro-service architecture design process, the calling details of interfaces of each layer of the micro-service architecture are described by combining the best clustering results of the interfaces of the presentation layer, so as to obtain a preliminary micro-service result. As shown in fig. 5, the whole characterization process is as follows:

The three-layer interface call chains of all the presentation layer interfaces (the Controller interfaces in the corresponding diagrams) of the original system are described, namely, the situation that interface confusion occurs is avoided by finding out the call chains of all the Controller interfaces, service interfaces and DAO interfaces of each presentation layer interface, and paying attention to distinguishing the Service interfaces and the upstream interfaces (the Service interfaces need to distinguish the Controller interfaces which are mainly relied on and the DAO interfaces need to distinguish the Service interfaces which are mainly relied on). After the calling relation chain of each layer of interfaces of the original monomer system is described, the Controller interfaces in the same cluster are gathered into one micro Service by combining the best clustering result of the presentation layer interfaces, the Controller interfaces which are not in the same cluster are separated, and the Service interfaces and the DAO interfaces are respectively classified into the micro Service where the corresponding upstream interfaces are located.

However, there may be a tighter coupling degree between the interface calls in the primary microservice result, and the problem of such interface call coupling mainly exists in that the presentation layer interface of one microservice calls the business logic layer interface of another microservice, and the procedure of calling the business logic layer interface by the presentation layer interface in the layered architecture is essentially the call of a specific method in the business logic layer interface. If there is such a situation in the microservice process as occurs in fig. 6: defining one or a plurality of methods of a certain Service interface in another micro Service (micro Service 1) called by a certain or a certain Controller interface in one micro Service (micro Service 2), wherein the methods form a set A, defining one or a plurality of methods of the same Service interface in the micro Service 1 called by a certain or a certain Controller interface, and forming a set B, if the intersection of the set A and the set B is an empty set, the Service interface can be subjected to method-level decomposition operation, so that the methods in the set A and the set B are respectively packaged into two mutually independent Service interfaces, and then the two mutually independent Service interfaces are put into the corresponding micro Service to become new Service interfaces in the respective micro Service to replace the old Service interfaces, thereby achieving the aim of eliminating the problem of tight coupling of interface calling between the micro services.

By performing the decoupling operation on the inter-service interface call, the problem of tight coupling of the inter-service interface call is solved, and the micro-service result is characterized by loose coupling among services and high cohesion in the services. Fig. 6 demonstrates the entire decoupling process.

And 4, evolving each micro-service result from a three-layer architecture mode to a DDD layered architecture mode.

The micro-service architecture processed in the previous step is still in a traditional three-layer architecture mode, and in contrast, the core design idea of the DDD hierarchical architecture is to separate and decouple core service logic and technical implementation details, which is the perfect implementation of the design principle of high cohesion and low coupling of the micro-service architecture. The DDD layered architecture and the microservice design emphasize that from the service, the core is to reasonably divide the domain boundary according to the service development, continuously adjust the existing architecture and optimize the existing code so as to maintain the vitality of the architecture and the code. Therefore, the implementation of micro-service design using DDD hierarchical architecture is a good choice.

All elements in the micro-service result are reclassified, the range of the layers is reclassified, and interaction rules and responsibility boundaries between the layers are determined, so that the evolution of each micro-service from the three-layer architecture mode to the DDD layered architecture mode needs to be gradually completed, as shown in fig. 7. The specific evolution process is as follows:

Firstly, a warehouse interface of an original data access layer is separated from a warehouse implementation, common public resources such as a third party tool kit, a driver, a common public tool, a configuration file and the like which are common to an original three-layer architecture are uniformly placed in a base layer, the warehouse interface is divided into a field layer, and decoupling of business logic and database resource logic is realized by relying on an inversion principle. Secondly, the original business logic layer interface is divided into two parts, on one hand, the persistent object in the data access layer is converted into a corresponding entity object, the service interface related to the assembly and arrangement of the original business logic layer and the entity or entity method is classified into the domain layer to be converted into a domain service interface, and a plurality of entity objects and domain services which are closely relied on form aggregation to bear the basic core business logic of the system. On the other hand, the interfaces for combining and arranging the domain services in the original business logic layer are extracted into the application layer, so that the interfaces realize coarse-grained business behaviors according to the front-end requirements. And finally, converting all view objects originally positioned in the business logic layer into data transmission objects, and forming a user interface layer together with an original presentation layer interface, wherein the user interface layer is used for data assembly and transmission between a front-end application and a micro-service or between the front-end application and the micro-service and serves as a carrier for data transmission.

After the processing, the micro-server result in the traditional hierarchical architecture mode obtained in the last step is evolved into the micro-server result in the DDD hierarchical architecture mode. The domain services in the DDD hierarchical architecture mode are called by application services, the application services are called by a user interface layer, and the services are packaged or combined layer by layer, so that the dependency relationship inside the architecture is clear. In general, the evolution from the three-layer architecture mode to the DDD hierarchical architecture mode enables the internal structure of the micro-service architecture to be clearer, the problem that the core service logic of the hierarchical architecture is disordered and the code change is greatly influenced mutually is solved, in addition, the upgrading, maintenance and deployment of the system are easier, and the design and implementation scheme of the domain driving mechanism for micro-service splitting are finally completed.

In order to evaluate the index of the micro service splitting result in the present invention, the present invention adopts the Sum of Squares Error (SSE), error clustering rate (Icr), common link rate (Plr) and modularity (M) to measure the appropriate index in terms of high cohesive and loose coupling, as shown in fig. 8, and the following detailed description of these four indexes is given below:

intra-cluster error Sum of Squares (SSE)

Considering the split granularity of the micro-service, the invention observes the clustering effect under different clustering clusters by adjusting the clustering cluster number parameter k in the algorithm 2 (shown in figure 4), thereby determining the reasonable clustering number. Here, the present invention uses the sum of squares of errors (Sum ofsquared errors within clusters, SSE) within a cluster as a measure of the clustering effect, which is defined as follows:

Where d is the Euclidean distance between two vectors in n-dimensional space, k is the number of clusters, x is any vector in the cluster, ci is the center vector corresponding to the centroid of the ith cluster, and Si represents the set of vectors contained in the ith cluster.

As shown in fig. 9, as the number k of clusters increases gradually, the SSE value becomes smaller gradually until the value k reaches the maximum value (i.e., the cluster point corresponding to any vector is the cluster center itself where it is located), and the SSE value takes the minimum value 0. During the SSE change, an inflection point appears, and the SSE value drop rate suddenly slows down at this time, so that the k value corresponding to the SSE value is considered as the optimal split granularity of the micro-service.

Error rate (Icr)

After the reasonable candidate micro-service granularity is determined, the rationality allocated by the request instruction block, the transaction flow and the scene domain three-dimensional weight value a _1,2,3 is evaluated as key points for generating a satisfactory micro-service performance layer interface clustering result. The invention takes the clustering result as a basis for evaluating the clustering result, and introduces error clustering rate (Icr) as a measure of the rationality of the distribution of different dimension weight values. And quantitatively evaluating the similarity of the clustering result and the manual splitting result by calculating the proportion of the number of service interfaces which do not accord with the manual splitting opinion to the total number of interfaces of the project. In particular, when icr=0, it means that the resolution result obtained using the resolution method proposed by the present invention is completely identical to the manual version.

Common link rate (Public linkrate, plr)

The invention not only adopts the intra-cluster error Sum of Squares (SSE) and error cluster rate (Icr) to measure the internal cohesive property of the micro-service, but also adds indexes such as common link rate (Public linkrate, plr), modularity (Modularity, M) and the like to measure the coupling property between services. From the perspective of a single micro service, the present invention introduces the common link rate as a measure of the degree of coupling between clusters of micro services. The invention calculates the proportion of the common interface call links and the total links of each micro service by analyzing and counting the number of the call links of the internal interfaces of each micro service and the number of the common links between the micro services in the micro service splitting result. In particular, when Plr =1, it means that the business logic in the cluster is completely independent of other external clusters, i.e. that there is truly "no coupling" between the micro-service and other micro-services.

Modularity (Modularity, M)

From the perspective of the whole micro-service architecture, the invention uses the modularity concept proposed by NEWMAN AND GIRVAN as a standard for measuring the micro-service division quality, so as to measure the quality of the micro-service splitting result. Definition of modularity referring to fig. 8, the present invention formally adapts this definition to the evaluation of the micro-service splitting results, as follows:

Let an interface call link network be divided into k clusters, defining a matrix e of k x k. e _ij denotes the ratio of the number of links connecting cluster i and cluster j to the total number of links. In particular, e _ii represents the ratio of the number of links between the cluster i and the cluster i to the total number of links, that is, the ratio of the number of links in the community i to the total number of links. Thus, trace tr (e) = Σ _ie_ii of matrix e, i.e. the sum of the diagonal elements of the matrix, represents the proportion of links inside the cluster. The larger this value, the more tightly the association within the community. However, this has the disadvantage that if the whole graph is divided into 1 community, this value is the maximum value of 1. The present invention thus defines a _i＝∑_je_ij, which represents the ratio of the number of links connected into cluster i to the total number of links. After obtaining the values e _ii and a _i, the corresponding module degree M is calculated according to the following formula:

the value range of the modularity is [ -0.5, 1), if the quality of the micro service splitting is consistent with the effect of the random splitting, M=0 will be obtained. When the value of M approaches the maximum value of 1, it is shown that the split clusters have only very weak coupling.

The following describes a specific process of splitting a single application platform using the present invention, taking a real enterprise-wide project as an example:

The application platform is a comprehensive intelligent endowment platform which aims at providing personalized endowment services for old users, the core concept of the platform is based on Internet plus, medical, insurance, life care, intelligent wearing and other multi-aspect endowment requirements are technically achieved, the endowment service ecological mechanism of combining and linking home-community-living with the old is formed by integrating various fragmented endowment services on the middle line and off line of the society, and finally management service software and hardware combination solutions of home, community, living endowment and the like are provided for the old through a meshing deployment endowment service center, so that omnibearing, personalized and full-coverage endowment service under different requirement scenes such as home-community-living and the like is provided for the old. The intelligent endowment platform is a real enterprise-level large project, and is a good choice for the effectiveness and rationality of splitting the display method which is closer to reality.

(1) Business scenario analysis

The splitting method provided by the invention firstly analyzes service scenes and then constructs DEDs according to the logic flows of the service scenes. Scene analysis determines the participants in the system and the operations they may perform. Fig. 10 depicts the core business of the intelligent endowment service platform summarized after an industry interview with domain experts, including the following 6 roles:

a system administrator: the super administrator account of the system has the highest authority and can operate all modules by default.

Platform service personnel: service personnel of the platform side can operate all service modules with authority removal settings.

A merchant: the service provider of the hosting platform has the highest authority of commodity management and can operate all business modules of the merchant.

Service mechanism: the organization of the hosting platform has the highest authority of service management and can operate all service modules of the service organization.

The user: the platform service object has no background operation authority.

Financial specialists: platform financial accounting personnel, operable financial module.

In combination with natural language description of platform related business handling processes by various types of users, the use cases in fig. 10 are expanded and perfected, and finally ten coarse-grained scene fields of fig. 11 are summarized and corresponding description information is given so as to facilitate further construction of subsequent DED.

(2) Constructing DED and abstracting it into multi-dimensional interface correlation comprehensive matrix

According to the analysis of the service scene introduced in the previous step, the service scene in fig. 11 is converted into the DED, and then according to the logic analysis of the service scene, the corresponding command operation is added into the DED, so as to complete the detailed description of the DED. The intelligent endowment service platform DED is shown in fig. 12, which shows a business logic detail depiction of 10 business scenarios matched with fig. 11. By importing the intelligent endowment service platform DED data set as input into an algorithm 1 shown in fig. 3 for corresponding operation processing, the algorithm 1 respectively identifies and calculates all interface details and correlations among the DEDs in three dimensions of a request instruction block, a transaction flow and a scene domain, and finally generates a multi-dimensional interface correlation comprehensive matrix.

(3) Identifying candidate micro-services from multi-dimensional interface relevance synthesis matrix

After the multidimensional interface correlation comprehensive matrix generated by DED is obtained, the matrix is automatically subjected to vectorization conversion by an algorithm 2 in FIG. 4, and classical clustering processing is performed on the group of high-dimensional vectors obtained by conversion to obtain a reasonable clustering result. These clustering results indicate potential micro-service candidates that can be independently developed. Fig. 13 shows the clustering result of the intelligent endowment service platform performance layer interface after the execution of algorithm 2 under the weka tool. The algorithm 2 automatically splits the multidimensional interface correlation comprehensive matrix of the intelligent endowment service platform into 8 micro service candidates, which are comprehensive searching, platform residence, service, page recommendation, users, reusability general service, commodity and login.

(4) Domain driven mechanism implementation scheme for micro service splitting

After candidate micro-services of the intelligent endowment service platform are identified, firstly, each micro-service is perfected, corresponding business logic layer and data access layer interfaces are sequentially designed from top to bottom, and a preliminary micro-service result of the intelligent endowment service platform is generated. And then, performing decoupling operation called by the inter-service interface to obtain a micro-servitization result with high cohesion in the inter-service loose coupling service. Finally, the evolution of each micro-service of the intelligent endowment service platform from the layered architecture mode to the DDD layered architecture mode is completed, and the implementation scheme of the domain driving mechanism for micro-service splitting is shown in fig. 14. Each rectangle in the figure represents a microservice, and a total of 8 types of microservices split from the intelligent endowment service platform are shown: comprehensive searching, platform residence, business service, page recommendation, user, reusability general business, commodity and login. The inside of the rectangle depicts the interface call details inside the service and the interaction relationship between the services.

It should be emphasized that the examples described herein are illustrative rather than limiting, and therefore the invention includes, but is not limited to, the examples described in the detailed description, as other embodiments derived from the technical solutions of the invention by a person skilled in the art are equally within the scope of the invention.

Claims

1. A single system micro-service splitting method based on domain event driving is characterized in that: the method comprises the following steps:

Step 4, each micro-service result is evolved from a three-layer architecture mode to a domain-driven design hierarchical architecture mode;

The method for generating the multi-dimensional interface correlation comprehensive matrix comprises the following steps: taking a domain event model as input, for two presentation layer interfaces I _a,I_b, from the correlation between three dimension definitions of a request instruction block, a transaction stream and a scenario domain:

C_Com(I_a,I_b)＝card(Com(I_a)∩Com(I_b))

C_Tra(I_a,I_b)＝card(Tra(I_a)∩Tra(I_b))

C_Sce(I_a,I_b)＝card(Sce(I_a)∩Sce(I_b))

2. The domain event driven based monolithic system microservice splitting method of claim 1 wherein: the method for constructing the domain event model in the step 1 comprises the following steps:

3. The domain event driven based monolithic system microservice splitting method of claim 2 wherein: the command is represented by the following two tuples:

4. The domain event driven based monolithic system microservice splitting method of claim 2 wherein: the upper text body and the lower text body are represented by the following binary groups:

Where concept= Request Command Block u Transaction Flow u Scenario Field is a domain context Concept set, relation is a set of inter-Concept relationships;

Request Command Block is a triggering condition, and the interior of the triggering condition is formed by sequentially arranging and combining a group of interface calls and corresponds to command elements in the domain event model;

5. The domain event driven based monolithic system microservice splitting method of claim 1 wherein: the specific implementation method of the step 2 is as follows:

6. The domain event driven based monolithic system microservice splitting method of claim 1 wherein: the specific implementation method of the step 3 is as follows:

7. The domain event driven based monolithic system microservice splitting method of claim 1 wherein: the specific implementation method of the step 4 is as follows: