Robbin负载均衡

墨蓝 2021-11-23 15:42 182阅读 0赞

Robbin是在Spring Cloud中的一个组件，是由Netfix发布的负载均衡器，有助于控制HTTP和TCP客户端的行为。它给我们提供了默认的轮询、随机等负载均衡算法。同时也可以由我们定义自己的算法。

由于Robbin已经被集成在Eureka里面，因此我们这个样例的代码都是在《[微服务Eureka使用详解][Eureka]》的基础上进行。

参考博客：[https://blog.csdn.net/u013089490/article/details/83786844][https_blog.csdn.net_u013089490_article_details_83786844]、[https://blog.csdn.net/dwhdome/article/details/86477961][https_blog.csdn.net_dwhdome_article_details_86477961]

**负载均衡样例**

（1）我们首先启动好在《微服务Eureka使用详解》中编写的三个服务：服务注册中心，user服务，roles服务。访问Eureka的管理页面可以看到如下内容：

![1117146-20190523105913626-2036705972.png][]

（2）下面我们先来修改User服务（只修改controller）：

@GetMapping("users/{id}")
        public String getUser(@PathVariable("id") String id) {
            String str = "7001User.id" + id;
            System.out.println(str);
            return str;
        }

启动服务，它的端口是7001。

然后再复制一个User项目，将Controller内容调整为如下：

@GetMapping("users/{id}")
        public String getUser(@PathVariable("id") String id) {
            String str = "7002User.id" + id;
            System.out.println(str);
            return str;
        }

以及将配置文件中的端口修改为7002

server.port=7002

启动该应用。

这时我们再查看Eureka服务页面：

![1117146-20190523110530226-259006395.png][]

可以清楚的看到USER服务的可用区域(Availability Zones)已经从（1）变成了（2）。状态（status）已经变成了两个服务地址7001和7002。

（3）Roles服务的负载均衡在《微服务Eureka使用详解》中已经配置过了，我们这里查看一下即可。

@Bean
        @LoadBalanced
        public RestTemplate restTemplate() {
            return new RestTemplate();
        }

（4）访问Roles服务路径~/roles/\{id\}，可用连续多次访问，这里假如我连续访问5次：

/roles/1
    /roles/2
    /roles/3
    /roles/4
    /roles/5

可用看到返回的结果：

7001User.id1
    7002User.id2
    7001User.id3
    7002User.id4
    7001User.id5

两个User服务，7001端口和7002端口是默认处于一个轮询的状态。假设这一次访问7001端口，下一次就访问7002端口，以此类推。

**修改负载均衡策略**

负责负载均衡策略的顶级接口：

com.netflix.loadbalancer.IRule

所有的负责均衡算法均实现了这个接口，它的实现类如下：

![1117146-20190523143841301-1620401491.png][]

默认情况下，使用的是

com.netflix.loadbalancer.RoundRobinRule：以轮询的方式进行负载均衡。

常用的还有

com.netflix.loadbalancer.RandomRule：随机策略

com.netflix.loadbalancer.RetryRule：重试策略。

com.netflix.loadbalancer.WeightedResponseTimeRule：权重策略。会计算每个服务的权重，越高的被调用的可能性越大。

com.netflix.loadbalancer.BestAvailableRule：最佳策略。遍历所有的服务实例，过滤掉故障实例，并返回请求数最小的实例返回。

com.netflix.loadbalancer.AvailabilityFilteringRule：可用过滤策略。过滤掉故障和请求数超过阈值的服务实例，再从剩下的实力中轮询调用。

如果我们要实现自己的策略，可以继承IRule接口，下面我们来以RoundRobinRule为例查看一下如何实现负载均衡策略。

（1）IRule接口

public interface IRule {
    
        // 返回经过负载均衡后最终调用的服务
        Server choose(Object var1);
    
        void setLoadBalancer(ILoadBalancer var1);
    
        ILoadBalancer getLoadBalancer();
    }

（2）RoundRobinRule类

我们先看最重要的choose(Object)方法

public Server choose(Object key) {
            return this.choose(this.getLoadBalancer(), key);
        }

里面调用了我们另一个choose(ILoadBalancer, Object)方法

public Server choose(ILoadBalancer lb, Object key) {
            if (lb == null) {
                log.warn("no load balancer");
                return null;
            } else {
                Server server = null;
                int count = 0;
    
                while(true) {
                    if (server == null && count++ < 10) {
                        List<Server> reachableServers = lb.getReachableServers();
                        List<Server> allServers = lb.getAllServers();
                        int upCount = reachableServers.size();
                        int serverCount = allServers.size();
                        if (upCount != 0 && serverCount != 0) {
                            int nextServerIndex = this.incrementAndGetModulo(serverCount);
                            server = (Server)allServers.get(nextServerIndex);
                            if (server == null) {
                                Thread.yield();
                            } else {
                                if (server.isAlive() && server.isReadyToServe()) {
                                    return server;
                                }
    
                                server = null;
                            }
                            continue;
                        }
    
                        log.warn("No up servers available from load balancer: " + lb);
                        return null;
                    }
    
                    if (count >= 10) {
                        log.warn("No available alive servers after 10 tries from load balancer: " + lb);
                    }
    
                    return server;
                }
            }
        }

在上面的方法中，主要内容是在while(true)内获取下一个server，获取的方法是incrementAndGetModulo(int)。然后根据方法返回的服务下标，从服务集合中找到对应的server，如果server存在且存活，会直接使用这个server。如果server不存在或不存在，则会再循环获取下一个。直到循环10次，或着没有从服务注册中心找到可用的服务，会返回null。

核心的incrementAndGetModulo(int)方法

private int incrementAndGetModulo(int modulo) {
            int current;
            int next;
            do {
                current = this.nextServerCyclicCounter.get(); //nextServerCyclicCounter是AtomicInteger对象，默认值0，可保证线程安全性 
                next = (current + 1) % modulo; //每次往后移一位，取集合中的下一个server。这里要注意的是从1开始，即数组中的第二个server会被第一个调用。
            } while(!this.nextServerCyclicCounter.compareAndSet(current, next)); //操作完成后用CAS操作将next赋值给nextServerCyclicCounter return next;
        }

（3）可用顺便再看一下RetryRule类。

public Server choose(ILoadBalancer lb, Object key) {
            long requestTime = System.currentTimeMillis();
            long deadline = requestTime + this.maxRetryMillis;
            Server answer = null;
            answer = this.subRule.choose(key); //内部仍然是使用了轮询策略。 if ((answer == null || !answer.isAlive()) && System.currentTimeMillis() < deadline) {
                InterruptTask task = new InterruptTask(deadline - System.currentTimeMillis());
    
                while(!Thread.interrupted()) {
                    answer = this.subRule.choose(key);
                    if (answer != null && answer.isAlive() || System.currentTimeMillis() >= deadline) {
                        break;
                    }
    
                    Thread.yield();
                }
    
                task.cancel();
            }
    
            return answer != null && answer.isAlive() ? answer : null;
        }

这个类采用的是重试策略，可以看到里面其实仍是采用了轮询策略，只不过如果轮询的server无法访问，或者不存活，会在指定的时间(500)内一直获取下一个server，直到找到一个存活的server。

**注意：上面所说的故障服务，是由Eureka注册中心来判断。即使服务已经挂掉，但是Eureka的实例未过期，仍会被判断为正常。但是实际的返回可能是null等。**

如果我们要实现自己的负载均衡策略，也可以通过继承IRule接口，在配置文件中进行配置。

转载于:https://www.cnblogs.com/yxth/p/10913295.html

[Eureka]: https://www.cnblogs.com/yxth/p/10845640.html
[https_blog.csdn.net_u013089490_article_details_83786844]: https://blog.csdn.net/u013089490/article/details/83786844
[https_blog.csdn.net_dwhdome_article_details_86477961]: https://blog.csdn.net/dwhdome/article/details/86477961
[1117146-20190523105913626-2036705972.png]: /images/20211122/b3b4ac49de8646b5ae1cce403afbe287.png
[1117146-20190523110530226-259006395.png]: /images/20211122/1dd3571e6828431698b68f4795e845b3.png
[1117146-20190523143841301-1620401491.png]: /images/20211122/617d7244eef34d839e33dbeb28459bef.png