Introduction: With the development of software system architecture, we have gone from a single application to a distributed system, and gradually move towards cloud native. Among them, the microservice architecture is the most representative, but there are various types of microservice design. For all kinds of problems, I hope this article can help you provide ideas and guidance in the design of microservice architecture.
Foreword & background
Before the story begins, let me tell you a story. In recent years, with the development of software system architecture, we have experienced from a single application to a distributed system, and gradually move towards cloud native. Among them, the microservice architecture is the most representative. , But there are various problems in the design of microservices. For example, the granularity of microservice split is too fine, and the call depth between services is too long. It may be necessary to reorganize the business and consider the service merger. At this time, someone will ask: " Why did you dismantle and recombine microservices? " You told him that we are " Building a Central Station "; then with the rapid expansion of the business, the use of resources can no longer hold, and we must consider dismantling the system. Sometimes someone will ask: " Why did you combine and dismantle the microservices again? " You tell him that we are " dismantling the middle station "; then, of course, after dismantling, it is found that some services are unreasonably dismantled, maybe It is about to merge again. At this time someone asks: " What the hell are you doing? " You can answer him like an old man: "The world is in the general trend. If we divide for a long time, we must unite. If we are together for a long time, we must divide. Qin. After the extinction of Qin, Chu and Han were divided and merged into Han. The emperor of Han ruled the world, and later Guangwu Zhongxing was divided into three middle stations... "
Many people may feel the same in the actual application of microservice design in the above-similar scenarios. How to reasonably split and design microservices? Whether there are relevant standards and norms for reference, the answer is yes, but only the methodology. From a philosophical point of view, there is no universal solution, but some methods can be summarized and abstracted as a guide based on experience, but after excessive abstraction, it is very obscure and difficult to understand, and implementation is not an easy task.
A brief history of microservices development
First of all, let’s review the development process of software system architecture: Monolithic architecture --> Distributed/cluster architecture --> Service-oriented architecture (SOA service-oriented) --> Microservice architecture --> Gridization/Unitization Architecture
In general, the microservice architecture includes all the characteristics of the previous architecture, distributed cluster deployment, service-oriented design, and microservices pay more attention to the granularity of service splitting, that is: how large a service should be split into . However, with the increase in system business volume, the scale of services has become larger and larger, and corresponding new problems have emerged, such as underlying system resource issues, communication and governance issues between services, and overall service operation and maintenance issues. SpringCloud, Microservice frameworks such as Dubbo can only solve problems at the software development level. In the early days of microservices, people focused on the software development level. In recent years, with the maturity and promotion of operation and maintenance technologies such as containerized management technology Docker and container orchestration technology Kubernetes, the microservice system has changed from the original focus on development. Gradually evolved into a DevOps management model integrating design, development, operation and maintenance.
Through the development process of service architecture, we can see that microservices achieve decoupling between services, but they also cause many non-business problems. For example: service discovery, service current limiting, service monitoring, service permission control, service version control, etc. Spring Cloud and other micro-service frameworks, although they provide us with, for example: Eurek, a registry to solve service discovery problems, Hystrix, a circuit breaker to solve current limiting problems, and Ribbon, Fegin, and other technologies to solve service invocation problems, but let’s see if they are How is it used? Import dependency dependencies and package them with our business code for deployment. That is to say, Spring Cloud is an "intrusive" solution. Although it simplifies the difficulty of dealing with non-business problems, developers still need to deal with this part The function must be understood.
We hope that business developers only care about business code development, instead of spending their energy on the development of non-business code. Service Mesh (service mesh) technology is the embodiment of this idea, which can help remove non-business functions from the code. The medium stripping process removes the entire network communication between services and sinks it to the infrastructure level, such as: service discovery, load balancing, version control, blue-green deployment and other issues.
Let's return to the fundamental problem to be solved in microservice design, namely: how to design and split microservices. Here are some principles and methodology commonly used in microservice architecture design:
- AKF split principle
- Business split principle
- Domain Driven Design
- Layered architecture design
AKF split principle
Let’s first talk about the most basic principles of microservice design: AKF Scalability Cube
AKF Scalability Cube is a scalable model proposed in the book "Architecture is the Future". This cube has three axes, and each axis describes the extension. A dimension of sex. In theory, according to these three expansion modes, a single system can be expanded infinitely.
- X axis: refers to horizontal copy. It is easy to understand that it is to run a few more instances of the single system to make a cluster plus load balancing mode. In order to better support this horizontal scalability, the system is best designed to separate the front and back ends and provide stateless services. This kind of expansion capability has the lowest cost and the simplest implementation. It is suitable for the initial stage of development and has low business complexity. Increasing system capacity can solve most problems.
- Y-axis: Refers to the division of responsibilities in the application. This part is what we often call the microservice split mode, which is split based on different businesses. This kind of expansion capability that belongs to business decoupling can make the team more focused and solve the problem of code complexity, but it will inevitably involve the isolation and transmission of the underlying data, so the degree of difficulty is relatively large, which is suitable for complex business and data volume. Large, large-scale team scene.
- Z axis: refers to partitioning based on services or data, such as partitioning by region. This is the most costly expansion method. Generally, very large systems have similar requirements. For example, when an Internet system suddenly increases in user volume and a single cluster model may not be able to carry it, it needs to be served according to the user's region. And data partition. Different from the traditional sub-database table or logically multi-tenant, multiple partitions need to be physically separated, similar to the unitized architecture of the financial industry in recent years, and the idea of multiple data centers. It is suitable for the exponential rapid growth of users, and can be partitioned according to certain rules.
While paying attention to the splitting of the three axes of AKF, we also need to think about the 3S principles, namely: Safety (safety), Scale (scale), Speed (speed)
Business split principle
Next, from the perspective of system business, talk about the splitting and design principles of microservices.
Clarify the separation of microservices and design principles; realize microservices with business needs as the center, high autonomy and continuous evolution as the goal.
For cross-service calls, first consider from a business perspective, achieve high cohesion, low coupling, and minimize the occurrence of such coupling through the principle of splitting.
Domain Driven Design
Domain-Driven Design (DDD: Domain-Driven Design) is a set of more advanced object-oriented modeling methods for software system analysis and design. It is very different from the traditional data-driven design-centric architecture. Domain-driven design pays more attention to the domain model, so what is a domain? To put it bluntly, a field actually refers to a business area . The domain-driven design is to construct the relationship between the business and the business, as well as the internal logic of the business .
In domain-driven design, the first and most important step is to reach a consensus. The team including technicians, domain experts, product managers, etc. can reach a consensus on business knowledge related to the field, so that everyone can be simple, clear and accurate. Describe the business meaning and rules of this field, this is the unified language (Ubiquitous Language) . It is an effective way to solve the business complexity in some medium and large software systems by reaching such a consensus.
After having a common language, how to organize and implement the business model, this part is the Model-Driven Design phase. DDD divides this model design process into two stages:
- Strategic design
- Tactical design
The so-called strategic design, also known as high-level design, refers to the separation of the system into different domains, in other words: which are the core domains (core competitiveness), which are the general domains (non-core shared, externally available), and which It is the support domain (not unique to the core and can be outsourced).
The so-called tactical design refers to how to organize different business models specifically, in other words: what roles (entities, value objects) are these models? What is the relationship between these models (aggregation, aggregation root)? How do these models collaborate and evolve (domain events, domain services, factories, warehouses, application services)?
Then the domain model is divided into boundary contexts, and the dependencies between them are identified to form a domain model design similar to the above figure, and finally the boundary context or the domain model in it is mapped into microservices.
Domain-driven design, a business-oriented design method, has a natural fit with today's agile development and microservice architecture systems.
Layered architecture design
Finally, based on the above design principles and methods, let’s take a look at the layered architecture design. I think everyone is familiar with layered design, but how to layer in the microservice architecture, you can refer to the following middle-stage construction scenarios:
聚合域：聚合中台业务完成业务流程
业务域：提供中台业务能力接口
通用域：提供数据的原子操作接口
The advantage of the layered architecture is that it can make the relationship between services clearer. Try not to call each other at the same level, and avoid cross-level calls. The depth of the entire call chain should also be controlled within a certain range.
Concluding remarks
There is no best design mode and architecture scheme, only continuous optimization and evolution of the system. It is necessary to find the bottleneck of system performance, find the corrupted place in the architecture design, find the feasible method, and then continuously optimize and improve the quality of the system. , The charm of architecture lies here.
"Every line of code you write is your business card, and every bug you fix is counted. This is not a programming technique, this is the art of programming." - Tribute to "Flying Life"