The microservice architectural style is an approach to developing a
single application as a suite of small services, each running in its
own process and communicating with lightweight mechanisms, often an
HTTP resource API.

These services are built around business capabilities and
independently deployable by fully automated deployment machinery.

There is a bare minimum of centralized management of these services ,
which may be written in different programming languages ​​and use
different data storage technologies.

The above is the definition of microservice architecture from James Lewis and Martin Fowler. In summary, there are the following points:

1. The entire application system is composed of several independently running services
2. There is a lightweight communication mechanism between services, usually REST API
3. Each service has its own business logic and can be deployed separately
4. Decentralized service management mechanism
5. Each service can use different Programming language implementation, using different data storage technologies

In the entire microservice architecture, the protagonist is naturally an independent deployment and independent operation of services, and if there is a lack of management of these services Mechanism, just like this society is suddenly no longer bound by moral laws, and the entire microservice architecture is no longer a system.

The microservice architecture I understand is roughly like this:

As can be seen from this picture, in addition to the core micro In addition to the service, an API gateway (Gateway) and a registration discovery center (Registry) are also added. But this picture is not perfect, it can only be regarded as showing some core mechanisms.

The author has not thought of what kind of posture can be used to show the various mechanisms of the microservices more completely on a picture, it is better to spend some pen and ink to describe it!

1. Speaking of Gateway

We can regard Gateway as the Entry Point of the entire system, which is of very important strategic significance, as can be seen from the position in the figure above. Let us consider a question first:

Q: Why do we need Gateway? Can this part be discarded?

A: From the perspective of service users, the absence of Gateway means that you need to understand the interfaces exposed by each service. This is undoubtedly a complicated and meaningless task; from the perspective of service managers Consider that without Gateway, whether it is daily development work or future maintenance and expansion work, it will be a severe test.

So the conclusion is obvious, Gateway is indispensable to the entire microservice architecture system.

In fact, our deployment strategy is usually to deploy multiple instances of a service. Then the client sends a request, which instance should Gateway route to?

It’s time for Load Balance to play.

So, if it is the above deployment strategy, it is usually necessary to add a layer of Load Balance between Gateway and Services, and finally route to one of the service instances through a certain forwarding strategy.

Let’s make a bold assumption: What if there are multiple Gateways?

Usually this kind of consideration is because the number of services behind it is so large that one Gateway cannot carry such a large amount of traffic, so it is considered to add a few more helpers. Each Gateway routes a part of the service, and finally it can be formed. A Gateway cluster.

At this time, the complexity of the entire architecture has risen to another level, and new problems have arisen. For this group of Gateways, they must be effectively managed.

The simple solution is to add a Load Balance in front of this group of Gateways, which looks like this:

But there are multiple Loads in front What about Balance?

……

This question is endless.

It can only depend on the actual situation, which reminds me of a sentence:

There are a lot of fun at the Gateway level Things, such as monitoring, current limiting and so on.

Gateway’s implementation methods are also diverse, such as NodeJs, Zuul, Nginx, and so on.

2. How to communicate

As mentioned at the beginning of the article, communication between microservices is usually in the form of REST API. Here is a brief explanation of REST.

REST API is not that mysterious. REST is built on HTTP requests, so REST requests are essentially HTTP requests.

REST is a resource-oriented architecture, and each operation of the API can be regarded as the state transfer of resources.

There are three important concepts:

• Resource: resource, that is, data. For example, goods, orders, etc.;
• Representational: A certain representation of resources, such as JSON, XML, JPEG, etc.;
• State Transfer: State transfer, realized through HTTP verbs.

When your technical team decides to use the REST architecture, there are two details to consider:

• Which HTTP verb should you choose? Especially the choice of PATCH and PUT should be considered clearly.
• Resource naming convention. The standard of REST is that names are all nouns, and they are plural.

Since it is based on the HTTP protocol, we have to consider the problem that a request fails due to various reasons.

Usually, we will introduce a retry mechanism into the system. The strategies for requesting retries are also different. For example, the maximum number of retries is 3 times, and the retries are 3 times within 5 seconds. If there are multiple instances, you can also set the maximum number of retries allowed on each instance. So, even if the number of retries are used up, the request still cannot be reached, what should I do?

Let’s try to feel:

Service-1 was forced to go offline for some reason. If there is no support from other replica sets, then all chains routed to Service-1 The road will be interrupted. If this situation cannot be improved as soon as possible, all application resources (threads, queues, etc.) may be exhausted within a few seconds, the entire request link will be dragged down, and the entire system may even be paralyzed.

This is the classic Cascading Failure.

At this time, you need to install a switch on the link to each service, just like an air switch in your home. Once an emergency occurs, the link will be automatically disconnected without affecting Other links ensure the normal operation of the entire system.

This is the so-called circuit breaker. This mechanism is not unique to the IT industry, and it is also well-known in the financial industry. These concepts are derived from life, extracting the laws of human survival one after another.

There is also a concept similar to fusing: downgrade.

In the field of microservices, “service fuse” and “service degradation” do cause some confusion for beginners.

Actually, it is not difficult to understand if you carefully examine it.

Both are for system stability and security considerations, and will be triggered only when certain conditions are met. The difference is that the triggering method and scene are different.

Service fuse is generally triggered automatically by the system according to preset conditions, such as 10 consecutive request failures. In order to avoid further losses, the system directly takes the corresponding service offline. At this time, the switch is equivalent to being in the Closed state, and when the service is back online and the heartbeat connection is established, the switch state is converted to the Open state.

The trigger of service degradation can be manual intervention or automatically triggered by the system. At this time, there are hierarchical divisions between services. The availability of some downgraded services is reduced. When users use them, sometimes they may not get the expected results.

There is also a certain relationship between the two, which can be summed up as follows:

Due to long-term service degradation, permanent service fusing .

If it is not very clear, you can see the fourth reference I attached.

3. Let’s talk about Registry again

In a highly autonomous microservice architecture, the role of Registry and Discovery Center is very important.

The role of the Registry is like a catalog of a book, and the corresponding content can be found through the catalog. Registry loads the metadata of microservices. When a service tries to call another service, it will go to the Registry to request a piece of metadata to find out where the called service is.

In this way, every service can be regarded as a Registry Client, and Gateway is no exception.

Registry is so important, I usually want it to be highly available, so at least one more copy will be deployed for it, and each Registry holds a complete service metadata.

The decentralized service management mechanism mentioned at the beginning of the article shall not be mentioned again here.

In the SOA architecture system, the ESB is the center of the entire system. If the ESB is paralyzed, it means that the entire system is unusable.

A major difference between microservices and SOA is de-ESB, which means decentralization. This means that when the Registry is all offline, all services can still operate normally. Among them, one of the main tasks is that each Registry Client caches a copy of the metadata information of the service for emergencies.

There is a well-known CAP theorem in the field of distributed systems:

• C——Data Consistency
• A——Service Availability (Available)
• P——Partition tolerance of the service to network partition failures (Partition tolerance)

These three characteristics cannot be satisfied at the same time in any distributed system. At most two can be satisfied at the same time. Architects should not waste energy on how to design a perfect distributed system that satisfies the three, but should make a choice.

In the SOA architecture system, ESB prioritizes consistency. Taking zookeeper as an example, when zookeeper is used to obtain the service list, if zookeeper is selecting the master, or more than half of the machines in the zookeeper cluster are unavailable, Then the data will not be available, so zookeeper cannot guarantee service availability, and it satisfies the two conditions of CP.

But for the service discovery scenario, if the data does not meet the requirements of consistency, it will not cause any catastrophic consequences. We should pay more attention to the availability of services. From this perspective, AP is better than CP. This is why Spring Cloud Netflix abides by AP principles when designing Eureka.

4. Talking about link tracking

This is the last part of this article, and it can also be regarded as an “advanced topic” in the field of microservices.

In the author’s opinion, the tracking of the call chain can be regarded as a means of operation and maintenance, and it is not that simple to do this part of the work.

In the past, in a single application environment, all businesses were on the same server. If the server has errors or exceptions, we only need to focus on one point to quickly locate and deal with the problem.

The microservice architecture has determined that the system completes a series of business activities in a distributed environment. At this time, tracking and locating problems will become more troublesome.

Link tracking tools are common in some medium and large systems, because the efficiency of human flesh troubleshooting is too low.

Even if it is not a troubleshooting problem, if PM wants to track the business flow, it will gradually become impossible.

This is a picture that makes people feel uncomfortable when viewed:

This picture describes the call of each service node The relationship is scary, right?

For the realization of link tracking tools, the famous ones are Twitter Zipkin and Google Dapper. As for the introduction of tools, it is not within the scope of this article, and the author will start a new chapter.

Summary

This article introduces the definition of microservice architecture style and four technical concepts related to microservice governance. In fact, it is also a manifestation of the current DevOps concept.

I hope it helps you.

THANKS!

Attachment:

References:

1. Service-oriented and microservice architecture

p>

2. Microservice architecture design-Peter Liu

3. Talk about my understanding of service fusing and service degradation

4. Vernacular: Service degradation and fusing Differences

5. Spring Cloud technical analysis (1)-service governance

6. Microservices as I know

Daily sharing of dry goods, delivering valuable information from the Internet world, all in the “Technology Exchange”.