Overview
There is no doubt that Spring Cloud is currently the leader in the field of microservice architecture, and countless books and blogs are explaining this technology. However, most of the explanations still stay at the level of using Spring Cloud functions. Many of its underlying principles may not be known to many people. Therefore, this article will use a lot of hand-drawn drawings to talk about the underlying principles of the Spring Cloud microservice architecture.
In fact, Spring Cloud is a family bucket technology stack that contains many components. This article starts with a few of its core components to analyze its underlying working principle. That is Eureka, Ribbon, Feign, Hystrix, Zuul these components.
1. Introduction to business scenarios
Let me tell you a business scenario first. Suppose we now develop an e-commerce website to implement the function of paying orders. The process is as follows:
- After creating an order, if the user paid the order immediately, we need to update the order status to "Paid"
- Deduct the corresponding merchandise inventory
- Inform the warehouse to deliver
- Add corresponding points to the user's shopping
For the above process, we need to have order service, inventory service, warehousing service, points service. The general idea of the entire process is as follows:
- After the user completes the payment for an order, he will go to the order service and update the order status
- Order service calls inventory service to complete corresponding functions
- The order service calls the warehousing service to complete the corresponding functions
- Order service calls credit service to complete corresponding functions
At this point, the business process of the entire payment order ends
The picture below clearly shows the calling process between services:
it is good! With the business scenario in place, let's take a look at how these components work together in the Spring Cloud microservice architecture, their respective roles, and the principles behind them.
2. Spring Cloud core component: Eureka
Let's consider the first question: How do you order the order service to call the inventory service, warehousing service, or credit service?
- Order service simply doesn't know which machine the inventory service is on! Even if he wanted to make a request, he didn't know who to send it to, and he was helpless!
- At this time, it was Spring Cloud Eureka's turn. Eureka is a registration center in the microservice architecture, which is responsible for the registration and discovery of services.
Let's take a look at the following picture and carefully analyze the whole process in conjunction with the picture:
As shown in the figure above, there is an Eureka Client component in the inventory service, warehousing service, and credit service. This component is specifically responsible for registering the information of this service in the Eureka Server. To put it bluntly, it is to tell Eureka Server which machine it is and which port it is listening on. And Eureka Server is a registration center, which has a registry that saves the machine and port number where each service is located
There is also an Eureka Client component in the order service. This Eureka Client component will find Eureka Server and ask: Which machine is the inventory service? Which port is listening? What about warehousing services? What about points service? Then you can pull the relevant information from the Eureka Server's registry to your own local cache.
At this time, if the order service wants to call the inventory service, you can not find your local Eureka Client and ask which machine is the inventory service? Which port is listening? After receiving the response, you can then send a request to call the inventory service to deduct the inventory interface! In the same way, if the order service needs to call the warehousing service and point service, it is the same.
in conclusion:
- Eureka Client: responsible for registering the information of this service in Eureka Server
- Eureka Server: The registration center, which has a registry, which stores the machine and port number where each service is located
3. Spring Cloud core component: Feign
Now the order service does know where the inventory service, credit service, and warehouse service are, and what port numbers are being monitored. But the new problem is here again: Is it necessary for the order service to write a lot of code, establish a network connection with other services, then construct a complex request, then send the request over, and finally write a lot of code for the returned response Handle?
This is the code snippet 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 large section of code above, did you feel cold and sweaty? In fact, when you call the service, if you write the code every time, the amount of code is at least several times more than the above paragraph, so this matter is not at all capable of the earth.
In this case, what should we do? Don't worry, Feign has already provided us with an elegant solution. Let's see what code your order service will call the inventory service if you use Feign?
What does it feel like to read the above code? Do you feel that the whole world is clean and you have found the courage to live! There is no underlying code for establishing a connection, constructing a request, and parsing a response, just define a FeignClient interface with annotations, and then call that interface. Based on your annotations, Feign Client will establish a connection with the service you specified, construct a request, initiate a request, obtain a response, parse the response, etc. based on your annotations. This series of dirty work is exhausting, and Feign has done it for you.
So the question is, how does Feign do this magic? Very simple, a key mechanism of Feign is the use of dynamic proxies. Let's take a look at the following diagram together, combined with the diagram to analyze:
- First, if you define @FeignClient annotation on an interface, Feign will create a dynamic proxy for this interface
- Then if you call that interface, the essence is to call the dynamic proxy created by Feign, which is the core of the core
- Feign's dynamic proxy will dynamically construct the address of the service you want to request based on your @RequestMapping and other annotations on the interface
- Finally, for this address, initiate a request and parse the response
Four, Spring Cloud core component: Ribbon
Having said Feign, it is not finished. Now the new problem is coming again, if people's inventory service is deployed on 5 machines, as shown below:
- 192.168.169:9000
- 192.168.170:9000
- 192.168.171:9000
- 192.168.172:9000
- 192.168.173:9000
This is troublesome! How does Feign know which machine to request?
- Spring Cloud Ribbon comes in handy. Ribbon is specifically to solve this problem. Its role is load balancing, it will help you choose a machine for each request, and evenly distribute the request to each machine
- Ribbon load balancing uses the most classic Round Robin polling algorithm by default. what is this? To put it simply, if the order service initiates 10 requests for the inventory service, then let you first request the first machine, then the second machine, the third machine, the fourth machine, the fifth machine, and then Come again-a cycle, the first machine, the second machine. . . And so on.
In addition, Ribbon worked closely with Feign and Eureka to complete the work, as follows:
- First, Ribbon will obtain the corresponding service registry from the Eureka Client, and you will know on which machines all services are deployed and which port numbers are listening.
- Then Ribbon can use the default Round Robin algorithm to choose a machine from it
- Feign will construct and initiate a request for this machine.
For the entire process above, let's take another picture to help you understand more deeply:
V. Spring Cloud core components: Hystrix
In a microservices architecture, a system will have many services. Take the business scenario in this article as an example: the order service needs to call three services in a business process. Now suppose that the order service itself can only handle up to 100 threads. Then, the integration service unfortunately hangs. Every time the order service calls the integration service, it will be stuck for a few seconds and then throw a timeout exception.
Let's analyze it together, what problems will this cause?
- If the system is in a high-concurrency scenario, when a large number of requests come in, 100 threads of the order service will be stuck in the request point service. The order service does not have a thread to process the request
- Then it will cause others to request the order service, and find that the order service has also hung up, and will 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 figure above, so many services call each other. If any protection is not done, a certain service will hang, which will cause a chain reaction and cause other services to hang. For example, if the credit service hangs, it will cause all the threads of the order service to be stuck in the request credit service. None of the threads can work, and the order service will also hang in an instant. Anyone who requests the order service will be stuck and unable to respond.
But let's think about it, even if the points service is hung up, the order service doesn't need to be hung up! why?
- Let's look at the business: when paying for the order, as long as the inventory is deducted, and then notify the warehouse to ship, it will be OK
- If the points service hangs, wait for him to recover, and slowly restore the data manually! Why do you have to hang up the order service because of a point service? Not acceptable!
Now that the problem is analyzed, how to solve it?
Then it was Hystrix's turn. Hystrix is a framework for isolation, fusing and degradation. What do you mean? To put it bluntly, Hystrix will engage in many small thread pools. For example, the order service request inventory service is a thread pool, the request storage service is a thread pool, and the request integration service is a thread pool. The threads in each thread pool are only used to request that service.
To draw an analogy: It is unfortunate now that the point service has hung up, what will happen?
Of course, the thread used to call the credit service in the order service will be stuck and will not work! However, since the order service calls the inventory service and warehousing service, the two thread pools are working normally, so these two services will not be affected in any way.
At this time, if someone requests the order service, the order service can still call the inventory service to deduct the inventory normally, and call the warehousing service to notify the delivery. It's just that when you call the points service, you will get an error every time. But if the points service is hung up, why do you have to get stuck for a few seconds each time you call? Does it make sense? of course not! So we can't get the credit service directly. For example, if you request the credit service within 5 minutes and return directly, don't go to the network to get stuck for a few seconds. This process is called fuse!
The other person said, "Brother, if you hang up on the point service, you will blow it. Anyway, what are you doing!" Do n’t just return without doing anything? No problem, let's downgrade: every time you call the credit service, you will record a message in the database, saying how many credits have been added to the user, because the credit service has hung up, resulting in no success! After the point service is restored, you can manually add points based on these records. This process is called downgrade.
To help you understand more intuitively, let's use a picture to sort out the entire process of Hystrix isolation, fuse and degradation:
Six, Spring Cloud core component: Zuul
After talking about Hystrix, let's talk about the last component: Zuul, which is the micro service gateway. This component is responsible for network routing. Don't understand network routing? Okay, let me tell you, what would happen if Zuul didn't do his daily work?
Suppose you have deployed hundreds of services in the background, and now there is a front-end brother, and the request is sent directly from the browser. To make an analogy: People need to request inventory services, do you still remember the name of this service is inventory-service? Deploy on 5 machines? Even if people are willing to remember this one, you can have hundreds of service names and addresses in the background? Is it necessary for an adult family to request one, but one must be remembered? If you want to play like this, it is really a boat of friendship.
The above situation is unrealistic at all. Therefore, in the general microservices architecture, a gateway is inevitably designed, such as android, ios, pc front end, WeChat applet, H5, etc., without having to care about the hundreds of services on the back end, you know that there is a gateway, all requests All go to the gateway, and the gateway will forward the request to the back-end services according to some characteristics of the request.
And after having a gateway, there are many benefits, such as unified downgrade, current limiting, authentication and authorization, security, and so on.
7. Summary:
Finally, to summarize, the above several Spring Cloud core components, in the micro-service architecture, play the roles:
- Eureka: When each service is started, the Eureka Client will register the service to the Eureka Server, and the Eureka Client can also pull the registry from the Eureka Server in turn, so as to know where other services are
- Ribbon: When a request is initiated between services, load balancing is performed based on the Ribbon, and one of multiple machines in a service is selected.
- Feign: Based on Feign's dynamic proxy mechanism, according to the annotation and the selected machine, the request URL is spliced to initiate the request
- Hystrix: The request is initiated through the Hystrix thread pool. Different services use different thread pools to achieve the isolation of different service calls and avoid the problem of service avalanches.
- Zuul: If the front-end and mobile terminals want to call the back-end system, they will all enter from the Zuul gateway, and the Zuul gateway will forward the request to the corresponding service.
The above is that we have explained the underlying principles of several core components of the Spring Cloud microservice architecture through an e-commerce business scenario.
The text summary is not intuitive enough? no problem! We connect the five core components of Spring Cloud in a picture, and then intuitively feel the underlying architectural principles:
If you have any harvest, please help forward it, your encouragement is the author's biggest motivation, thank you!
If you need information, you can use the private information "information"!