[Part 1] Introduction to Spring Cloud

1.1 Overview

Spring CloudIt is currently the leader in the field of microservice architecture, and countless books and blogs are explaining this technology. However, most of the explanations are still at Spring Cloudthe level of function use, and many people may not know the underlying principles.

In fact, it Spring Cloudis a whole family bucket-style technology stack, a one-stop solution for distributed microservice architecture, which contains many components. This article starts with its core components to analyze its underlying working principle. That is, Eureka、Ribbon、Feign、Hystrix、Zuulthese components.

1.2 Introduction to business scenarios

Let me tell you a business scenario first. Suppose we are developing an e-commerce website now. To realize the function of paying for orders, the process is as follows:

• After creating an order, if the user pays the order immediately, update the order status to "paid"
• Deduct the corresponding product inventory
• Notify the warehouse center for delivery
• Add corresponding points to the user's purchase

For the above process, we need order service, inventory service, warehousing service, and point service . The general idea of ​​the whole process is as follows:

• After the user completes the payment for an order, he will go to the order service to update the order status
• The order service calls the inventory service to complete the corresponding function
• The order service calls the warehousing service to complete the corresponding function
• The order service calls the integral service to complete the corresponding function

At this point, the entire business process of paying the order ends

The picture below clearly shows the calling process between services:

After we have the business scenario, let's take a look at Spring Cloudhow these components cooperate with each other in the microservice architecture, their roles and the principles behind them.

1.3 Spring CloudCore components:Eureka

Let's consider the first question: How to call the order service if you want to call the inventory service, warehousing service, or point service?

The order service does not know which machine the inventory service is on! Even if he wants to initiate a request, he doesn't know who to send it to, and he is powerless!

At this point, it was time to Spring Cloud Eurekashow up. EurekaIt is the 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 analyze the whole process carefully in combination with the picture:

As shown in the figure above, there is a component in the inventory service, warehousing service, and point service, which is responsible for registering the information ofEureka ClientEureka Server this service into . To put it bluntly, it is to tell Eureka Serverwhich machine you are on and which port you are listening on. InsteadEureka Server , it is a registry, which has a registry that saves the machine and port number where each service is located .

There is also a Eureka Clientcomponent in the order service. This Eureka Clientcomponent will Eureka Serverask: which machine is the inventory service on? Which port are you listening on? What about warehousing services? What about points service? Then you can pull the relevant information from Eureka Serverthe registry to your local cache.

At this time, if the order service wants to call the inventory service, you can ask your local Eureka Clientmachine which machine the inventory service is on? Which port is it listening on? After receiving the response, you can then send a request to call the interface of the inventory service to deduct the inventory! In the same way, if the order service needs to call the warehousing service and the point service, it is also done in the same way.

in conclusion:

• Eureka Client: Responsible for registering the information of this service Eureka Serverinto
• Eureka Server: Registry center, which has a registry that saves the machine and port number where each service is located

1.4 Spring CloudCore components:Feign

Now the order service does know where the inventory service, point service, and warehouse service are, and which port numbers are listening at the same time. But a new question arises: Does the order service have to write a lot of code by itself, establish a network connection with other services, then construct a complex request, then send the request, and finally write a lot of code for the returned response. deal with it?

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

Friendly reminder, high energy ahead:

After reading the large piece of code above, did you feel a chill on your back and a cold sweat? In fact, when you make an inter-service call, if you write code every time, the amount of code is at least several times larger than the above paragraph, so this is not something that people on earth can do.

In that case, what should we do? Don't worry, Feignwe have already provided us with an elegant solution. FeignLet's see what the code for your order service to call the inventory service will look like if you use it?

How do you feel after reading the code above? Do you feel that the whole world is clean, and you have found the courage to live again! There is no underlying code for establishing a connection, constructing a request, and parsing a response. Just define an FeignClientinterface , and then call that interface. Based on your annotations, peopleFeign Client will establish a connection with the service you specify, construct a request, initiate a request, get a response, parse the response, and so on . This series of dirty work is Feignall done for you.

So the question is, Feignhow is it so magical? Quite simply, Feignone of the key mechanisms is the use of dynamic proxies . Let's take a look at the following figure and analyze it in combination with the figure:

• First, if you define an @FeignClientannotation on an interface, Feigna dynamic proxy will be created for this interface
• Then if you call that interface, the essence is to call Feignthe created dynamic proxy, which is the core of the core.
• FeignThe dynamic proxy will @RequestMappingdynamically construct the address of the service you want to request based on your annotations on the interface.
• Finally, for this address, initiate a request and parse the response

1.5 Spring CloudCore Components:Ribbon

It 's over Feign, it's not over yet. Now the new problem comes again, if people's inventory service is deployed on a 5machine, as shown below:

192.168.169:9000
192.168.170:9000
192.168.171:9000
192.168.172:9000
192.168.173:9000

Here's to trouble! How Feigndoes one know which machine to request?

• That's where Spring Cloud Ribbonit comes in handy. RibbonIt is specially designed to solve this problem. Its function is load balancing, which will help you select a machine for each request and distribute the request evenly to each machine
• RibbonRound RobinThe most classic round- robin algorithm used by default load balancing . what is this? Simply put, if the order service initiates a 10second request to the inventory service, it will let you request the first 1machine, then the first 2machine, the first 3machine, the first 4machine, the first 5machine, and then a cycle, the first 1machine, 2machine. . . And so on.

In addition, work Ribbonis done in close collaboration with Feignand Eurekaas follows:

• First Ribbon, you Eureka Clientwill get the corresponding service registry from , and you will know which machines all services are deployed on and which port numbers are listening.
• Then Ribbonyou can use the default Round Robinalgorithm to choose a machine from
• FeignA request will be constructed and initiated against this machine.

For the whole process above, here is another picture to help you understand more deeply:

1.6 Spring CloudCore components:Hystrix

In a microservice architecture, a system will have many services. Take the business scenario of this article as an example: the order service needs to call three services in a business process. Now suppose that the order service itself has at most 100one thread that can process the request. Then, the point service unfortunately hangs up. Every time the order service calls the point service, it will be stuck for a few seconds, and then a timeout exception will be thrown.

Let's analyze it together, what problems will this cause?
1. If the system is in a high concurrency scenario, when a large number of requests come in, 100each thread of the order service will be stuck in the request point service. As a result, there is no thread in the order service that can process request
2, and then when others request the order service, they find that the order service also hangs and does not respond to any requests.

The above is the terrifying 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 one service fails, it will cause a chain reaction and cause other services to fail. For example, if the point service is hung up, all the threads of the order service will be stuck in the request point service. No thread can work, and the order service will also be hung up in an instant. Others requesting the order service will all be stuck and unable to respond.

But let's think about it, even if the points service is suspended, the order service can be suspended! Why?

• Let’s look at it in combination with the business: when paying for the order, just deduct the inventory, and then notify the warehouse to deliver OKthe goods.
• If the points service hangs, the big deal is that after he recovers, he will slowly restore the data manually! Why does it have to be because a point service has been suspended that the order service has also been suspended? Unacceptable!

Now that the problem is analyzed, how to solve it?

Now it's time to Hystrixshine. HystrixIt is a framework for isolation, circuit breaker, and degradation . What do you mean? To put it bluntly, Hystrixthere will be many small thread pools . For example, the order service requesting the inventory service is a thread pool, the request for the warehouse service is a thread pool, and the request point service is a thread pool. Threads in each thread pool are used only to request that service.

For example, it is unfortunate that the point service has been suspended. What will happen?

Of course, the thread used to call the point service in the order service will be stuck and cannot work! However, since the two thread pools of the order service calling the inventory service and the warehousing service are working normally, these two services will not be affected in any way.

At this time, if someone else 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 calling the point service, an error will be reported every time. But if the point service is all hung up, why do you have to get stuck for a few seconds every time you call it ? Does it make sense? of course not! Therefore, we can directly fuse the credit service . For example, the request for the credit service will return directly within 5 minutes . Don't go to the network request and get stuck for a few seconds. This process is the so-called fuse !

That person said again, brother, if the points service is hung up, it will be cut off, so what are you doing? Don't do anything and just go back ? No problem, let's downgrade : every time you call the points service, you will record a message in the database, saying how many points have been added to a certain user, because the points service has been suspended, resulting in no success in adding points! In this way, when the points service is restored, you can manually add points based on these records. This process is called downgrading .

In order to help you understand more intuitively, let's use a picture to sort out Hystrixthe whole process of isolation, fusing and downgrading:

1.7 Spring CloudCore components:Zuul

After that Hystrix, let's talk about the last component: Zuul, which is the microservice gateway. This component is responsible for network routing . Don't know network routing? OK, then let me tell you, Zuulwhat would happen if you didn't have a daily job?

Suppose you have hundreds of services deployed in the background, and now there is a front-end brother, and people's requests are sent directly from the browser. For example: if someone wants to request an inventory service, do you still ask them to remember the name of this service inventory-service? Deployed on 5a single machine? Even if people are willing to remember this one, what about the names and addresses of hundreds of services in your background? Is it possible that when a family requests one, they have to remember one? If you want to play like this, it's really a small boat of friendship, if you say it is overturned!

The above situation is not realistic at all. Therefore, in the general microservice architecture, a gateway is bound to be designed in it, such as the android、ios、pcfront end, WeChat applet, H5etc. You don't need to care about the hundreds of services in the back end, you know that there is a gateway, and all requests go to the gateway, the gateway According to some characteristics of the request, the request will be forwarded to various services on the backend.

And after having a gateway, there are many benefits, such as unified downgrade, current limit, authentication and authorization, security , and so on.

1.8 Summary

Finally, let’s summarize Spring Cloudthe roles of the above-mentioned core components in the microservice architecture:

• Eureka: When each service starts, Eureka Clientthe service will be registered to Eureka Server, and you can also pull the registry Eureka Clientfrom the reverse , so as to know where other services areEureka Server
• Ribbon: When a request is initiated between services, based on Ribbonload balancing, select one from multiple machines of a service
• Feign: Based on Feignthe dynamic proxy mechanism, according to the annotation and the selected machine, the request URLaddress is spliced, and the request is initiated
• Hystrix: The request is initiated through Hystrixthe thread pool. Different services use different thread pools, which realizes the isolation of different service calls and avoids the problem of service avalanches.
• Zuul: If the front-end and mobile end want to call the back-end system, Zuulthey enter from the gateway uniformly, and the Zuulgateway forwards the request to the corresponding service

Spring CloudThe above is our explanation of the underlying principles of several core components of the microservice architecture through an e-commerce business scenario .

The text summary is not intuitive enough? no problem! We connect each of Spring Cloudthe 5core components through a diagram, and then intuitively feel the underlying architecture principle: