客户端负载均衡-Spring Cloud Ribbon

Spring Cloud Ribbon是基于HTTP和TCP客户端负载均衡工具，基于Netflix Ribbon实现

负载均衡

服务端负载均衡

. 硬件负载均衡 如F5
. 软件负载均衡 如Nginx

客户端负载均衡

@LoadBalanced开启负载均衡

客户端和服务端 负载均衡最大不同点在于服务清单所存储的位置

客户端负载均衡中，所有客户端节点都维护着自己要访问的服务清单，来自于服务注册中心

RestTemplate

GET请求

getForEntity函数
getForObject函数

POST请求

postForEntity函数
postForObject函数
postForLocation函数 以post请求提交资源，并返回新资源的uri

PUT请求

put函数 返回值为void

DELETE请求

delete函数

负载均衡自动化配置LoadBalancerAutoConfiguration的条件

@ConditionalOnClass(RestTemplate.class)
@ConditionalOnBean(LoadBalancerClient.class)

该类主要做了三件事

创建了一个LoadBalancerInterceptor的Bean，用于客户端发起请求时拦截，以实现客户端负载均衡
创建了一个RestTemplateCustomizer的Bean，用于给RestTemplate增加拦截器
维护了 一个被@LoadBalanced修饰的RestTemplate对象列表，并初始化，通过调用RestTemplateCustomizer实例来给需要客户端负载均衡的RestTemplate增加拦截器

负载均衡器 - ILoadBalancer

AbstractLoadBalancer是ILoadBalancer接口的抽象实现

定义了分组实例

ALL
STATUS_UP
STATUS_NOT_UP

BaseLoadBalancer是Ribbon负载均衡器的基础实现类

DynamicServerListLoadBalancer是对基础负载均衡器的扩展

实现了服务清单在运行时动态更新的能力
具备对服务清单的过滤功能

ServerListUpdater - 对ServerList的更新

ServerListFilter

ZoneAwareLoadBalancer是对DynamicServerListLoadBalancer的扩展，也是默认的Ribbon负载均衡器

负载均衡策略 - IRule

AbstractLoadBalancerRule是负载均衡策略的抽象类

RandomRule 该策略实现了从服务清单中随机选取一个的策略

RoundRobinRule 该策略实现了按照线性轮询的方式依次选取

WeightedResponseTimeRule对RoundRobinRule的扩展，增加了根据实例的运行情况来计算权重，并根据权重挑选实例，以达到更优分配

WeightedResponseTimeRule的三个核心内容

定时任务，用来为每个服务实例计算权重，默认30s执行一次
权重计算
实例选择，1 生成一个[0，最大权重值]的随机数 2 遍历权重列表

RetryRule 该策略实现了具备重试机制的实例选择功能

ClientConfigEnabledRoundRobinRule比较特殊，不直接使用

BestAvailableRule对ClientConfigEnabledRoundRobinRule的继承，注入了负载均衡器的统计对象

可选出最空闲的实例

PredicateBasedRule对ClientConfigEnabledRoundRobinRule的继承，是一个抽象策略

“先过滤清单，在轮询选择”

AvailabilityFilteringRule对PredicateBasedRule的继承

ZoneAvoidanceRule对PredicateBasedRule的继承

配置详解

自动配置

IClientConfig：Ribbon客户端配置
IRule：Ribbon负载均衡策略
IPing：Ribbon实例检查策略
ServerList：服务实例清单的维护机制
ServerListFilter：服务实例清单的过滤机制
ILoadBalancer：负载均衡器

注意：当同时引入Eureka和Ribbon时会有些不同

同时引入时会触发Eureka中实现的对Ribbon的自动化配置

参数配置

1 全局配置：配置文件中ribbon. = value

2 指定客户端的配置：配置文件中.ribbon.=value

重试机制

Eureka的实现的服务治理机制强调了CAP理论中的AP,可用性和分区容错性，而Zookeeper强势的是CP，一致性和分区容错性。其最大区别是Eureka为了实现更高的服务可用性，牺牲了一定的一致性。