Shulou(Shulou.com)06/03 Report--

This article mainly introduces "what are the principles of micro-service design". In daily operation, I believe many people have doubts about the principles of micro-service design. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful for you to answer the doubts about "what are the principles of micro-service design?" Next, please follow the editor to study!

Good micro-service design can make later upgrade and maintenance easier, otherwise it will be a great headache.

The following design principles are strongly recommended:

Single responsibility

High cohesion

Low coupling

Hide the internal implementation

Avoid code base sharing

Avoid excessive exposure of data

Avoid database sharing

Minimize synchronous calls

Minimize hardware sharing

Avoid using platform-specific technologies

These three principles are the core of object-oriented design and are also applicable to micro-service design.

1. Single responsibility

Each microservice should have only one responsibility.

For example, a microservice has two major functions:

Classified management of commodities

Shopping Cart

Putting them together doesn't seem like a big problem, because the technologies used are the same, the functions and data are closely linked, and organizationally, the same development team is usually responsible for it.

However, this results in a lot of code coupling between the two functions.

After a long time, it will bring the same problems as a single architecture, difficult to maintain, difficult to test, difficult to deploy.

Therefore, according to the principle of "single responsibility", it should be divided into two micro-services.

two。 High cohesion

Closely related behaviors should be put together.

For example, there are two microservices:

Order management

Order amount statistics

The order amount Statistics service needs to request the order Management service to obtain the required data.

Such as price, tax, service charge.

At first everything was fine, but suddenly one day there was an increase in taxes and new rules of calculation needed to be changed.

In that case, the order service needs to provide new data, and the amount statistics service also needs to change the calculation method.

In other words, each change basically requires two services to change together, which is tightly coupled.

Because the logic of the order amount statistics service is only related to the order, it should be incorporated into the order service.

Put closely related behaviors together to achieve high cohesion.

3. Low coupling

Changes to one service do not affect other services.

This principle involves many aspects.

3.1 hide the internal implementation

For example, in the previous section "High cohesion", the amount statistics service was incorporated into the order management service, so does the "statistics interface" in the previous amount statistics service still need to be exposed?

Now it is the internal function of the order service, and the statistical results can be used as the data in the order object, so there is no need for external exposure to prevent misoperation and unnecessary coupling.

3.2 avoid sharing a code base

Sharing code is really convenient, but it can cause the underlying code to be too relevant.

It is very inconvenient for future upgrades, for example, a service wants to upgrade the language version, but the shared library uses a lower version, and some of its usage is out of date in the higher version, which is embarrassing.

Want to avoid perfectly is also unrealistic, can only be avoided as far as possible.

For example, without sharing, services recreate wheels so that there is a boundary between services.

However, this approach is only applicable to libraries that need to be shared. It is very stable and does not need to be changed, otherwise the related services need to be changed.

Another example is to reduce the granularity of the shared library to avoid the formation of a full-featured library.

A large library will inevitably lead to a wide range of citations and great influence.

If the granularity is very small, there are fewer services involved.

3.3 avoid over-exposure of data

For example, the user service has an interface to get the user's details and return all the user's information.

When the shopping cart service obtains user information, it will get very complete data, such as payment information.

This is not necessary, just return the basic properties of the user.

Special properties should be provided through another interface.

Excessive exposure will increase the coupling between services.

3.4 avoid database sharing

When a service wants to get data from another service, it should only take it through the interface, not directly from the other party's database.

Otherwise, this data-level coupling can lead to nightmares.

3.5 minimize synchronous calls

For example, the order service needs to call many other services when creating an order, such as users, goods, payment, inventory, logistics.

Do you call the interfaces of each service synchronously?

Unrealistically, if one of the service interface calls fails, then the creation of the order fails.

It is best to use event-driven asynchronous calls.

Synchronous invocation will cause network blocking, which requires extremely high availability of the called service, so it should be used with caution.

3.6 avoid sharing of hardware infrastructure

The service is well designed, but it is also very painful if the hardware deployment is not planned.

For example, if two services are deployed on one server and service B consumes a lot of resources, then service A may not be available.

Therefore, the key point of hardware can not be ignored, and balanced deployment should be done according to the characteristics of each service.

3.7 avoid using platform feature technology

For example, Java RMI is good for remote calls, but it is a platform feature that requires both sides of the service to use a set of technologies. This kind of high coupling is not as free as platform-independent REST.

At this point, the study of "what are the principles of micro-service design" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.