【SpringCloud】03. Design principles of microservices

Design principles of microservices:

1、 AKF split principle

The industry has a simple concept for scalable system architecture design: capacity and availability problems can be solved by adding machines (if one fails, two).

1. Y axis (function)

Y-axis expansion will split the huge overall application into multiple services. Each service implements a set of related functions, such as order management, customer management, etc. A common solution in engineering is service-oriented architecture (SOA). For example, for an e-commerce platform, we can split it into different services to form the following architecture:

However, by observing the above figure, it is easy to find that when the number of services increases, the service invocation relationship becomes complex. Adding a new function to the system makes the number of services to be called uncontrollable, which leads to confusion in service management. Therefore, in general, it is necessary to use the mechanism of service registration to form a service gateway for service governance. The architecture of the system will become as shown in the following figure:

2. X axis (horizontal expansion)

X-axis expansion is consistent with our previous simple concept, which solves the problems of capacity and availability by absolutely replicating services and data equally. In fact, it is to run multiple instances of microservices in the mode of cluster and load balancing. In order to improve the availability and capacity of a single service, each service is divided by axis expansion.

3. Z axis (data partition)

Z-axis expansion usually refers to system division based on the unique needs of requesters or users, and makes the divided subsystems isolated from each other but complete. Take the automobile factory as an example: in order to develop its business in China or use China's cheap labor, Ford has established a complete subsidiary factory in China, which is responsible for the complete automobile production like the American factory. This is a Z-axis extension.

There are two common z-axis expansion schemes in the engineering field:

2、 Front and rear end separation principle

What is front and rear end separation? Aren't the front and rear ends separated? This starts with the awkward JSP. Fine division of labor has always been the principle of making the cake bigger. It is best for engineers in multiple fields to cooperate without contacting knowledge in other fields, so as to make efficiency higher and higher and maintenance simpler. JSP template technology integrates HTML and Java code, making the front and back ends of traditional MVC development like glue here. The front end makes pages, the back end turns into templates, finds problems, and then finds the front end. The front end can't understand java code The purpose of front and rear end separation is to break this embarrassing situation.

The front-end and back-end separation principle is simply the code separation between the front-end and the back-end. The recommended mode is to deploy in the way of physical separation to further promote more complete separation. If you continue to directly use the server-side template technology, such as JSP, and pile Java, JS, HTML and CSS into one page, a slightly more complex page cannot be maintained.

This separation has several advantages:

3、 Stateless service

For stateless services, let's first talk about what is state: if a data needs to be shared by multiple services to complete a transaction, then this data is called state. Furthermore, services that depend on this "state" data are called stateful services, and vice versa.

This stateless service principle does not mean that statefulness is not allowed in the microservice architecture. The real meaning of the expression is to change the stateful business service into a stateless computing service, and the state data will be migrated to the corresponding "stateful data service".

Scenario Description: for example, the data cache and session cache previously established in local memory should be migrated to the distributed cache for storage in the current microservice architecture, so as to turn the business service into a stateless computing node. After migration, it can scale dynamically on demand. Microservice applications dynamically add and delete nodes at runtime, so it is no longer necessary to consider how to synchronize cache data.

4、 Restful's communication style

As a principle, it should have been a "stateless communication principle". Here we directly recommend a preferred restful communication style because it has many advantages: