Welcome to follow our wechat official account: Shishan100

My new course ** “C2C e-commerce System Micro-service Architecture 120-day Practical Training Camp” is online in the public account ruxihu Technology Nest **, interested students, you can click the link below for details:

120-Day Training Camp of C2C E-commerce System Micro-Service Architecture

directory

1. Introduction to service scenarios

Spring Cloud core component: Eureka

Spring Cloud core component: Feign

4. Spring Cloud core component: Ribbon

Core components of Spring Cloud: Hystrix

Vi. Spring Cloud core component: Zuul

Seven,

An overview of the

Spring Cloud is undoubtedly the current leader in microservices architecture, with countless books and blogs devoted to the technology. However, most of the explanation is still about the use of Spring Cloud features, and many of the underlying principles may not be known by many people. Therefore, this article will talk about the underlying principles of the Spring Cloud microservices architecture with lots of hand-drawn diagrams.

In fact, Spring Cloud is a whole family bucket technology stack with many components. This paper starts with its core components to analyze the underlying working principle. Eureka, Ribbon, Feign, Hystrix, Zuul.

1. Introduction to service scenarios

Let’s first tell you a business scenario, suppose we now develop 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 inventory of goods
  • Notify the warehouse center for shipment
  • Add points to the user for this purchase

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

  • After a user has paid for an order, they go to the order service and update the status of the order
  • The order service invokes the inventory service to complete the corresponding function
  • The order service invokes the warehouse service to complete the corresponding function
  • Order service invokes integral service to complete corresponding functions

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

The following figure clearly shows the invocation process between services:

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

Spring Cloud core component: Eureka

Let’s consider the first question: how does the order service want to call the inventory service, the warehouse service, or the points service?

  • The order service 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.
  • This is where Spring Cloud Eureka comes in. Eureka is a registry in the microservices architecture that is responsible for registering and discovering services.

Let’s take a look at the diagram below and take a closer look at the process:

As shown in the figure above, the Inventory service, warehousing service, and credits service all have a Eureka Client component, which is responsible for registering the information of this service with Eureka Server. Basically, it tells the Eureka Server which machine it is on and which port it is listening to. Eureka Server is a registry with a registry that stores the machine and port number of each service

There is also a Eureka Client component in the order service. The Eureka Client component will ask the Eureka Server: Which machine is the inventory service? What port are you listening to? What about warehousing? How about points service? This information can then be pulled from the Eureka Server registry into its own local cache.

If the order service wants to call the inventory service, it can ask the local Eureka Client which machine the inventory service is on. What port are you listening for? Upon receiving the response, you can then send a request to invoke the inventory service’s destocking interface! The same is true if the order service calls the warehousing service or the credits service.

To sum up:

  • **Eureka Client: ** Is responsible for registering information about this service with Eureka Server
  • **Eureka Server: ** Registry, which contains a registry that stores the machine and port number of each service

Spring Cloud core component: Feign

Now the order service really knows where the inventory service, the credits service, the warehouse service are, and what port numbers it is listening to. But a new problem arises: does the order service write a whole bunch of code itself, establish network connections with other services, construct a complex request, send the request, and then write a whole bunch of code to handle the response that comes back?

This is the code snippet of the above process translation, let’s have a look and experience the feeling of despair and helplessness!!

Friendly tips, high energy ahead:

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