负载均衡

负载均衡(Load Balance)是集群技术（Cluster）的一种应用。负载均衡可以将工作任务分摊到多个处理单元，从而提高并发处理能力，如果有服务down掉，分担请求到其他服务，增加系统的健壮性。

大家熟知的nginx可以实现负载均衡，除他之外，常用的SOA（面向服务的架构）框架Dubbo和Spring Cloud也有负载均衡策略，他们有什么不同呢，下面来看一下

nginx实现负载均衡，是把请求拦到后台服务之前，根据配置的策略选择后台服务，再进行分发；

轮询分派
upstream loop{
    server 127.0.0.1:8080
    server 127.0.0.1:7080
    server 127.0.0.1:6305
}
按照默认轮询的方式进行负载，
假设后端server down掉，能自己剔除。
缺点：可靠性地，负载不均衡，机器性能可能不一致

权重分派
upstream loopweight{
    server 127.0.0.1:8080 weight = 5;
    server 127.0.0.2:7080 weight = 5;
    server 127.0.0.3:6305 weight = 10;
}
考虑1和2的机器配置低，或者1和2的性能不如3的时候
这样将3的权重设置大一些，更多的请求会被分配到3上。
为1和2分担更多的请求。

IP哈希
upstream iphash{
    ip_hash;
    server 127.0.0.1:8080;
    server 127.0.0.2:7080;
    server 127.0.0.3:6305;
}
这里的IP说的是客户端的出口IP，这样经过 des_server_ip = hash(ip)
相应的ip在没有down掉的情况下，肯定会hash到固定的ip上。

URL哈希
upstream urlhash{
    server 127.0.0.1:8080;
    server 127.0.0.2:7080;
    server 127.0.0.3:6305;
    hash $request_uri;
    hash_method crc32;
}
按照URI进行哈希，固定的URI Hash到固定的server上。

性能，响应时间分派
upstream iphash{
    server 127.0.0.1:8080;
    server 127.0.0.2:7080;
    server 127.0.0.3:6305;
    fair;
}
按后端服务器的响应时间来分配请求。响应时间短的优先分配。

down And backup
    upstream iphash{
        server 127.0.0.1:8080 down; #当前server不参与负载
        server 127.0.0.2:7080;
        server 127.0.0.3:6305 backup; #非backup的机器(参与负载的机器)，down掉或者忙的时候，请求backup机器。备用机
        fair;
    }

应用
listen 80;
server_name www.domain.com
location ~^ /api{
    proxy_pass http://loopweight    #选择一种你喜欢的负载策略
 

Dubbo的负载均衡是将服务消费者的请求，按策略分配到服务提供者，此时请求已经进入到后台服务；

Dubbo 提供了多种均衡策略，默认为 random 随机调用。可以自行扩展负载均衡策略

Random LoadBalance(默认，基于权重的随机负载均衡机制)

随机，按权重设置随机概率。
在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。

RoundRobin LoadBalance(不推荐，基于权重的轮询负载均衡机制)

轮循，按公约后的权重设置轮循比率。
存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。

LeastActive LoadBalance

最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。
使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。

ConsistentHash LoadBalance

一致性 Hash，相同参数的请求总是发到同一提供者。(如果你需要的不是随机负载均衡，是要一类请求都到一个节点，那就走这个一致性hash策略。)
当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。

配置方式
xml 配置方式

服务端服务级别

<dubbo:service interface="..." loadbalance="roundrobin" />
客户端服务级别

<dubbo:reference interface="..." loadbalance="roundrobin" />
服务端方法级别

<dubbo:service interface="...">
    <dubbo:method name="..." loadbalance="roundrobin"/>
</dubbo:service>
客户端方法级别

<dubbo:reference interface="...">
    <dubbo:method name="..." loadbalance="roundrobin"/>
</dubbo:reference>

注解配置方式：

消费方基于注解的服务级别配置方式：

@Reference(loadbalance = "roundrobin")
HelloService helloService;
 

Spring cloud负载均衡之Ribbon

Ribbon 是运行在消费者端的负载均衡器，其工作原理就是 Consumer 端获取到了所有的服务列表之后，在其内部使用负载均衡算法，进行对多个系统的调用，此时请求已经到达后台服务；

 Ribbon默认使用的是RoundRobinRule 轮询策略。

• RoundRobinRule：轮询策略。Ribbon 默认采用的策略。若经过一轮轮询没有找到可用的 provider，其最多轮询 10 轮。若最终还没有找到，则返回 null。
• RandomRule: 随机策略，从所有可用的 provider 中随机选择一个。
• RetryRule: 重试策略。先按照 RoundRobinRule 策略获取 provider，若获取失败，则在指定的时限内重试。默认的时限为 500 毫秒。

• BestAvailableRule：最大可用策略，即先过滤出故障服务实例后，选择一个当前并发请求数最小的。

• WeightedResponseTimeRule：带有加权的轮询策略，对各个服务实例响应时间进行加权处理，然后再采用轮询的方式获取相应的服务实例。

• AvailabilityFilteringRule：可用过滤策略，先过滤出有故障的或并发请求大于阈值的一部分服务实例，然后再以线性轮询的方式从过滤后的实例清单中选择一个。

• ZoneAvoidanceRule：区域感知策略，先使用主过滤条件（区域负载器，选择最优区域）对所有实例过滤并返回过滤后的实例，依次使用次过滤条件列表中的过滤条件对主过滤条件的结果进行过滤，判断最小过滤数和最小过滤百分比，最后对满足条件的服务实例使用轮询方式。

配置文件配置方式

 

 

 总结：nginx、dubbo、spring cloud都可以实现负载均衡，但是策略不同，负载的层面也不同，nginx是把服务统一拦截到后台服务之前，根据策略把请求分配到后台服务，而dubbo和spring cloud是对服务消费请求进行分配，分配到服务生产者那里。