Microservice architecture design pattern and CAP theorem
Preface
Hello everyone, I am a programmer who develops Java back-end. Since the National Day holiday has come, I plan to spend this week on improving my skills. Microservices were studied in the last year of college, but they were used less after work. In order to prevent the company's business from using microservices in the future, I won't be confused and have to learn it temporarily, so this National Day plans to make a summary of microservices. The plan is to spend five days. First of all, I want to declare that I am a rookie. If the summary is not good or very bad, welcome to point out that we all study together. Hehe~
What is the use of microservices?
In the early Internet development, many projects, including now, are monolithic applications. Generally, this single application is composed of three parts: client user interface, module and database. Generally, there will be many modules, and finally they are packaged and deployed on the server. In the early stage of the project, this method will be easier to develop and deploy. But in the later stage, the trouble can be big, because the project functions will be expanded as the user needs increase. The previous small applications will become more and more complex. Once a bug appears, it will affect the whole body, so the update and change of each service in a single application will cause the entire application to be redeployed, and the flexibility is too low... and distributed is the solution to this problem.
As the name suggests, microservices are actually splitting a huge application into a set of small and interconnected services.
SOA architecture
The SOA architecture is service-oriented, and is further divided vertically based on a single architecture according to business functions. Each service contains its own business logic and multiple adapters. Split the modules and use interfaces to communicate with each other. Just like we are engaged in the separation of front and back ends in development, the back end uses Responsebody to send Json to the front end, and the front end gets the data according to the back end interface. In this way, when developing, no one has to wait for who to do it first, just take care of their duties. SOA architecture usually exists in the process of the operating system in an independent form, and each service communicates through the network. In the case of microservices, it is actually to split the SOA again. The microservice architecture is more thorough than the SOA architecture.
Common design patterns of microservice architecture
Aggregator microservice design pattern
This design pattern uses aggregators to mobilize multiple services through load balancing, each of which has its own cache server and database. The interfaces of all services will be exposed, and finally all the retrieved data will be processed and displayed by the aggregator, and the data can also be added with business logic to form new microservices. This is the most common and simple design pattern.
Agent microservice design pattern
This design pattern is basically the same as the picture just now. I don’t bother to draw it again. The aggregator is replaced by a proxy. This mode is mainly evolved from the aggregator mode just now. This model does not aggregate data on the client side, but mobilizes different microservices according to the difference in business requirements. The agent can delegate the request, and can also perform data conversion work. Each microservice is its own independent cache and database system.
Chain microservice design pattern
When service A receives the message, it will communicate with B, and then B will communicate with C. Because it is chained, the synchronous transmission of messages between services is blocked during the period of time when the client does not receive a response after the client sends a request, until the entire chain is completed and the response is sent to the client. So when we are in the chain service design mode, don't let its service chain be too long, otherwise the client will wait for a long time.
Branch microservice design pattern
This design pattern is more like a combination of the aggregate microservice design pattern and the chain microservice design pattern. We can call two service chains at the same time. When the client sends a request to call service A, A needs to call service B while at the same time calling service C, and service C needs to call service D. Therefore, a branch microservice model is formed.
Asynchronous messaging microservice design pattern
Here, when service A requests service C, service C needs to request service B again. At this time, synchronization will cause blocking, so some microservice architectures will use message queues to request responses. Here, C is a producer, and B is a consumer. The message queue is the message produced by the persistent service C. The queue will help cache the message until the consumer service starts working
CAP theorem
The CAP theorem actually means that in a distributed system, Consistency, Availability and Partition Tolerance cannot be taken into account in actual development.
Consistency
This actually means that the operation returns to the client successfully after the user has updated the data, and then all nodes will maintain the same data at the same time, which is distributed consistency.
Availability
This availability means that the service is always available. Once the user's request is received, the server must respond, and it is the normal response time. The main purpose of maintaining usability is to give customers a better experience. There will be no operation failures, access links that cannot be accessed for half a day, and access timeouts.
Partition Tolerance (partition fault tolerance)
In fact, partition fault tolerance means that after a single server or multiple servers have problems, other normal servers can still provide services normally. In a distributed system, if some nodes or network partitions fail, it can still continue to provide services that satisfy consistency and availability. There are multiple sub-networks in most distributed systems, and then each sub-network can be called a zone.
Trade-off strategy
Because the three characteristics of CPA in a distributed system can only satisfy two of them at the same time, there will be three choices: CA, CP, AP.
If I choose the CA strategy, I hope to make the system meet the consistency and availability at the same time, but also give up the partition fault tolerance. In this way, it is no longer possible to deploy sub-nodes, and abandoning the scalability of the system obviously violates the original intention of the distributed system.
So, should I choose CP? Then I hope that the system can satisfy both consistency and partition fault tolerance. All update operations must wait for synchronization to be completed before responding to return results. In the event of network failures or other events, sacrificing availability will affect customer experience.
Finally, there is the AP strategy. This strategy is to hope that the system can meet the partition fault tolerance and availability. But the data of each node can only provide services for local applications, leading to global inconsistency.