Ribbon负载均衡

1. 集中式负载均衡

在客户端和服务端之间使用独立的负载均衡设施(可以是硬件，如F5, 也可以是软件，如nginx、LVS等), 由该设施负责把访问请求通过某种策略转发至服务端。

2. 进程内负载均衡

将负载均衡逻辑集成到客户端组件中，客户端组件从服务注册中心获知有哪些地址可用，然后自己再从这些地址中选择出一个合适的服务端发起请求。Ribbon就是一个进程内的负载均衡实现。

3. Ribbon常用的负载均衡策略

Ribbon就属于进程内负载均衡，它只是一个类库，集成于Eureka Client进程，Eureka Client进程通过访问注册中心Eureka Server发现服务列表，发现的服务列表信息是由ribbon来管理的。当访问Application Service的时候，Application Client会通过ribbon来找到合适的Application Service地址信息，并发起远程调用请求。
ribbon的负载均衡策略是通过不同的类型来实现的，下表详细介绍一些常用负载均衡策略及对应的Ribbon策略类。这些类型都在包com.netflix.loadbalancer下。

a. 轮询策略(默认) - RoundRobinRule

轮询策略表示每次都顺序取下一个provider，比如一共有5个provider，第1次取第1个，第2次取第2个，第3次取第3个，以此类推

b. 权重轮询策略（常用） - WeightedResponseTimeRule

1.根据每个provider的响应时间分配一个权重，响应时间越长，权重越小，被选中的可能性越低。
2.原理：一开始为轮询策略，并开启一个计时器，每30秒收集一次每个provider的平均响应时间，当信息足够时，给每个provider附上一个权重，并按权重随机选择provider，高权越重的provider会被高概率选中。

c. 随机策略（不推荐） - RandomRule

从provider列表中随机选择一个provider

d. 最少并发数策略（应用在硬件软件环境一致的情况下） - BestAvailableRule

选择正在请求中的并发数最小的provider，除非这个provider在熔断中。

e. 在“选定的负载均衡策略”基础上进行重试机制 - RetryRule

1.“选定的负载均衡策略”这个策略是轮询策略RoundRobinRule
2.该重试策略先设定一个阈值时间段，如果在这个阈值时间段内当选择provider不成功，则一直尝试采用“选定的负载均衡策略：轮询策略”最后选择一个可用的provider

f. 可用性敏感策略（一般在同区域内服务集群环境中使用） - AvailabilityFilteringRule

过滤性能差的provider,有2种：
第一种：过滤掉在eureka中处于一直连接失败provider
第二种：过滤掉高并发的provider

g. 区域敏感性策略（应用在大型的，物理隔离分布式环境中） - ZoneAvoidanceRule

1.以一个区域为单位考察可用性，对于不可用的区域整个丢弃，从剩下区域中选可用的provider
2.如果这个ip区域内有一个或多个实例不可达或响应变慢，都会降低该ip区域内其他ip被选中的权重

4. 配置ribbon负载均衡策略, 在配置文件application.yml文件中添加如下配置：

{服务名称 - 即显示在eureka管理界面上, Application的名称}: 
  ribbon:
    NFLoadBalancerRuleClassName: {策略类的全名称, 如: com.netflix.loadbalancer.RandomRule}

5. 配置点对点直连(一般用于测试)， 在配置文件application.yml文件中添加如下配置:

{服务名称 - 即显示在eureka管理界面上, Application的名称}: 
  ribbon:
    listOfServers: 127.0.0.1:8081

ribbon:
  eureka:
    enabled: false