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

Spring Cloud is undoubtedly the current leader in microservices architecture, and countless books and blogs have been written about this technology.

However, most explanations still stay at the level of using Spring Cloud functions, and many of its underlying principles may not be known to many people.

In fact, Spring Cloud is a family bucket-style technology stack that contains many components. This article starts with the core components, namely Eureka, Ribbon, Feign, Hystrix, Zuul, to analyze the underlying working principle.

Business Scenario Introduction

Let's first tell you a business scenario. Suppose we are now developing an e-commerce website to realize the function of paying orders.

The process is as follows:

After creating an order, if the user immediately pays for the order, we need to update the order status to "paid."

Deduct the corresponding commodity inventory.

Inform warehouse center to deliver goods.

Add points to the user's purchase.

For the above process, we need order service, inventory service, warehousing service, points service.

The general idea of the whole process is as follows:

After paying for an order, the user goes to order service to update the order status.

Order service calls inventory service to complete corresponding functions.

Order service calls warehousing service to complete corresponding functions.

Order service calls points service to complete corresponding functions.

At this point, the entire payment order business process ends. The following diagram clearly shows the invocation process between services:

Good! With the business scenario, let's take a look at how these components work together in the Spring Cloud microservices architecture, their respective roles, and the principles behind them.

Spring Cloud Core Component: Eureka

Let's consider the first question: How does an order service want to invoke inventory services, warehousing services, or points services?

The order service doesn't know which machine the inventory service is on! Even if it wanted to send a request, it didn't know who to send it to.

Then it was Spring Cloud Eureka's turn. Eureka is a registry in the microservices architecture that specializes in service registration and discovery.

Let's take a look at the following diagram and analyze the whole process in detail:

As shown in the figure above, there is an Eureka Client component in the inventory service, warehousing service and points service, which is responsible for registering the information of this service into the Eureka Server.

To put it bluntly, it tells Eureka Server which machine it is on and which port it is listening on.

Eureka Server is a registry that stores the machines and port numbers on which services are located.

There is also an Eureka Client component in the order service. This Eureka Client component will ask the Eureka Server: Which machine is the inventory service on? Which port are you listening to? What about storage services? What about points service?

This information can then be pulled from the Eureka Server registry into its own local cache.

At this time, if the order service wants to call the inventory service, it can not find its own local Eureka Client and ask which machine the inventory service is on. Which port to listen to?

After receiving the response, you can send a request to invoke the interface of inventory service deduction! Similarly, if the order service wants to call the warehousing service and the points service, it is also the same.

To sum up:

Eureka Client: Responsible for registering information about this service in Eureka Server.

Eureka Server: Registry, which has a registry that stores the machine and port number where each service is located.

Spring Cloud Core Component: Feign

Now the Order Service does know where the Inventory Service, Points Service and Warehouse Service are located and which port numbers are monitored.

But here's the new question: does the order service have to write a bunch of code, establish network connections with other services, construct a complex request, send the request, and write a bunch of code to process the response?

This is the code fragment of the above process translation, let's take a look together and experience this desperate and helpless feeling!!!

Friendly reminder, high energy ahead:

After reading the code above, do you feel cold back and cold sweat? In fact, if you hand-write code every time you make a call between services, the amount of code is at least several times more than the above paragraph, so this is not something Earthlings can do at all.

If so, what should we do? Don't worry, Feign has already provided us with an elegant solution. Let's see what your order service calls inventory service code looks like if you use Feign.

What does it feel like to read the code above? Does it feel like the whole world is clean and you have found the courage to live!

There is no underlying code to establish a connection, construct a request, and parse the response. It is directly to define a Feign Client interface with annotations, and then call that interface.

Feign Client will establish a connection with the service you specify, construct a request, initiate a request, obtain a response, parse the response, and so on according to your annotation at the bottom. This series of dirty work, Feign has done it all for you.

So the question is, how did Feign do it? Quite simply, one of Feign's key mechanisms is the use of dynamic proxies.

Let's take a look at the picture above and analyze it together with the picture:

First, if you define the @ FeinClient annotation for an interface, Feign creates a dynamic proxy for that interface.

And then if you invoke that interface, essentially you invoke the dynamic proxy Feign creates, which is the core of the core.

Feign's dynamic proxy dynamically constructs the address of the service you want to request based on annotations such as @RequestMapping on your interface.

Finally, for this address, initiate a request and parse the response.

Spring Cloud Core Component: Ribbon

Feign, not yet. Now there is a new problem, if the inventory service is deployed on 5 machines.

As follows:

192.168.169:9000

192.168.170:9000

192.168.171:9000

192.168.172:9000

192.168.173:9000

This was troublesome! How does Feign know which machine to request? The Spring Cloud Ribbon comes in handy.

Ribbon is specifically designed to solve this problem. It acts as a Load Balancer, helping you select a machine for each request and distribute requests evenly across machines.

Ribbon's Load Balancer defaults to the classic Round Robin polling algorithm. What's this?

Simply put, if order service makes 10 requests for inventory service, let's ask for machine 1, then machine 2, machine 3, machine 4, machine 5, then machine 1, machine 2 again. And so on.

In addition, the Ribbon is working closely with Feign and Eureka to complete the work, as follows:

First, the Ribbon will get the corresponding service registry from the Eureka Client, which also knows which machines all services are deployed on and which port numbers are listening to.

The Ribbon can then use the default Round Robin algorithm to select a machine from among them.

Feign constructs and initiates a request for that machine.

For the whole process above, let's take another picture to help you understand it more deeply:

Spring Cloud Core Component: Hystrix

In microservices architecture, a system has many services. Take the business scenario in this article as an example: order service needs to invoke three services in a business process.

Now suppose that the Order Service itself has a maximum of 100 threads to process requests, and then the Credits Service unfortunately hangs up. Every time the Order Service calls the Credits Service, it gets stuck for a few seconds and then throws a timeout exception.

Let's analyze it together. What problems will this lead to? If the system is in a high concurrency scenario, when a large number of requests come in, the 100 threads of the order service will be stuck in the request credit service, resulting in no thread of the order service to process the request.

Then it will cause others to request order service, and find that the order service is also hung up and does not respond to any requests.

The above is the terrible service avalanche problem in the microservice architecture, as shown in the following figure:

As shown in the above figure, so many services call each other. If no protection is done, one service will hang up, which will cause a chain reaction and cause other services to hang up.

For example, if the points service hangs, it will cause all the threads of the order service to be stuck in the request points service. None of the threads can work, which will instantly cause the order service to hang up. All the requests for order service by others will be stuck and unable to respond.

But let's think about it, even if the points service hangs up, the order service can also not hang up! Why not?

Let's look at the business: when paying the order, as long as the inventory is deducted, and then notify the warehouse to deliver the goods is OK.

If the points service hangs up, at worst, after it recovers, slowly recover the data manually! Why must because a point service hangs, it directly leads to the order service also hangs? Unacceptable!

Now that the problem analysis is over, how can we solve it? Then it was Hystrix's turn to shine. Hystrix is a framework for isolation, fusing and degradation. What does that mean?

To put it bluntly, Hystrix will make a lot of small thread pools, such as order service request inventory service is a thread pool, request warehousing service is a thread pool, request points service is a thread pool. Threads in each thread pool are used only to request that service.

For example: unfortunately now, the points service hangs up, what will happen? Of course, it will lead to the order service that is used to call the points service thread are stuck dead can not work ah!

However, since the order service calls the inventory service and the warehousing service, these two thread pools are working normally, so these two services will not be affected in any way.

At this time, if others request order service, order service can still call inventory service to deduct inventory and call warehousing service to notify delivery.

However, when calling the points service, it would report an error every time. But if the points service is down, what's the point of being stuck for a few seconds at a time? Does it make sense? Of course not!

Therefore, we can directly fuse the points service. For example, if we request the points service within 5 minutes, we will directly return it. Don't go to the network request for a few seconds. This process is the so-called fuse!

Then they said, brother, if the points service fails, you will be blown out. At least you can do something! don't just go back and do nothing, okay?

No problem, let's have a downgrade: every time you call the points service, you record a message in the database saying how many points have been added to a certain user, because the points service is hung up, resulting in no increase!

So when the points service is restored, you can add points manually according to these records. This process is called degradation.

To help you understand more intuitively, let's use a picture to sort out the whole process of Hystrix isolation, fusing and degradation:

Spring Cloud Core Component: Zuul

After Hystrix, let's talk about the last component: Zuul, which is the microservice gateway. This component is responsible for network routing.

Don't understand network routing? Okay, so let me tell you, what would happen if Zuul didn't have his day job?

Suppose you have hundreds of services deployed in the background, and now you have a front-end sibling whose requests come directly from the browser.

For example, if someone asks for an inventory service, do you want them to remember that the service is called inventory-service? Deployed on five machines?

Even if people are willing to remember this one, do you have hundreds of service names and addresses backstage? Did he have to remember one just because he asked for it? If you want to play like this, it's really a boat of friendship. It'll flip over when you say so!

The above situation was simply unrealistic. Therefore, in general microservice architecture, a gateway will inevitably be designed inside.

Like Android, iOS, PC front-end, Weixin Mini Programs (Mini), H5, etc., you don't have to care about hundreds of services on the backend, you know there is a gateway, all requests go to the gateway, and the gateway will forward the request to each service on the backend according to some characteristics in the request.

And after having a gateway, there are many benefits, such as uniform degradation, current limiting, authentication authorization, security, and so on.

If you want to learn Java engineering, high performance and distributed for free, easy to understand. Microservices, Spring, MyBatis, Netty source code analysis friends can add my Java advanced group: 705127209, the group has Ali Daniel live broadcast technology, and Java large Internet technology video free to share with you.

summary

Finally, to sum up, the above several Spring Cloud core components, in the microservices architecture, respectively, play a role:

Eureka: When each service starts, the Eureka Client registers the service with Eureka Server, and the Eureka Client can pull the registry from Eureka Server in turn to know where other services are.

Ribbon: When a request is initiated between services, Load Balancer is performed based on the Ribbon, and one machine is selected from multiple machines of a service.

Feign: Feign-based dynamic proxy mechanism that assembles request URL addresses based on annotations and selected machines to initiate requests.

Hystrix: The request is initiated through the thread pool of Hystrix. Different services go through different thread pools, realizing the isolation of different service calls and avoiding the problem of service avalanche.

Zuul: If the front-end and mobile end want to invoke the back-end system, they enter from the Zuul gateway in a unified way, and the Zuul gateway forwards the request to the corresponding service.

The above is how we explain the underlying principles of several core components of Spring Cloud microservices architecture through an e-commerce business scenario.

Isn't the text summary intuitive enough? No problem! Let's connect the five core components of Spring Cloud through a diagram, and then intuitively feel the underlying architecture principle:

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.