Come on! Please don’t ask me about the underlying principles of Spring Cloud

Did you get a chill on your back and a cold sweat after reading that long piece of code? In fact, if you write code every time you make an interservice call, it will be at least several times more code, so it’s not humanly possible.

In that case, what to do? Don’t worry, Feign has already provided us with an elegant solution. Let’s see what your order service calls the inventory service code looks like with Feign.

How does it feel to see the code above? Does not feel the whole world is clean, and found the courage to live! There is no low-level code for establishing a connection, constructing a request, and parsing a response. It’s just a matter of annotating a FeignClient interface and calling that interface. The Feign Client will make connections to the service you specify, construct requests, initiate 靕 requests, get responses, parse responses, and so on, based on your annotations. Feign did all the dirty work for you.

So, how did Feign pull this off? Quite simply, one of the key mechanics of Feign is the use of dynamic proxies. Let’s take a look at the following picture, combined with the picture to analyze:

• First, if you define the @FeignClient annotation for an interface, Feign will create a dynamic proxy for that interface
• And then if you call that interface, you’re essentially calling the dynamic proxy created by Feign, which is the core of the core
• Feign’s dynamic proxy dynamically constructs the address of the service you want to request based on your @requestMapping annotation on the interface
• Finally, the request is initiated and the response parsed against this address

4. Spring Cloud core component: Ribbon

We’re done with Feign. Now a new problem arises, if the home 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 is trouble! How does Feign know which machine to request?

• This is where the Spring Cloud Ribbon comes in. This is exactly what Ribbon is designed to do. It works as a load balancer, helping you select one machine for each request and distribute the request evenly to each machine
• The Ribbon uses the classic Round Robin algorithm by default for load balancing. What is this? In simple terms, if the order service makes 10 requests to the inventory service, let you request the first machine, then the second machine, then the third machine, then the fourth machine, then the fifth machine, then another cycle, the first machine, the second machine… And so on.

In addition, Ribbon works closely with Feign and Eureka as follows:

• First, the Ribbon retrieves the service registry from the Eureka Client. This enables the Ribbon to know which machines all services are deployed on and which port numbers they are listening to.
• The Ribbon then uses the default Round Robin algorithm to select a machine
• Feign will construct and initiate a request for that machine.

Here’s another picture to help you understand the whole process:

Core components of Spring Cloud: Hystrix

In a microservices architecture, a system has many services. Take the business scenario in this article as an example: The order service needs to invoke three services in a business process. Now assume that the order service itself has at most 100 threads to handle requests, and then the integral service unfortunately hangs. Every time the order service calls the integral service, it gets stuck for a few seconds and throws a timeout exception.

Let’s analyze it. What’s the problem?

1. 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 get stuck in the request credit service. The order service does not have a thread to process the request
2. Then, when someone requests the order service, they find that the order service also hangs and does not respond to any requests

This, above, is the dreaded service avalanche problem in microservices architecture, as shown in the figure below:

As shown above, with so many services calling each other, if one service fails without any protection, it will cause a chain reaction of other services to fail. For example, if the integral service is suspended, all threads of the order service will be stuck in the integral request service, and no thread can work. As a result, the order service will also be suspended instantly, and all the order services will be stuck and unable to respond to other people’s requests.

But let’s think about it, even if the integral service is suspended, the order service can also not be suspended! Why is that?

• According to our business, when you pay the order, you only need to deduct the inventory and then inform the warehouse to deliver the goods
• If the integral service is suspended, the biggest thing is to wait for him to recover, slowly manual recovery data! Why is it necessary for a credit service to fail, so that the order service fails? Unacceptable!

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

This is where Hystrix comes in. Hystrix is a framework for isolation, circuit breakers, and downgrades. What does that mean? To put it plainly, Hystrix has many small thread pools, such as order service request inventory service is a thread pool, request warehousing service is a thread pool, request credit service is a thread pool. The threads in each thread pool are used only to request that service.

For example: now unfortunately, the points service failed, what will happen?

Of course, it will cause the order service thread used to call the integral service to freeze up! But since both thread pools, which the order service calls the inventory service and the warehouse service, are working, these two services are not affected at all.

At this time, if others request the order service, the order service can still call the inventory service to deduct the inventory and call the storage service to notify the delivery. But when I call the integral service, I get an error every time. ** But what if the credits service is suspended and stuck for a few seconds each time it is called? Does it make sense? Of course not! ** Therefore, we can directly fuse the integral service, such as within 5 minutes to request the integral service directly returned, do not go to the network request stuck for a few seconds, this process is the so-called fuse!

** that somebody else say again, brother, integral service hung you melt off, somehow you stem some what ah! Why don’t you just go back and do nothing? Every time you call the integral service, you will record a message in the database, saying how many points have been added to the so-and-so user, because the integral service failed, resulting in no successful increase! So when the points service is restored, you can manually add points based on these records. This process is called demotion.

To help you visualize the process of Hystrix isolation, fusing and degradation, here is a diagram:

Vi. Spring Cloud core component: Zuul

With Hystrix out of the way, I move on to the final component: Zuul, or microservices gateway. ** This component is responsible for network routing. ** Don’t understand network routing? Okay, let me tell you something. What 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 request comes directly from the browser. For example, if someone asks for an inventory service, do you let them remember the name of the service as inventory-service? Deployed on five machines? Even if people remember this one, do you have the names and addresses of hundreds of services in the background? Do people ask for one and have to remember one? You want to play like this, that is really the boat of friendship, said to turn over!

This is simply not realistic. So general micro service architecture will design a gateway in the inside, as android, ios, PC front end, WeChat applet, H5, and so on, don’t need to care about the back-end has hundreds of service, will know that there is a gateway, all requests to the gateway, the gateway will be according to the request of some characteristics of each service will forward the request to the backend.

Moreover, there are many benefits after having a gateway, such as unified degradation, traffic limiting, authentication and authorization, security, and so on.

Vii. Summary:

Finally, to summarize the roles of these Spring Cloud core components in the microservices architecture:

• Eureka: When each service is started, the Eureka Client registers the service with the Eureka Server, and in turn, the Eureka Client can pull the registry from the Eureka Server to know where other services are
• Ribbon: When the Ribbon sends requests between services, it performs load balancing. The Ribbon selects one machine for a service
• Feign: FeIGN-based dynamic proxy mechanism that concatenates request URLS and initiates requests based on annotations and selected machines
• Hystrix: Requests are routed through Hystrix’s thread pool. Different services are routed through different thread pools, which enables the isolation of different service calls and avoids service avalanche
• Zuul: If the front end and mobile end want to call the back end system, they enter through Zuul gateway and forward the request to the corresponding service

Above is the underlying principle of several core components of Spring Cloud microservice architecture through an e-commerce business scenario.

** Text summary not intuitive enough? No problem! ** Let’s connect the five core components of Spring Cloud in series through a diagram to intuitively feel the underlying architectural principles:

If there is any harvest, please help to forward, your encouragement is the biggest power of the author, thank you!

The Spring Cloud original series will be updated continuously

Welcome to follow our wechat official account: Shishan100

More than ten years of EXPERIENCE in BAT architecture