好运一分快三_一分快三APP下载_Spring Clould负载均衡重要组件:Ribbon中重要类的用法

  • 时间:
  • 浏览:7

    Ribbon是Spring Cloud Netflix全家桶中负责负载均衡的组件,它是一组类库的集合。通过Ribbon,线程池池员能在不涉及到具体实现细节的基础上“透明”地用到负载均衡,而从不在项目里太多地编写实现负载均衡的代码。

    比如,在某个饱含Eureka和Ribbon的集群中,某个服务(都并能 理解成有一一3个 jar包)被部署在多台服务器上,当多个服务使用者并肩调用该服务时,哪些并发的请求能被用本身合理的策略转发到各台服务器上。

    事实上,在使用Spring Cloud的其它各种组件时,让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 都能看完Ribbon的痕迹,比如Eureka能和Ribbon整合,而在后文里将提到的提供网关功能Zuul组件在转发请求时,也都并能 整合Ribbon从而达到负载均衡的效果。

    从代码层面来看,Ribbon有如下有一一3个 比较重要的接口。

    第一,ILoadBalancer,这也叫负载均衡器,通过它,让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 能在项目里根据特定的规则合理地转发请求,常见的实现类有BaseLoadBalancer。

    第二,IRule,这俩 接口有多个实现类,比如RandomRule和RoundRobinRule,哪些实现类具体地定义了诸如“随机“和”轮询“等的负载均衡策略,让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 还能重写该接口里的法律办法来自定义负载均衡的策略。

在BaseLoadBalancer类里,让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 能通过IRule的实现类设置负载均衡的策略,原先 该负载均衡器就能据此合理地转发请求。

    第三,IPing接口,通过该接口,让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 能获取到当前哪些服务器是可用的,让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 并能通过重写该接口里的法律办法来自定义判断服务器不是可用的规则。在BaseLoadBalancer类里,让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 同样能通过IPing的实现类设置判断服务器不是可用的策略。    

1 ILoadBalancer:负载均衡器接口

    在Ribbon里,让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 还都并能 通过ILOadBalancer这俩 接口以基于特定的负载均衡策略来选泽服务器。

    通过下面的ILoadBalancerDemo.java,让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 来看下这俩 接口的基本用法。这俩 类是倒进4.2帕累托图创建的RabbionBasicDemo项目里,代码如下。    

1    //省略必要的package和import代码
2    public class ILoadBalancerDemo {
3        public static void main(String[] args){
4            //创建ILoadBalancer的对象 
5             ILoadBalancer loadBalancer = new BaseLoadBalancer();
6            //定义有一一3个

服务器列表
7               List<Server> myServers = new ArrayList<Server>();
8            //创建有一一3个

Server对象
9            Server s1 = new Server("ekserver1",10001000);
10             Server s2 = new Server("ekserver2",10001000);
11            //有一一3个

server对象倒进List类型的myServers对象里   
12             myServers.add(s1);
13             myServers.add(s2);
14            //把myServers倒进负载均衡器
15            loadBalancer.addServers(myServers);
16            //在for循环里发起10次调用
17            for(int i=0;i<10;i++){
18             //用基于默认的负载均衡规则获得Server类型的对象
19                Server s = loadBalancer.chooseServer("default");
20             //输出IP地址和端口号
21                System.out.println(s.getHost() + ":" + s.getPort());
22            }        
23       }
24    }

     在第5行里,让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 创建了BaseLoadBalancer类型的loadBalancer对象,而BaseLoadBalancer是负载均衡器ILoadBalancer接口的实现类。

    在第6到第13行里,让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 创建了有一一3个 Server类型的对象,并把它们倒进了myServers里,在第15行里,让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 把List类型的myServers对象倒进了负载均衡器里。

    在第17到22行的for循环里,让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 通过负载均衡器模拟了10次选泽服务器的动作,具体而言,是在第19行里,通过loadBalancer的chooseServer法律办法以默认的负载均衡规则选泽服务器,在第21行里,让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 是用“打印”这俩 动作来模拟实际的“使用Server对象防止请求”的动作。

    上述代码的运行结果如下所示,其中让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 能看完,loadBalancer这俩 负载均衡器把10次请求均摊到了2台服务器上,从中觉得能看完 “负载均衡”的效果。

    第二,IRule,这俩 接口有多个实现类,比如RandomRule和RoundRobinRule,哪些实现类具体地定义了诸如“随机“和”轮询“等的负载均衡策略,让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 还能重写该接口里的法律办法来自定义负载均衡的策略。

    在BaseLoadBalancer类里,让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 能通过IRule的实现类设置负载均衡的策略,原先 该负载均衡器就能据此合理地转发请求。

    第三,IPing接口,通过该接口,让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 能获取到当前哪些服务器是可用的,让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 并能通过重写该接口里的法律办法来自定义判断服务器不是可用的规则。在BaseLoadBalancer类里,让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 同样能通过IPing的实现类设置判断服务器不是可用的策略。  

1    ekserver2:10001000
2    ekserver1:10001000
3    ekserver2:10001000
4    ekserver1:10001000
5    ekserver2:10001000
6    ekserver1:10001000
7    ekserver2:10001000
8    ekserver1:10001000
9    ekserver2:10001000
10   ekserver1:10001000

2 IRule:定义负载均衡规则的接口

    在Ribbon里,让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 都并能 通过定义IRule接口的实现类来给负载均衡器设置相应的规则。在下表里,让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 能看完IRule接口的这俩 常用的实现类。

实现类的名字

负载均衡的规则

RandomRule

采用随机选泽的策略

RoundRobinRule

采用轮询策略

RetryRule

采用该策略时,会饱含重试动作

AvailabilityFilterRule

会过滤些多次连接失败和请求并发数过低的服务器

WeightedResponseTimeRule

根据平均响应时间为每个服务器设置有一一3个 权重,根据该权重值优先选泽平均响应时间较小的服务器

ZoneAvoidanceRule

优先把请求分配到和该请求具有相同区域(Zone)的服务器上

    在下面的IRuleDemo.java的线程池池里,让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 来看下IRule的基本用法。

1    //省略必要的package和import代码
2    public class IRuleDemo {
3        public static void main(String[] args){
4        //请注意这是用到的是BaseLoadBalancer,而不是ILoadBalancer接口
5        BaseLoadBalancer loadBalancer = new BaseLoadBalancer();
6            //声明基于轮询的负载均衡策略
7            IRule rule = new RoundRobinRule();
8        //在负载均衡器里设置策略 
9            loadBalancer.setRule(rule);
10            //如下定义3个Server,并把它们倒进List类型的集合中
11            List<Server> myServers = new ArrayList<Server>();
12            Server s1 = new Server("ekserver1",10001000);
13            Server s2 = new Server("ekserver2",10001000);
14            Server s3 = new Server("ekserver3",10001000);
15            myServers.add(s1);
16            myServers.add(s2);
17            myServers.add(s3);
18            //在负载均衡器里设置服务器的List
19            loadBalancer.addServers(myServers);
20            //输出负载均衡的结果
21            for(int i=0;i<10;i++){
22                Server s = loadBalancer.chooseServer(null);
23                System.out.println(s.getHost() + ":" + s.getPort());    
24          }        
25        }
26    }

    这段代码和上文里的ILoadBalancerDemo.java很这俩,但有如下的差别点。

    1 在第5行里,让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 是通过BaseLoadBalancer这俩 类而不是接口来定义负载均衡器,是因为是该类饱含setRule法律办法。

    2 在第7行定义了有一一3个 基于轮询规则的rule对象,并在第9行里把它设置进负载均衡器。

    3 在第19行里,让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 是把饱含3个Server的List对象倒进负载均衡器,而不是原先 的有一一3个 。机会这里存粹是为了演示效果,太多让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 就倒进有一一3个 根本不占据 的“ekserver3”服务器。

    运行该线程池池后,让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 都并能 看完有10次输出,可是我 觉得是按“轮询”的规则有顺序地输出3个服务器的名字。机会让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 把第7行的代码改成如下,这么就会看完 “随机”地输出服务器名。

    IRule rule = new RandomRule();

3  IPing:判断服务器不是可用的接口

    在项目里,让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 一般会让ILoadBalancer接口自动地判断服务器不是可用(哪些业务都封装进 Ribbon的底层代码里),此外,让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 还都并能 用Ribbon组件里的IPing接口来实现这俩 功能。

    在下面的IRuleDemo.java代码里,让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 将演示IPing接口的一般用法。    

1    //省略必要的package和import代码
2    class MyPing implements IPing {
3        public boolean isAlive(Server server) {
4             //机会服务器名是ekserver2,则返回false
5            if (server.getHost().equals("ekserver2")) {
6                return false;
7            }
8            return true;
9        }
10    }

    第2行定义的MyPing类实现了IPing接口,并在第3行重写了其中的isAlive法律办法。

    在这俩 法律办法里,让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 根据服务器名来判断,具体而言,机会名字是ekserver2,则返回false,表示该服务器不可用,可是我 返回true,表示当前服务器可用。     

11    public class IRuleDemo {
12        public static void main(String[] args) {
13            BaseLoadBalancer loadBalancer = new BaseLoadBalancer();
14            //定义IPing类型的myPing对象
15            IPing myPing = new MyPing(); 
16             //在负载均衡器里使用myPing对象
17            loadBalancer.setPing(myPing);
18             //同样是创建有一一3个

Server对象并倒进负载均衡器
19            List<Server> myServers = new ArrayList<Server>();
20            Server s1 = new Server("ekserver1", 10001000);
21            Server s2 = new Server("ekserver2", 10001000);
22            Server s3 = new Server("ekserver3", 10001000);
23            myServers.add(s1);
24            myServers.add(s2);
25            myServers.add(s3);
26            loadBalancer.addServers(myServers);
27             //通过for循环多次请求服务器 
28            for (int i = 0; i < 10; i++) {
29                Server s = loadBalancer.chooseServer(null);
1000                System.out.println(s.getHost() + ":" + s.getPort());
31            }
32        }
33    }

    在第12行的main函数里,让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 在第15行创建了IPing类型的myPing对象,并在第17行把这俩 对象倒进了负载均衡器。通过第18到第26行的代码,让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 创建了有一一3个 服务器,并把它们也倒进负载均衡器。

    在第28行的for循环里,让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 依然是请求并输出服务器名。机会这里的负载均衡器loadBalancer中饱含了有一一3个 IPing类型的对象,太多在根据策略得到服务器后,会根据myPing里的isActive法律办法来判断该服务器不是可用。

    机会在这俩 法律办法里,让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 定义了ekServer2这台服务器不可用,太多负载均衡器loadBalancer对象始终不需要把请求发送到该服务器上,也可是我说,在输出结果中,让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 不需要看完“ekserver2:10001000”的输出。

    从中让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 能看完IPing接口的一般用法,让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 都并能 通过重写其中的isAlive法律办法来定义“判断服务器不是可用“的逻辑,在实际项目里,判断的法律办法无非是”服务器响应不是时间过长“或”发往该服务器的请求数不是太多“,而哪些判断法律办法都封装进 IRule接口以及它的实现类里,太多在一般的场景中让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 让我们歌词 歌词 用到IPing接口。

4  预告&版权申明

     在本周的底下时间里,我将继续给出用Eureka+Ribbon高可用负载均衡架构的搭建法律办法。

     本文内容摘自买车人写的专业书籍,转载时请并肩引入该版权申明,请勿用于商业用途。