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

Why do we need a microservice architecture? This is also the focus of our discussion. There are a lot of people who talk about "microservices" every day, but I don't think there are many people who really think deeply about "why."

So as I combed through the material, I decided to start with the source-the "why."

Architecture evolves, not overnight.

The trend analysis in the "Architecture Evolution Trend Chart" is well recognized in the industry. The content of this diagram itself, the description of each architecture, advantages and disadvantages, etc., a simple search on the Internet has a lot of, interested students can search for themselves, after all, this is not the focus of our article.

Different periods and stages of software development have different demands on the understanding, selection and application of technology. Architecture selection, always only "appropriate and inappropriate", never "which is better". We talk about microservices today, not because they are better, but because, after careful analysis, the idea of microservices is more in line with our goals.

What is "microservices architecture"?

Since we are talking about "why," we must first understand "what is."

"An explanation will understand, a question will not know, a discussion will fight", this is a sentence I saw on the Internet before, laughed for a long time, too appropriate, moved over.

When it comes to microservices, there is no way to mention this "great god"-Martin Fowler. He did not directly give a precise definition of microservices, but gave a description of the characteristics of microservices, probably from the following four aspects:

1. Classification of service types according to business modules

2. Each service can be deployed independently and isolated from each other

3. Calling services via lightweight APIs

4. Services need to guarantee good high availability

How do you understand that? Here is my interpretation:

The first point is to split the service according to the business, which is "horizontal split"; at the technical level,"front and back separation" belongs to "vertical split"; horizontal and vertical cut together, a single application is split into mesh small pieces of application, which is the embodiment of the "micro" idea in microservices.

Second, independent deployment and isolation from each other fully reflect the design concept of "I am for everyone, everyone is for me", which is the embodiment of the "service" idea in microservices.

Third, regarding lightweight APIs, microservices themselves recommend the use of lightweight communication protocols and simple data structures. In fact, http+json is usually used in the implementation process. The advantage of this is that services no longer need to care about each other's models, only through pre-agreed interfaces to carry out data flow. This is the embodiment of the "decoupling" idea in microservices.

The last point, which is more common, is something that must be considered in all kinds of design nowadays.

So I gave a definition of microservices (see picture).

In practice, we have encountered a variety of problems, some technical problems, some business problems, and some management problems. Here is one of the cases.

This kind of thing was neither big nor small. One of the most troublesome things is the occurrence of "prevarication." Each independent organization has its own assessment indicators and concerns, and it is impossible to divide the boundaries of a specific task very clearly in actual conditions. For example, interface definition, even if it says "both sides sit down and discuss the decision together," one party will eventually be responsible for the matter, and prevarication is inevitable.

One of the guiding ideas of microservices is about organizational adjustment. There is also a special law called "Conway's Law". Interested parties can search and understand it themselves.

And our solution worked. Before the organization has not completely re-planned according to the concept of micro-services, such tasks that need to be completed collaboratively across organizations directly set up temporary project teams: relevant departments send out personnel and resources, designate/select a project manager who can hold to be responsible for the whole thing, and then everyone is surprised to find: The problem of "department wall" disappeared, because everything was done within the group, and the overall completion was linked to the performance of all project team members, so things went very smoothly. After successful delivery, the project team disbanded and went home. It greatly improves communication efficiency and delivery speed, and at the same time greatly improves resource utilization rate.

In fact, many times, everyone's ideas and ideas to solve problems do not have to be micro-services to do so, but "coincide," micro-services exist in our daily work bit by bit.

Someone asked: I want to do micro-services, any suggestions?

Yes. Through our continuous exploration and summary, to do a good job in micro-services, we must do a certain amount of preparatory work and talk about it from four specific aspects:

Business split-reflected in the design phase: at design time, there should be enough judgment to reasonably plan the boundaries between services.

Service governance-support for underlying technologies: First, choose a distributed service infrastructure that suits your actual situation, and make corresponding technical preparations for service discovery, governance, fusing, and degradation.

Automated testing: It must be automated. An obvious representation of microservices is that with the increase of services, if you continue to use the traditional test mode, you will encounter bottlenecks. In order to ensure efficient iteration, try to automate more links.

Automatic O & M: After microservices are split, each service can be deployed independently, which means it can be upgraded anytime and anywhere. Especially when the Internet has developed to this day, business needs to maintain an efficient response to market changes, and automated operation and maintenance is an important link to improve delivery speed.

Finally, it must be mentioned that "monitoring": including hardware environment, service status, system health, interface invocation, real-time alarm of abnormalities, and advance warning of potential problems. How important is monitoring in implementing microservices? Bottom line: don't microservice unless you're ready for surveillance.

Finally, microservices are not silver bullets, there is no silver bullet in the software field, microservices with its unique advantages in solving some problems at the same time, but also introduced other problems, these points must be deeply considered.

"Think twice before you act."

------

I am a small micro, focusing on micro-service technology sharing, committed to mining more "high, fine, comprehensive" micro-service knowledge to share with you.

My WeChat: weiblack (Remarks: 51CTO)

WeChat official account: black and small micro service,"sharing technology, loving life," welcome to pay attention

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.