Explain the Ribbon structure in detail, aiming at the interview high-frequency questions

Why use the Ribbon

In the previous chapter, we studied the registration center. Do you know what Eureka is? This time, I am not silent. When we know that there are multiple service providers, we will ask all the service providers to register the service node information in EurekaServer, and then ask the client to pull a service registration list to the local. The service consumer will find the appropriate service instance information from the service registry and invoke the service through IP:Port.

How do consumers decide which service instances to invoke? Ribbon, the protagonist of this chapter, stands up silently and says with a smile, yes, I am.

Srping Cloud Ribbon is a client load balancing tool based on Netflix Ribbon.

To put it simply, the Ribbon is an open source service released by Netflix. Its main function is to parse the service list in the configuration or registry and distribute service requests through the software negative balancing algorithm on the client side.

The Ribbon client provides a range of sophisticated configuration options such as connection timeout and retry.

Simply put, the Ribbon lists all the machines after LoadBalancer in the configuration file. The Ribbon will automatically help you to connect these machines based on certain rules (drum polling, random linking, etc.).

It is also easy to enable the Ribbon to implement custom load balancing algorithms.

What’s the difference between the Ribbon and Nginx?

Centralized load balancing

So what you see here is a centralized load balancer a centralized load balancer is like a real estate broker, he has a lot of housing information.

Service consumers are just like tenants who need to rent a house. We cannot directly conduct rental transactions with the owner of the house, but choose the housing information through the housing intermediary to achieve rental transactions.

In other words, the client does not request the service instance directly, but selects a certain service instance through the load balancing algorithm when it reaches the load balancer, and then forwards the request to the service instance.

Centralized load balancers are divided into hardware load balancers, such as F5, and software load balancers, such as Nginx.

Client load balancing

This is client-side load balancing. For example, there are a lot of rental apps, and many owners don’t want to rent through an intermediary, they want to save a lot of intermediary fees.

Many tenants also want to save money on agency fees and do not want to rent through an intermediary, so they record the rental information on the App in their notebooks.

However, due to the tenant’s lack of experience in renting, he does not know which suite to choose. At this time, the tenant happens to have a friend who is a real estate agent (just so coincidentally), so the tenant will invite his friend to the home, let him help with advice, choose a good housing source, and then the tenant will go directly to see the house.

In other words, client requests are no longer forwarded to the load balancer. The client maintains a set of service lists. Before a service instance is to be discarded, the client selects a service node through the load balancing algorithm and sends requests directly to the service node.

Ribbon Architecture

Let’s start with a picture:

Let’s take a closer look at the six component interfaces of the Ribbon core shown in the figure above.

IRule

IRule means that the Ribbon selects a service from a list of servers to access based on a particular algorithm. The default algorithm is polling.

Let’s look at an IRule class inheritance diagram:

The leaf nodes circled in red are load balancing algorithms that are still in use, while the ones circled in purple are obsolete.

As can be seen from the figure, there are several load balancing algorithms currently used by us:

RoundRobinRule and WeightedResponseTimeRule

So round Rule, which I didn’t circle but it’s a very common load balancing algorithm, means that you take down one server at a time.

Linear polling algorithm implementation: each time the request from the user is assigned to the server in turn, starting from 1 to N(number of servers), and then the cycle starts again. The advantage of the algorithm is its simplicity, it does not need to record the state of all the current connections, so it is a stateless scheduling.

RoundRobinRule and Weightedresponse Rule are inherited and inherited relationships.

WeightedResponseTimeRule calculates the weight of all services based on average response time. The faster the response time, the greater the weight, the greater the probability of being selected.

There is a scheduled task that updates the weight list every 30 seconds by default, based on the response time of the instance.

However, if statistics are insufficient at startup, the RoundRobinRule policy is used, and when statistics are sufficient, the WeightedResponseTimeRule is switched to.

AvailabilityFilteringRule

AvailabilityFilteringRule will filter out due to multiple access fault in the circuit breaker state service, there are complicated by the number of connections over threshold of service, and then for the rest of the service list according to the polling strategy for a visit.

ZoneAvoidanceRule

Select a Server based on the performance and availability of the Server.

BestAvailableRule

Services that are in the breaker trip state due to multiple access failures are filtered out and the service with the least concurrency is selected.

RandomRule

Randomly select services.

Using ThreadLocalRandom. Current (). NextInt (serverCount); Random selection.

RetryRule

Obtain services based on the RoundRobinRule(round rule) policy. If the failed service is obtained, the system tries again at a specified time to obtain available services.

User-defined load balancing algorithm

The customized load balancing algorithm consists of three steps:

  1. Implement the IRule interface or extend the AbstractLoadBalancerRule class

  2. Override the choose method

  3. Specify a custom load balancing policy algorithm class

First we create a MyRule class, but this class should not be left lying around.

The documentation warns that this custom class cannot be placed in the current and sub-packages that @ComponentScan scans, otherwise our custom configuration class will be shared by all Ribbon clients, and we will not be able to use it for the special purpose.

MyRule

Next, customize a load balancing policy algorithm MyRule_CustomAlgorithm.

Define the algorithm: each service node is called three times, with the following code

​

You can use a customized load balancing policy as follows:

First, add directly to the startup class

Name refers to the service name, and Configuration refers to the custom algorithm class.

Second, specify a custom load balancing algorithm class in the configuration file.

ServerList

ServerList Component used to obtain and store the list of service nodes.

Storage is classified into static storage and dynamic storage.

By default, the service node list is retrieved from the configuration file and stored as static storage.

Obtaining the corresponding service instance information from the registry and storing it is called dynamic storage.

ServerListFilter

ServerListFilter Is used to filter the service instance list. The server returns the filtered service instance list based on the incoming service instance list.

ServerListUpdater

ServerListUpdater is a list updater that dynamically updates the list of services.

ServerListUpdater periodically implements update operations through task scheduling. So it has a unique implementation subclass: PollingServerListUpdater.

Updater PollingServerListUpdater dynamic server list to update the default implementation, using a task scheduler ScheduledThreadPoolExecutor complete update regularly.

IPing

The cached service instance information may no longer be available. In this case, a detection component is required to check whether the service instance information is available.

IPing is used by the client to quickly check whether the server is active at that time (heartbeat detection).

ILoadBalancer

ILoadBalancer is one of the most important links in the Ribbon. ILoadBalancer is the core resource of the load balancer, that is, the acquisition, update, filtering, and selection of all services.

ServerListUpdater dynamically updates a list of services using ServerListUpdater. The ServerListUpdater dynamically updates a list of services using ServerListUpdater. Remove non-viable service nodes by IPing and select a service from the list of existing servers based on IRule.

The Ribbon selects a detailed flow of available services

According to the figure above, the process is as follows:

  1. Get the service node list information from the configuration file or registry through ServerList.

  2. In some cases we may need to filter the list of service nodes by specified policies through ServerListFilter.

  3. To avoid having to go to the registry or configuration file every time to get the service node information, we will save the filtered service list information to local memory. At this time, if a new service node is added or some services are offline, we need to use ServerListUpdater to dynamically update the service list.

  4. When some service nodes are no longer able to provide services, we will remove the services through IPing (heartbeat detection).

  5. Finally, the ILoadBalancer interface selects a service from the service list using the load balancing algorithm specified by IRule.

How the Ribbon is used

Generally speaking, there are three ways to use the Ribbon

First, the way to use native apis

First we create a RibbonClient project. Then we create a RibbonTest class:

RibbonTest

Start the project, visit http://localhost:8008/ribbon/test, run the results are as follows:

Because the IRule we set is a random policy, we see the result of accessing the service address randomly from the list of services.

Second, when we integrate Spring-Cloud, we can use Ribbon + RestTemplate for load balancing.

Because we want to select a service to call through the Ribbon + RestTemplate with the specified load balancing policy, we will first create an OrderService OrderService.

First we add configuration information to the configuration file.

Next, create an OrderController

Finally, we annotate the startup class with @enableeurekaclient;

The code section is complete, and then we start the EurekaServer service that we built in the previous article.

After successful startup, we visit http://localhost:8761/ and the result is as follows, we find that there are services registered to the Eureka registry at this time.

Then we configure the three ports 7777,8888,9999 respectively in the figure below to start.

Then we refresh the previously opened http://localhost:8761/ page, we found that there are three services named order-service, port number 7777,8888,9999 respectively registered:

Now that the services are set up, we need to use the Ribbon+RestTemplate to retrieve the list of services from the Eureka registry and access the specified service nodes through load balancing policies.

For the first step, we still use the RibbonClient project. We create a RestTemplateConfig class to configure the RestTemplate instance.

RestTemplateConfig

For those of you with a sharp eye, we have added a @loadBalanced annotation. With this annotation, we do not need to use IP+ port to call the service. We can use the service name and load balancing function to call the service.

Finally, we modified the RibbonTest code:

At last, we started the RibbonClient project. Since the load balancing strategy was not set, the polling strategy was used to schedule the service by default.

After the success of the project launch, we visit http://localhost:8008/ribbon/test, refresh the page three times, we visit the result, in turn, are as follows:

You may not be in my order, but it must be a three-port loop.

The third way is to use the Ribbon+Fegin. There will be a special article on this method.

The Ribbon is agily-load mode

When we finished building the SpringCloud microservice, we often had a problem: when our service consumer called the service provider interface, the first request often timed out, and there was no problem with the next call.

Why is that?

The main reason is that the Ribbon load balancing Client is not initialized when the service is started. The Client is created during the call. Therefore, the time of the first call includes not only the time of sending the HTTP request, but also the time of creating the RibbonClient. If the creation time is slow and the timeout time is short, it is easy to have request timeout problems.

The solution

Since the reason for the timeout is that RibbonClient needs to be created during the first call, can we create RibbonClient in advance?

If we can think of it, SpringCloud developers can think of it, too.

So we can create RibbonClient ahead of time by setting the following two properties:

Ribbon summary

This article introduces the usage scenarios of the Ribbon and the differences between the Ribbon and Nginx. Starting with the overall architecture of the Ribbon, it introduces in detail the five major components of the Ribbon: IRule, IPing, ServerList, ServerListFilter. ServerListUpdater. And a detailed description of the load balancer’s core interface ILoadBalancer. How the Ribbon is used and the Ribbon’s hunger loading mode.

Ribbon load balancing is an integral part of the SpringCloud ecosystem and a frequently asked interview question.

Original is not easy, if you like, rewardShare the likes on watchThree even. To be the best in the world with everyone else.