I’m not a typical science guy. Click on the blue word above to follow. After following you can harvest the most hardcore knowledge sharing, the most interesting stories on the Internet

Welcome to the atypical science man

Recommend Lao Wang’s article on micro services.

Through this article you can learn about the change from monolithic architecture to microservice architecture, ServiceMesh, API gateway, and BFF concepts.

Follow the wechat official account and reply to “micro services” for more articles about micro services

This is Lao Wang’s original text

Microservices have been a topic for a long time, and there are many examples that can be found on InfoQ or ThoughtWorks. Unfortunately, a large percentage of these cases fail because, apart from technical barriers, many people are out of touch and microservices for the sake of microservices. This article uses an example to take you through the evolution of microservices from start to finish, not only to know how, but also to know why.

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 a project, a single architecture is often a good fit for rapid iteration. However, as the project progresses, the project itself becomes more complex and its disadvantages inevitably occur, such as the following examples:

  • Because everyone is working on the same repository, you might run into a situation where the Mall module has completed a new feature and is ready to go live, only to have to delay the launch because the recommendation module has just submitted code that hasn’t been tested yet.
  • Different technology stacks are used for different requirements: the guy in charge of the comments module wants to build the system with PHP + MySQL, the guy in charge of the user module wants to build the system with Golang + PostgreSQL.
  • Some modules need high performance CPU, and some modules need large memory. Because different modules are coupled together, our server has to have both high performance CPU and large memory, which increases the cost.

How to solve such problems? Conway’s Law gives a good suggestion: “The architecture of the design system is subject to the communication structure of the organization that produces the design.” In a popular way, “the architecture of the system will be designed according to the organizational structure.” In this case, because different teams are responsible for different modules, it is natural to split the system into separate services such as mall, recommendations, comments, users, etc. : each service has its own version library and database, and services communicate with each other through RPC. Different services have their own version libraries and can be independently developed and deployed using their own technology stacks and hardware.

One problem that needs attention is how to determine the size of service granularity. Although the size of service can be determined according to the size of organizational structure according to Conway’s Law, 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, the local function calls between modules became remote RPC calls between services, and we had to deal with issues like service governance. As the number of microservices increased, the problem became more and more difficult. Fortunately, with the development of cloud native, In particular, with the maturity of technologies such as K8S and ISTIO, our architecture can evolve to the Service Mesh stage, transparently implementing service governance through Sidecar.

If function calls that are local between modules are replaced by RPC calls that are remote between services, our microservices are likely to become “distributed singleton”. The crux of the problem lies in the excessive use of RPC, which leads to strong coupling between services. The solution is to introduce events to decouple services from services through events.

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

  • Use RPC (emphasis on what to do) : When the user module creates a new user, the mall module is called through RPC to give the user a coupon. The user module and the mall module are strongly coupled in the process.
  • Using Event (to emphasize what happened) : When the user module creates a new user, it sends out a UserCreated Event. After observing the corresponding Event, the mall module gives the user a coupon. During the process, the user module and the mall module are weakly coupled.

In practice, RPC or Event should be selected according to requirements: if it is the implementation part of business logic, RPC is preferred. If it is a follow-up notification after the business logic is complete, it is strongly recommended to use 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, the API Gateway can be added to act as a proxy, and the front end only needs to ask the API Gateway once to get the data.

With the API Gateway in place, it can help with logic like aggregation. One problem is that there may be many different types of front-end, such as PC front-end and Mobile front-end, and their business logic will inevitably have various differences. If these differences are handled in the API Gateway, it will taste bad. To solve these problems, Backend For Frontend (BFF) is introduced. Each front-end has its own BFF to process its own service logic. The API Gateway processes only common service logic, such as authentication and logging.

Microservices is a very complex concept, and this article will only give a brief introduction to some superficial issues. Other complex issues, such as SAGA, are not covered due to space constraints. If you are interested, please refer to them by yourself.

Martin Fowler’s first law of Distributed Objects in PoEAA: Don’t distribute your objects! Using this statement, it is not difficult to extend the first law of microservices: do not use microservices! It’s a bit of a joke, but at least it warns us to be in awe when it comes to micro-services.

In depth Understanding the Java Virtual Machine JVM Advanced features and Best Practices (latest Second edition) Reply [ebook] get "Meituan 2019 Technical Collection" reply [Redis] get redis exclusive information reply [wechat group] or [add Group] free join the architect technical exchange group WISH all fans: good health, everything is successfulCopy the code

What is architectural design? Architecture Design This article is enough

Why is Redis so fast?

Blockbuster: The latest JVM ecology report for 2020

BIO, NIO, AIO summary

How much do you know about the new features of JDK8?

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

Welcome to the atypical science man