2分pk10套路_Spring Clould负载均衡重要组件:Ribbon中重要类的用法

  • 时间:
  • 浏览:0

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

    比如,在某个蕴含Eureka和Ribbon的集群中,某个服务(都太少 理解成三个 jar包)被部署在多台服务器上,当多个服务使用者一同调用该服务时,那先 并发的请求能被用四种 合理的策略转发到各台服务器上。

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

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

    第一,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            //定义三个

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

Server对象
9            Server s1 = new Server("ekserver1",5050);
10             Server s2 = new Server("ekserver2",5050);
11            //三个

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行里,我们都歌词 我们都歌词 我们都歌词 创建了三个 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:5050
2    ekserver1:5050
3    ekserver2:5050
4    ekserver1:5050
5    ekserver2:5050
6    ekserver1:5050
7    ekserver2:5050
8    ekserver1:5050
9    ekserver2:5050
10   ekserver1:5050

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

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

实现类的名字

负载均衡的规则

RandomRule

采用随机选则的策略

RoundRobinRule

采用轮询策略

RetryRule

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

AvailabilityFilterRule

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

WeightedResponseTimeRule

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

ZoneAvoidanceRule

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

    在下面的IRuleDemo.java的tcp连接里,我们都歌词 我们都歌词 我们都歌词 来看下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            //如下定义三个Server,并把它们放到List类型的集合中
11            List<Server> myServers = new ArrayList<Server>();
12            Server s1 = new Server("ekserver1",5050);
13            Server s2 = new Server("ekserver2",5050);
14            Server s3 = new Server("ekserver3",5050);
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行定义了三个 基于轮询规则的rule对象,并在第9行里把它设置进负载均衡器。

    3 在第19行里,我们都歌词 我们都歌词 我们都歌词 是把蕴含三个Server的List对象放到负载均衡器,而全是以前的三个 。机会这里存粹是为了演示效果,统统统统我们都歌词 我们都歌词 我们都歌词 就放到三个 根本不占据 的“ekserver3”服务器。

    运行该tcp连接后,我们都歌词 我们都歌词 我们都歌词 都太少 都看有10次输出,就让 实在是按“轮询”的规则有顺序地输出三个服务器的名字。机会我们都歌词 我们都歌词 我们都歌词 把第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             //同样是创建三个

Server对象并放到负载均衡器
19            List<Server> myServers = new ArrayList<Server>();
20            Server s1 = new Server("ekserver1", 5050);
21            Server s2 = new Server("ekserver2", 5050);
22            Server s3 = new Server("ekserver3", 5050);
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);
50                System.out.println(s.getHost() + ":" + s.getPort());
31            }
32        }
33    }

    在第12行的main函数里,我们都歌词 我们都歌词 我们都歌词 在第15行创建了IPing类型的myPing对象,并在第17行把统统对象放到了负载均衡器。通过第18到第26行的代码,我们都歌词 我们都歌词 我们都歌词 创建了三个 服务器,并把它们也放到负载均衡器。

    在第28行的for循环里,我们都歌词 我们都歌词 我们都歌词 依然是请求并输出服务器名。机会这里的负载均衡器loadBalancer中蕴含了三个 IPing类型的对象,统统统统在根据策略得到服务器后,会根据myPing里的isActive土方式 来判断该服务器否是可用。

    机会在统统土方式 里,我们都歌词 我们都歌词 我们都歌词 定义了ekServer2这台服务器不可用,统统统统负载均衡器loadBalancer对象始终太少把请求发送到该服务器上,也可是我说,在输出结果中,我们都歌词 我们都歌词 我们都歌词 太少都看“ekserver2:5050”的输出。

    从中我们都歌词 我们都歌词 我们都歌词 能都看IPing接口的一般用法,我们都歌词 我们都歌词 我们都歌词 都太少 通过重写其中的isAlive土方式 来定义“判断服务器否是可用“的逻辑,在实际项目里,判断的土方式 无非是”服务器响应否是时间过长“或”发往该服务器的请求数否是太少 “,而那先 判断土方式 都封放到IRule接口以及它的实现类里,统统统统在一般的场景中我们都歌词 我们都歌词 我们都歌词 用到IPing接口。

4  预告&版权申明

     在本周的上边时间里,我将继续给出用Eureka+Ribbon高可用负载均衡架构的搭建土方式 。

     本文内容摘自另一方写的专业书籍,转载时请一同引入该版权申明,请勿用于商业用途。