Ribbon of Netflix source code analysis: design and implementation of client-side load balancer Ribbon

1. Basic functional requirements of LB

Think about how an LB works, whether it is hardware or software, what capabilities we require it to have, and come up with the most concise list of requirements: it seems that there are only two that can be thought of:

  • ?Set the list of services (servers) for adding and reading backends
  • Can choose a service (server)

Netflix's LoadBalancer is also called for. Requested by ILoadBalancer.

iloadbalancer_outline

It can be seen that the main ones are: correspondingly configure the back-end service; read the back-end service; mark a service as unavailable; of course, the most important thing is to choose a back-end service to provide the service.

This is the method list of version 2.1.0. The starting version of 2.1.3 is to divide getServerList (boolean availableOnly) into two getReachableServers and getAllServers (the explanation is in favor of the cleaner), one is divided into two, has it been cleaned, it seems to be one Dot. One is to get all backend servers, and the other is to return only available backend servers.

2 main implementation

Observe the most basic implementation class of ILoadBalancer com.netflix.loadbalancer.BaseLoadBalancer to understand the main behavior. The main implementation of LB is in it, DynamicServerListLoadBalancer and ZoneAwareLoadBalancer just extend his functions.

iloadbalancer_class_inhereriate

Although the default provided from the ribbon is a ZoneAwareLoadBalancer LB.

3 Main Components

You can see several important attributes (tools) contained in an LB, and it is these tools that provide support for the functions of the LB. they are:

IRule Load balancing strategy, which can be plug-in to provide various applicable load balancing algorithms for LB
Iping ?Determine whether the target service is alive or not corresponds to different protocols and different ways to detect to get whether the back-end service is alive. If there is http, and NIWSDiscoveryPing for service survival in the microservice framework is obtained through the information in the instanceinfo obtained by the eureka client.
LoadBalancerStats The LB operation information records the real-time operation information of the LB, and these operation information can be used as the input of the LB policy.

Observe the next few main methods. The first is the most important service selection method:

A little disappointed, there is nothing, except for a count, just one sentence, you can see that this function is delegated to the included load balancing policy rule to achieve. Different behavior of LB can be achieved by using the choose method of different load balancing strategies, which will be introduced in another article .

Others are nothing special. The service list of the maintenance backend implements the getServerList and addServers methods as follows:

 

Regarding the use of IPing, a timer is started when the LB is initialized to pingIntervalSeconds according to the configured period, and the configured IPing mode class is used to determine which backend servers are unavailable.

Another important point is that the important logic used in IRule and IPing two LBs can be dynamically generated by configuring a class name in the configuration.

This is also the most flexible part of LB. Users can write a ping method according to their own server's protocol and judgment criteria. For example, the ribbon provides the common http ping, and also provides NIWSDiscoveryPing for service survival in the microservice framework, and obtains the status of the service through the information in the instanceinfo obtained by the eureka client. Of course, what is more commonly used is that the user needs to write a load balancing strategy suitable for the application scenario. This will be explained in detail in another article .

4 Server backend service

The description of Ribbon's backend service is encapsulated in com.netflix.loadbalancer.Server, and the main information is two host and port. But the implementation looks more complicated than this. I see that the implementation of such an internal interface is defined in it.

How come there is still getServiceIdForDiscovery? Look at the subclass of Server, com.netflix.niws.loadbalancer.DiscoveryEnabledServer, and you should understand it all.

When you see the referenced com.netflix.appinfo.InstanceInfo, you can understand that the service here is exactly the service discovered and registered by eureka. Ribbon, as a general client load balancing, only needs to forward the request to a host+port, but In the microservice framework of netflix, the backend commonly used by ribbon is the service registered in the service framework. Can you guess what the ASG of getASGName means? AWS Service Group? How to say something about aws.

over.

Original article. In order to maintain a consistent, up-to-date and traceable version of the article, please indicate when reprinting: Reprinted from idouba

The link address of this article: Ribbon of Netflix source code analysis: the design and implementation of the client-side load balancer Ribbon

Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=327046400&siteId=291194637