1. LB的基本功能要求
想想一个LB是怎么工作的,不管是硬件的还是软件的,我们要求它有哪些能力,提个最精简的需求清单出来:好像能想到的也就两个吧:
- ?设置添加和读取后端的服务(器)列表
- 能从中选择一个服务(器)
Netflix的LoadBalancer也是这样被要求的。通过ILoadBalancer来要求的。
可以看到主要有:对应配置后端服务;读取后端服务;标记一个服务不可用;当然最主要的是选择一个后端服务来提供服务。
这是2.1.0版本的方法列表,2.1.3开始版本也就是把getServerList (boolean availableOnly)分成了两个getReachableServers和getAllServers(解释是in favor of the cleaner),一个分成俩,clean了吗,好像一点点。一个是得到所有的后端server,一个是只返回可用的后端server。
2 主要实现
观察ILoadBalancer最基础的实现类com.netflix.loadbalancer.BaseLoadBalancer可以了解主要行为。LB的主要实现都在里面,DynamicServerListLoadBalancer和ZoneAwareLoadBalancer不过是扩展了他的功能而已。
虽然从ribbon默认提供的是一种ZoneAwareLoadBalancer的LB.
|
@Bean
@ConditionalOnMissingBean
publicILoadBalancer ribbonLoadBalancer(IClientConfig config,
ServerList<Server>serverList,ServerListFilter<Server>serverListFilter,
IRule rule,IPing ping){
ZoneAwareLoadBalancer<Server>balancer=LoadBalancerBuilder.newBuilder()
.withClientConfig(config).withRule(rule).withPing(ping)
.withServerListFilter(serverListFilter).withDynamicServerList(serverList)
.buildDynamicServerListLoadBalancer();
returnbalancer;
}
|
3 主要组件
可以看到一个LB中包含的几个重要的属性(工具),正是这几个工具为LB的功能提供支持。 他们是:
IRule |
负载均衡策略,可以插件化的为LB提供各种适用的负载均衡算法 |
Iping |
?判断目标服务是否存活 对应不同的协议不同的方式去探测,得到后端服务是否存活。如有http的,还有对于微服务框架内的服务存活的NIWSDiscoveryPing是通过eureka client来获取的instanceinfo中的信息来获取。 |
LoadBalancerStats |
LB运行信息 记录LB的实时运行信息,这些运行信息可以被用来作为LB策略的输入。 |
观察下几个主要方法。首先是最重要的的服务选择方法:
|
publicServer chooseServer(Objectkey){
if(counter==null){
counter=createCounter();
}
counter.increment();
returnrule.choose(key);
}
|
有点失望,啥也没有,除了个计数,就一句,可以看到将该功能委托给包含的负载均衡策略rule来实现。 可以通过使用不同的负载均衡策略的choose方法来达到LB的不同行为,这个将在另一篇文章中介绍。
其他的也没有什么特别的,维护后端的服务列表实现了getServerList和addServers方法如下:
|
publicList<Server>getServerList(booleanavailableOnly)
return(availableOnly?Collections.unmodifiableList(upServerList):Collections.unmodifiableList(allServerList));
}
publicvoidaddServers(List<Server>newServers){
ArrayList<Server>newList=newArrayList<Server>();
newList.addAll(allServerList);
newList.addAll(newServers);
setServersList(newList);
}
|
关于IPing的使用,在初始化LB的时候会启动一个timer来根据配置的周期pingIntervalSeconds,使用配置的IPing方式类判断后端的server哪些是不可用的。
另外重要一点,IRule和IPing两个LB中使用的重要逻辑的东西都可以在配置中配置一个类名来动态生成。
|
publicvoidinitWithNiwsConfig(IClientConfig clientConfig){
StringruleClassName=(String)clientConfig.getProperty(CommonClientConfigKey.NFLoadBalancerRuleClassName);
StringpingClassName=(String)clientConfig.getProperty(CommonClientConfigKey.NFLoadBalancerPingClassName);
IRule rule;
IPing ping;
rule=(IRule)ClientFactory.instantiateInstanceWithClientConfig(ruleClassName,clientConfig);
ping=(IPing)ClientFactory.instantiateInstanceWithClientConfig(pingClassName,clientConfig);
}
|
这也是LB最灵活的地方,用户可以根据自己的server的协议和判断标准写一个ping方法。 如ribbon提供了常用的http的ping,还提供了用于于微服务框架内的服务存活的NIWSDiscoveryPing,通过eureka client来获取的instanceinfo中的信息来获取服务的状态。 当然更常用的是用户自己要写适合应用场景的负载均衡策略。这将在另一篇文章详细的说明。
4 Server 后端服务
Ribbon的后端服务的描述封装在com.netflix.loadbalancer.Server中,主要信息也就两个host和port。但实现上比这个却看上去要复杂,看到里面定义了这样一个内部接口的实现
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
privateMetaInfo simpleMetaInfo=newMetaInfo(){
@Override
publicStringgetAppName(){
returnnull;
}
@Override
publicStringgetServerGroup(){
returnnull;
}
@Override
publicStringgetServiceIdForDiscovery(){
returnnull;
}
@Override
publicStringgetInstanceId(){
returnid;
}
};
|
怎么还有getServiceIdForDiscovery?看下Server的子类com.netflix.niws.loadbalancer.DiscoveryEnabledServer,应该就全明白了。
|
this.serviceInfo=newMetaInfo(){
@Override
publicStringgetAppName(){returninstanceInfo.getAppName();}
@Override
publicStringgetServerGroup(){returninstanceInfo.getASGName();}
@OverridepublicStringgetServiceIdForDiscovery(){returninstanceInfo.getVIPAddress();}
@Override
publicStringgetInstanceId(){returninstanceInfo.getId();}
};
|
看到引用到的com.netflix.appinfo.InstanceInfo就理解了,这里的服务正是eureka发现和注册的服务,ribbon作为一个通用的客户端负载均衡,只要把请求转发到一个host+port上,但在netflix的微服务框架里,ribbon常用的的后端也就是服务框架中注册的服务。 能猜到getASGName这个ASG是什么意思不?AWS Service Group? 怎么还说有aws的东西。
完。
相关推荐
Spring Cloud Netflix:核心组件,可以对多个Netflix OSS开源套件进行整合,包括以下几个组件: Eureka:服务治理组件,包含服务注册与发现 Hystrix:容错管理组件,实现了熔断器 Ribbon:客户端负载均衡的服务调用...
Spring Cloud Ribbon是一个基于HTTP和TCP的客户端负载均衡工具,它基于Netflix ... 在这一章中,我们将具体介绍如何使用Ribbon来实现客户端的负载均衡,并且通过源码分析来了解Ribbon实现客户端负载均衡的基本原理。
简单的说,Ribbon是一个客户端负载均衡器,我们可以在配置文件中列出Load Balancer后面所有的机器,Ribbon会自动的帮助你基于某种规则(如简单轮询,随机连接等)去连接这些机器,我们也很容易使用Ribbon实现自定义...
ribbon-httpclient-2.2.5.jar
Ribbon是一个基于HTTP和TCP的客户端负载均衡工具,它基于Netflix Ribbon实现。通过Spring Cloud的封装,可以让我们轻松地将面向服务的REST模版请求自动转换成客户端负载均衡的服务调用。Spring Cloud Ribbon虽然只是...
Spring Cloud Ribbon是基于Netflix Ribbon实现的一套客户端 负载均衡的工具。 简单的说,Ribbon是Netflix发布的开源项目,主要功能是提供客户端的软件负载均衡算法,将Netflix的中间层服务连接在一。Ribbon客户端...
netflix Ribbon源码下载
Spring Cloud Ribbon 是一个基于Http和TCP的客服端负载均衡工具,它是基于Netflix Ribbon实现的。它不像服务注册中心、配置中心、API网关那样独立部署,但是它几乎存在于每个微服务的基础设施中。包括前面的提供的...
Ribbon充当负载均衡器的作用,能够让我们的服务消费者调用到自己想使用的服务,服务消费者不用关心中间具体的操作,只需要将要调用的服务信息告诉负载均衡器,Ribbon就会从相应的服务集群中选择一个可以使用的服务器...
Spring Cloud Netflix 具有声明式 REST 客户端、断路器、服务发现、客户端负载均衡器、外部配置、路由器和过滤器这些特性。 Netflix 的项目建立在 Spring Boot 框架之上,提供了如下组件: ...
Ribbon:客户端负载均衡 Feign:基于Ribbon和Hystrix的声明式服务调用组件 Zuul:网关组件 Spring Cloud Bus:事件、消息总线,用于传播集群中的状态变化或事件 Spring Cloud Consul:服务发现与配置管理工具 Spring...
全球最大的互联网视频提供商Netflix在自己的技术团队博客上发布文章,对外...请注意:上面提到的负载均衡器是内部的客户侧负载均衡器,与Eureka一起使用,Eureka主要用来平衡到中间层服务的请求。 标签:Ribbon
spring cloud netflix eureka ribbon 示例 服务注册发现调用
ribbon:基于Netflix Ribbon 用过轮询策略实现的一套客户端负载均衡的工具 客户端负载均衡:负载均衡Zuul网关将一个请求发送给某一个服务的应用的时候,如果一个服务启动了多个实例,就会通过Ribbon来通过一定的负载...
spring-cloud-starter-netflix-ribbon-1.4.5.RELEASE.jar
使用springboot搭建的一个基础服务框架,里面主要使用了netflix的eureka、ribbon,是个学习和了解的框架
Spring Cloud 五大核心组件1.Netflix Eureka(服务发现)2.Netflix Ribbon(客户端负载均衡)3.Netflix Hystrix(断路器)4.Netflix Zuul(服务网关)5.Spring Cloud Config(分布式配置)
参考记录: ... 所有的SpringCloud能够实现三大模块: 服务发现——Netflix ...客户端负载均衡——Netflix Ribbon 断路器——Netflix Hystrix 服务网关——Netflix Zuul 分布式配置——Spring Cloud Config
使用Feign,只需要创建一个接口并注解,它具有可插拔的注解特性,可使用Feign 注解和JAX-RS注解,Feign支持可插拔的编码器和解码器,Feign默认集成了Ribbon,并和Eureka结合,默认实现了负载均衡的效果。 Feign ...
IDEA环境,springboot整合springcloud项目,并且解决springcloud导包出现unknown问题