I’m an atypical science man. Click on the top of the blue word attention. After following you can harvest the most hardcore knowledge sharing, the most interesting Internet story

Recommend an article by Lao Wang about micro services.

In this article you will learn about the evolution from monolithic architecture to micro-service architecture, ServiceMesh, API gateway and BFF concepts.

Follow the WeChat official account and reply to the micro service for more articles on micro service

The following is Lao Wang’s original text

While microservices have been a topic for a long time, many examples can be found on InfoQ or ThoughtWorks. Unfortunately, a significant percentage of these cases are failures, due to the fact that, in addition to the technical barriers, many people are out of touch with the real world and just microservices for the sake of microservices. This article takes you through the evolution of microservices from start to finish with an example, not only to know how, but also to know why.

<span id=”more-904″></span>

Suppose that we are developing an online shopping, its main functions include mall, recommendations, comments, user, etc., it is a typical monomer architecture: different team of technical personnel working on the same repository, according to system function module partition, through local function calls between different modules, usually the same database operation.

In the early stages of the project, the monolithic architecture is often well suited to the need for rapid iteration, but as the project grows, the project itself becomes more complex, and its drawbacks inevitably occur, such as the following:

  • Because we are all working on the same version library, we may encounter: the mall module has completed the new function and is ready to go online, but the recommendation module just submitted the code that hasn’t been tested yet, so the launch has to be delayed.
  • Different requirements have different technology stacks: the colleague responsible for the comment module wants to build the system in PHP + MySQL, while the colleague responsible for the user module wants to build the system in Golang + PostgreSQL.
  • Some modules need high performance CPU, some modules need large memory, because different modules are coupled together, so our server has to have both high performance CPU, large memory, thus increasing the cost.

How to solve such problems? Conway’s Law gives good advice: “The architecture of the design of systems is constrained by the communication structure of the organization in which these designs are produced.” In more general terms, “The architecture of the system is designed as the organizational architecture is designed.” In this case, because different teams are responsible for different modules, it is natural to use modules to split the system into separate services such as stores, recommendations, reviews, and users: each service has its own independent repository and database, and the services communicate with each other via RPC. Different services have their own repositories and can be independently developed and deployed using their own technology stacks and hardware.

One problem that needs to be paid attention to is how to determine the size of service granularity. Although according to Conway’s law, it is enough to determine the size of service according to the size of the organizational structure, how to plan a reasonable team size? Actually does not have a precise answer, we need according to the objective conditions to determine a suitable for their own modest service granularity, the particle size is too small will lead to strong coupling between services, big granularity is deviated from the original intention of the service, Uber according to service granularity size problem even invented the concept of a macro service, interested readers may wish to look at.

When we split the monolithic architecture into separate services, local function calls between modules became remote RPC calls between services, and we had to deal with issues like service governance, which became more and more difficult as the number of microservices increased. Fortunately, with the development of cloud native, Especially with the maturity of technologies such as K8S and Istio, our architecture can evolve to the Service Mesh phase and implement service governance transparently through Sidecar.

If we simply replace local function calls between modules with remote RPC calls between services, our microservices are likely to become “distributed singleton”. The crux of the problem lies in the over-use of RPC, which leads to strong coupling between services. The solution is to introduce Event to realize decoupling between services.

See how to implement the following business logic: When a user signs up, give the user a coupon in the store.

  • Using RPC: When the user module creates a new user, it calls the mall module through RPC to give the user a coupon. In the process, the user module and the mall module are strongly coupled.
  • Use an Event (to emphasize what happened) : When the user module creates a new user, it sends out a UserCreated Event, and the store module observes the Event and gives the user a coupon. The user and the store module are weakly coupled.

In practice, RPC or Event should be chosen according to requirements: if it is part of the implementation of business logic, RPC is preferred; If it is a part of the subsequent notification after the completion of the business logic, it is strongly recommended that you choose Event.

After service deployment is ready, then we also need to consider how to expose the service for the front-end calls, such as users browse a product details page, include data, and the corresponding recommended data and comments, if direct operation service, you will need to repeatedly query goods and services, recommendation service, reviews, is not recommended, At this point, you can join the API Gateway as a proxy, and the front end only needs to request the API Gateway once to get the data.

Once we have the API Gateway, it can help us with logic like aggregation. One problem is that there may be many different types of front ends, such as PC front ends and Mobile front ends, and their business logic will inevitably have various differences. If these differences are handled in the API Gateway, it will cause bad taste. To solve this problem, We introduce BFF (Backend For Frontend). Each Frontend has its own BFF to handle its own business logic, while the API Gateway only handles common business logic such as authentication and logging.

Microservice is an extremely complex concept, and this article only deals with some superficial issues. Due to space constraints, other complex issues such as Saga have not been covered. If you are interested, please refer to them yourself.

Finally, I give you Martin Fowler’s first law of distributed objects in POEAA: Don’t distribute your objects! Using this phrase, it’s not hard to derive the First Law of Microservices: Don’t use microservices! There’s a bit of masochism in this, but at least it warns us to be in awe when it comes to microservices.

Get an in-depth understanding of the Java Virtual Machine: Advanced features and best practices for the JVM (the latest second edition) Reply [ebook] Get the "Meituan 2019 Technical Collection" Reply [Redis] Get the exclusive information of Redis Reply [WeChat Group] or [Plus Group] Join the architect technical exchange group for free Wish all the fans: good health and everything goes well





<center>

What is architectural design? This article is enough for architecture design

Why is Redis so fast?

Blockbuster: Explore the latest JVM ecology report for 2020

BIO, NIO, AIO summary

What do you know about the new JDK8 features?

Reply to “information” and get an exclusive technical information for free!

Welcome to Atypical Male Science