Spring Cloud Netflix Ribbon Detailed introduction and custom rule policies

Earlier in this article we described how to configure a consumer with a load balancing strategy with the Ribbon polling mechanism, this time to learn more about the details of the ribbon, and how to customize the load balancing strategy.

Talk about the general idea of the ribbon for load balancing. It is configured by the Ribbon by modifying the resttemplate with @loadbalanced, defining an interceptor for resttemplate, intercepting the rest request, and sending it to the ribbon for processing. The Ribbon is primarily responsible for selecting the appropriate instance and constructing the URL. (specifically not analyzed, interested can look at the loadbalancerautoconfiguration,loadbalancerinterceptor,loadbalancerclient several classes).

Let's take a look at some of the important interfaces we might use here.

Iloadbalancer:ribbon Load Balancer Interface, defines the addition of service instances, selects service instances, flags service instances offline, obtains the currently available instances, and obtains all service instance methods. Through the method definition, we can see that this class is the most important management class of the Ribbon. It manages the instance and chooses the appropriate instance to return by acquiring the load balancing policy in the instance method. It mainly involves Abstractloadbalancer implementation interface, and defines some basic methods.

1. Baseloadbalancer: Inheriting Abstractloadbalancer, a load balancer's underlying implementation class, there are several places to note: IPing (the way to detect instance state) objects are not implemented, are empty, need to be passed in at construction time, The default policy for checking instance state is Serialpingstrategy, which uses incoming rules, polling instances to check their status, and performance issues if the network is bad or there are too many instances. Check policies can also be customized for incoming. Defines the Irule object, which is primarily used to define a load balancing policy, and iloadbalancer passes itself through the constructor to irule,irule through the Choose function to obtain serverlist and returns a server under the rule. The default irule for this equalizer is Roundrobinrule, which is returned by the policy for a linear polling service instance.
2. Nooploadbalancer, this class inherited Abstractloadbalancer, from the name can be seen, anyway is nothing to do ...
3. Dynamicserverlistloadbalancer, inherits Baseloadbalancer, realizes the ability of the service list to update dynamically during running, and has the function of service list filtering. Everyone can see for themselves, I did not look at >_<.
4. Zoneawareloadbalancer, inherited Dynamicserverlistloadbalancer, functionally is the most perfect, the most powerful, because Dynamicserverlistloadbalancer uses polling method to invoke instances, In the case of different areas, there may be network latency and other conditions affecting performance, so there is a zoneawareloadbalancer, it has regional affinity, will prefer the same region of the instance. It uses Zoneavoidancerule as a load balancing policy.

IRule: Load Balancing Policy interface

1. Abstractloadbalancerrule, a number of basic methods have been implemented. Defines the Iloadbalancer object.
2. Randomrule: Random selection strategy.
3. Roundrobinrule: Linear Polling policy
4. Retryrule: The internal definition of another wheel-line strategy, with the judge to determine if the instance selection detection is alive, not alive, polling select the remaining instances, and determine the status of the instance, also set the timeout function, within a specified time, can not select the available instance, then return null.
5. Weightedresponsetimerule: The extension of the Roundrobinrule, which defines an algorithm to calculate the weight of the instance, the weight and the instance response time, anyway, the final effect is a short response time is easier to choose.
6. Clientconfigenabledroundrobinrule: Implementations are consistent with roundrobinrule and are used by other classes to extend by inheriting it.
7. Bestavailablerule inherits from Clientconfigenabledroundrobinrule, which iterates through all instances, filters the failed instances, and finds the one instance with the fewest concurrent requests returned. Who is the most busy to find who to work.
8. Predicatebasedrule: The rule first implements filtering (a certain instance is not a fault, and a more idle algorithm), and then traverses to find an instance. (This does not understand).
9. Availabilityfilteringrule: Inherits the Predicatebasedrule, walks directly the instance, according to the rule, finds a suitable instance to return.
10. Zoneavoidancerule: Inherit Predicatebasedrule, with the strategy of region affinity, first filter out the instance of the same region by region, then select an instance. If there are no instances of the same region, the other instances are traversed linearly.

　　

　　

　　

IPing: An interface to detect if an instance is available

1. Abstractloadbalancerping: Implements Iping, defines Abstractloadbalancer.
2. Noopping: Implements Iping, which returns true, indicating that all instances of the default are available.
3. Dummyping: Returns True by default and constructs a Initwithniwsconfig null method, which should be used to provide the developer with a class that inherits the implementation itself.
4. Niwsdiscoveryping: This is used in conjunction with Eureka, with the instance status of the registry managed, and the instance with the status up returned as available.
5. Pingconstant: Implement Iping, you can set the state of the current or all instances by setconstant.
6. Pingurl: Implement Iping, by sending an HTTP request to determine whether the status of the return value of the instance code is 200, to determine whether the instance is alive. The default address is an HTTP or IP: port, which can be setpingappendstring to the IP and then stitching the characters to form an address.

The above three interfaces are the main interface of the Ribbon, the rest of the interface is not introduced here.

The following is the default interface used by the Ribbon, note that after integration with the Eureka, the interface changes somewhat.

1. Iloadbalancer, with the zoneawareloadbalancer.
2. IRule, with the zoneavoidancerule.
3. IPing, with the noopping, by default can be
4. Serverlist<server>, using the configurationbasedserverlist, to configure the instance list to configure the way: <servername>. ribbon.listofservers=localhost:8001,localhost:8002, localhost:8003
5. Serverlistfilter<server>, default to filter instances of the same region using Zonepreferenceserverlistfilter.
6. Iclientconfig,ribbon client configuration, using Defaultclientconfigimpl by default

After integration with Eureka, the interface instance uses the following changes:

1. Serverlist<server>, replaced by Discoveryenabledniwsserverlist. This class implements the management of the list of service instance manifests to be maintained by Eureka's registry. Indicates that the ribbon gets a list of services directly from the Eureka Registry.
2. Iping is replaced by. Niwsdiscoveryping, which indicates that the status of the instance is maintained by the Eureka Registry, and the instance in the registry list is returned as available in the up state.

After this introduction, let's look at how to customize the implementation classes for these policies. You can also do this if you want to implement these interfaces.

By looking at the Ribbon source code, find the following class, which defines the fields of these configurations in its constructors.

 public   Propertiesfactory () { Classtoproperty.put (iloadbalancer.         class , "Nfloadbalancerclassname"         class , "Nfloadbalancerpingclassname"         class , "Nfloadbalancerruleclassname"         class , "Niwsserverlistclassname"     class , "Niwsserverlistfilterclassname" 

As we can see, it supports the implementation class configuration of 5 interfaces. For example: Through <servername>.ribbon.nfloadbalancerruleclassname=com.netflix.loadbalancer.randomrule, configure the servername load balancing policy to select instances randomly. A configuration without a service name indicates a global effect. Good Dalat, finished, pro-test effective Oh, you can try to customize their load-balanced configuration!