Table of contents
The role of microservice boundaries
Correctly understand the boundaries of microservices
When the focus falls on the boundary, the summary is that the design of microservices involves logical boundaries, physical boundaries, code boundaries, and so on.
So what role do these boundaries play in the evolution of microservice architecture? How should we understand these boundaries? This is what we will focus on today.
evolutionary architecture
In the process of microservice design and implementation, many people think: "How many microservices to split a single body into is the focus of microservice design." But is this really the case? Not so!
When Martin Fowler proposed microservices, he mentioned an important feature of microservices-evolutionary architecture. So what is an evolutionary architecture? The evolutionary architecture is to support incremental, non-destructive changes as the first principle, and at the same time support multi-dimensional changes at the application structure level.
Microservices are not a one-off split, but a gradual evolution. It can support when split or adjustment is required, without hurting the bones, and can be easily realized by recombining. Therefore, the focus of microservice transformation is to sort out the most fundamental aggregation and domain model, rather than the degree of perceptual segmentation. Segmentation can change with changes in requirements, business volume, and implementation architecture, but the underlying aggregation and domain model are stable.
So how to judge whether the microservice design is reasonable? In fact, it is very simple, you just need to see if it satisfies such a situation: With the development of business or the change of requirements, in the process of continuously splitting or combining new microservices, there will be no significant increase in software development and microservices. The cost of maintenance, and the process of evolution of this architecture is very easy and simple.
This is also the focus of microservice design, which is to see whether the microservice design can support the long-term and easy evolution of the architecture.
The microservices designed with the DDD method can not only realize the decoupling inside and outside the microservices through bounded context and aggregation, but also can easily realize the reorganization and update of business function building blocks, so as to realize the evolution of the architecture.
Microservices or Monoliths?
When some project teams split a centralized monolithic application into microservices, the first step is often not to establish a domain model, but to split a software package of the original monolithic application into multiple so-called "microservices" according to business functions. "software package, and the code in these "microservices" is still a centralized three-tier architecture model. The codes in "microservices" are highly coupled, and the logical boundaries are not clear. Here we call it "small single microservice" ".
The picture below also shows this process well.
With the introduction of new requirements and the development of business, these small single microservices will gradually expand. When one day you find that some of the business functions of these expanded microservices need to be split out, or some functions need to be reorganized with other microservices, you will find that these seemingly clear microservices have changed unconsciously. , has become a bloated and greasy large monomer, and the code in this large monomer is still highly coupled and unclear.
"I have worked hard for many years, and I returned to the pre-liberation overnight!" At this time, you need to repeat the process of refactoring from a large monomer to a single microservice over and over again. Think about it, is this price a bit high?
In fact, this problem is already obvious, that is, the boundary .
This monolithic microservice only defines the boundary of one dimension, that is, the physical boundary between microservices, and is essentially a monolithic architecture pattern. When designing microservices, it is not only this boundary that should be considered. Don’t forget to define the logical boundaries and code boundaries in the microservices so that you can get the results you want.
Now you know, we must avoid designing microservices as small monolithic microservices, so how to avoid it? Everyone wants clear boundaries, but how can we ensure them? DDD has already given the answer.
The role of microservice boundaries
You should still remember the bounded context and aggregation in the DDD design method? They are used to define the domain model and microservice boundaries.
Let's review the design process of DDD again.
In the event storm, we sort out user operations, events, and external dependencies in the business process, and sort out domain objects such as entities based on these elements. According to the business correlation between entity objects, multiple entities that are closely related to the business are combined to form an aggregation, and the first layer of boundaries is between the aggregations. According to factors such as business and semantic boundaries, one or more aggregates are defined in a bounded context to form a domain model, and the boundary between bounded contexts is the second layer boundary.
For ease of understanding, we divide these boundaries into: logical boundaries, physical boundaries, and code boundaries .
logical boundary
Logical boundaries mainly define the boundaries between combinations of different clusters composed of closely related objects within the same business domain or application. After the event storm performs association and cluster analysis on different entity objects, multiple aggregates and bounded contexts will be generated, which together form the domain model of this domain. The boundaries between aggregates within a microservice are logical boundaries. Generally speaking, microservices will have more than one aggregation, and the codes of different aggregations are isolated in different aggregation code directories during the development process.
Logical boundaries are of great significance in microservice design and architecture evolution!
The evolution of the microservice architecture is not arbitrary, and it needs to follow certain rules, which are logical boundaries. When the microservice architecture evolves, business capabilities are reorganized in units of aggregation on the business side, and microservice codes are reorganized in units of aggregated code directories on the microservice side. Because the microservice logic boundary designed according to the DDD method is clear, the business is highly cohesive, and the code between aggregations is loosely coupled, so we don’t need to spend too much time and energy when refactoring the domain model and microservice code.
Now let's look at a microservice instance. In the figure below, we can see that the microservice contains two aggregated business logics. The two aggregates respectively integrate different business capabilities, and the codes in the aggregates belong to the under different aggregation directories.
With the rapid development of business, if a certain microservice encounters high-performance challenges and needs to separate part of its business capabilities, we can use aggregation as a unit to split the aggregation code into a new microservice, so that Splitting of microservices can be easily achieved.
In addition, we can also reorganize the functions and codes of aggregations with similar functions in multiple microservices, combine them into new aggregations and microservices, and independently become general-purpose microservices. Now do you feel a little bit like a middle stage?
physical boundaries
Physical boundaries mainly define the boundaries between microservices from the perspective of deployment and operation. Different microservice deployment locations and operating environments are physically isolated from each other and run in different processes. This boundary is the physical boundary between microservices.
code boundaries
Code boundaries are mainly used for isolation between different functional codes within microservices. During the microservice development process, the corresponding code directory will be established according to the code model to realize the isolation of different functional codes. Due to the mapping relationship between the domain model and the code model, the code boundary directly reflects the business boundary. Code boundaries can control the scope of influence of code reorganization and avoid mutual influence between business and services. If microservices need to reorganize their functions, they only need to reorganize in units of aggregated code.
Correctly understand the boundaries of microservices
From the above content, we know that the logical boundaries and code boundaries designed according to DDD make the evolution of microservice architecture less strenuous.
The splitting of microservices can refer to the domain model or aggregation, because aggregation can be split into the smallest unit of microservices. But does the implementation process have to achieve consistency between the logical boundary and the physical boundary? In other words, does aggregation have to be designed as a microservice? The answer is not necessarily. This involves the problem of excessive splitting of microservices.
Excessive splitting of microservices will increase software maintenance costs, such as: integration costs, release costs, operation and maintenance costs, and costs for monitoring and locating problems. In the early stage of project construction, if you do not have strong microservice management capabilities, it is not appropriate to split microservices too finely. When we have certain capabilities, and the internal logic and code boundaries of microservices are also very clear, you can split new microservices at any time according to your needs, and realize the evolution of microservice architecture.
Of course, keep in mind that service calls and data dependencies between aggregates in microservices need to conform to the design principles and development specifications of high cohesion and loose coupling, otherwise you will not be able to complete the evolution of the microservice architecture quickly.
Summarize
Today we mainly discussed the role of various boundaries in microservice architecture design in architecture evolution.
Logical boundaries: The boundaries between aggregates within a microservice are logical boundaries. It is a virtual boundary, emphasizing the cohesion of the business, which can be turned into a physical boundary according to the needs, that is to say, the aggregation can also be independent as a microservice.
Physical Boundary: The boundary between microservices is a physical boundary. It emphasizes the isolation of microservice deployment and operation, and focuses on service invocation, fault tolerance and operation of microservices.
Code boundaries: The boundaries of code directories between different layers or aggregates are code boundaries. It emphasizes the isolation between codes to facilitate code reorganization during architecture evolution.
Through the above boundaries, we can make business capabilities highly cohesive, code loosely coupled, and have clear boundaries. We can quickly realize the splitting and combination of microservice codes, and easily realize the evolution of microservice architecture. But one thing must be paid special attention to. Microservices with clear boundaries are not the evolution from large monomers to small monomers.