Explain in detail the usage of important classes in the ribbon, an important component of spring cloud load balancing

Ribbon is a component responsible for load balancing in spring cloud Netflix. It is a collection of class libraries. Through ribbon, programmers can "transparently" use load balancing without involving specific implementation details, and do not have to write too much code to realize load balancing in the project.

For example, in a cluster containing Eureka and ribbon, a service (which can be understood as a jar package) is deployed on multiple servers. When multiple service consumers call the service at the same time, these concurrent requests can be forwarded to each server with a reasonable strategy.

In fact, when using other components of spring cloud, we can see the traces of ribbon. For example, Eureka can integrate with ribbon, and the zuul component that provides gateway function mentioned later can also integrate ribbon when forwarding requests, so as to achieve the effect of load balancing.

From the code level, ribbon has the following three important interfaces.

First, iloadbalancer, also known as load balancer, enables us to forward requests reasonably according to specific rules in the project. The common implementation class is baseloadbalancer.

Second, iRule. This interface has multiple implementation classes, such as randomrule and roundrobin rule. These implementation classes specifically define load balancing policies such as "random" and "polling". We can also rewrite the methods in this interface to define load balancing policies.

In the baseloadbalancer class, we can set the load balancing policy through the implementation class of iRule, so that the load balancer can forward requests reasonably.

Third, the iping interface. Through this interface, we can obtain which servers are currently available, and we can also customize the rules to judge whether the server is available by rewriting the methods in this interface. In the baseloadbalancer class, we can also set the policy to judge whether the server is available through the implementation class of iping.

1 iloadbalancer: load balancer interface

In the ribbon, we can also select servers based on specific load balancing policies through the iloadbalancer interface.

Through the following iloadbalancerdemo Java, let's look at the basic usage of this interface. This class is placed in the rabionbasicdemo project created in part 4.2. The code is as follows.

In line 5, we create a loadbalancer object of type baseloadbalancer, which is the implementation class of the load balancer iloadbalancer interface.

In lines 6 to 13, we create two server type objects and put them into myservers. In line 15, we put the list type myservers object into the load balancer.

In the for loop from lines 17 to 22, we simulated the action of selecting the server 10 times through the load balancer. Specifically, in line 19, we selected the server according to the default load balancing rules through the chooseserver method of the loadbalancer. In line 21, we simulated the actual action of "using the server object to process the request" with the action of "print".

The running results of the above code are as follows. We can see that the load balancer distributes 10 requests equally to two servers, from which we can really see the effect of "load balancing".

Second, iRule. This interface has multiple implementation classes, such as randomrule and roundrobin rule. These implementation classes specifically define load balancing policies such as "random" and "polling". We can also rewrite the methods in this interface to define load balancing policies.

In the baseloadbalancer class, we can set the load balancing policy through the implementation class of iRule, so that the load balancer can forward requests reasonably.

Third, the iping interface. Through this interface, we can obtain which servers are currently available, and we can also customize the rules to judge whether the server is available by rewriting the methods in this interface. In the baseloadbalancer class, we can also set the policy to judge whether the server is available through the implementation class of iping.

2 iRule: interface for defining load balancing rules

In the ribbon, we can set corresponding rules for the load balancer by defining the implementation class of the iRule interface. In the following table, we can see some common implementation classes of iRule interface.

In the following iruledemo In the Java program, let's take a look at the basic usage of iRule.

This code is the same as iloadbalancerdemo Java is very similar, but there are the following differences.

1 in line 5, we define the load balancer through the baseloadbalancer class rather than the interface because it contains the setrule method.

2 define a rule object based on polling rules in line 7 and set it into the load balancer in line 9.

3 in line 19, we put the list object containing three servers into the load balancer instead of the previous two. Because the essence here is to demonstrate the effect, we put it into a nonexistent "ekserver3" server.

After running the program, we can see that there are 10 times of output, and the names of three servers are output sequentially according to the "polling" rule. If we change the code in line 7 to the following, we will see that the server name is output "randomly".

3 iping: an interface to determine whether the server is available

In the project, we usually let the iloadbalancer interface automatically judge whether the server is available (these services are encapsulated in the underlying code of ribbon). In addition, we can also use the iping interface in ribbon component to realize this function.

In the following iruledemo In the Java code, we will demonstrate the general usage of the iping interface.

The myping class defined in line 2 implements the iping interface and overrides the isalive method in line 3.

In this method, we judge by the server name. Specifically, if the name is ekserver2, it returns false, indicating that the server is unavailable; otherwise, it returns true, indicating that the current server is available.

In the main function on line 12, we create a myping object of iping type on line 15 and put this object into the load balancer on line 17. Through lines 18 to 26, we created three servers and put them into the load balancer.

In the for loop on line 28, we still request and output the server name. Since the load balancer loadbalancer here contains an iping type object, after obtaining the server according to the policy, it will judge whether the server is available according to the isactive method in myping.

In this method, we define that ekserver2 is unavailable, so the load balancer loadbalancer object will never send requests to the server, that is, we will not see the output of "ekserver2:8080" in the output result.

From this, we can see the general usage of the iping interface, We can rewrite the isalive method to define the logic of "judging whether the server is available". In actual projects, the judgment is based on "whether the server response time is too long" or "whether there are too many requests sent to the server" ", and these judgment methods are encapsulated in the iRule interface and its implementation classes, so we use the iping interface in general scenarios.

The above is the whole content of this article. I hope it will be helpful to your study, and I hope you can support programming tips.