开发者社区> luyiisme> 正文

Ribbon2 核心设计分析

简介: Ribbon 提供基于软件的负载均衡方式与目标集群中的机器进行通信。这里忽略状态统计部分,健康检查的逻辑部分。 下面是个典型的使用方式开始,先指定一些目标服务器地址, ``` //sample-client.ribbon.listOfServers=www.taobao.com:80,www.baidu.com:80,www.sina.com:80 ``` 然后借助ribbon
+关注继续查看

Ribbon 提供基于软件的负载均衡方式与目标集群中的机器进行通信。这里忽略状态统计部分,健康检查的逻辑部分。

下面是个典型的使用方式开始,先指定一些目标服务器地址,

//sample-client.ribbon.listOfServers=www.taobao.com:80,www.baidu.com:80,www.sina.com:80

然后借助ribbon 封装的 httpClient 来发送请求(访问站点首页),循环20次是希望打印出负载均衡的效果。

...
RestClient client = (RestClient) ClientFactory.getNamedClient("sample-client");  
HttpRequest request = HttpRequest.newBuilder().setUri(new URI("/")).build();
for (int i = 0; i < 20; i++)  {
  HttpResponse response = client.executeWithLoadBalancer(request);
  System.out.println("Status code for " + response.getRequestedURI() + "  :" + response.getStatus());
}

下面按 Ribbon 的主要模块进行设计分析,并在最后部分分析上述代码的效果。

Ribbon-core 模块

这一模块中,主要定义通用的调用抽象。ribbon 的 client 处理请求并返回响应。

public interface IClient<S extends ClientRequest, T extends IResponse> {
    public T execute(S request, IClientConfig requestConfig) throws Exception;
}

ClientRequest, 是独立于所以具体实现的通信协议的抽象。它主要包括:uri(远程资源的定位符),loadBalancerKey(Object类型,这是决定请求调用到目标服务器的关键信息),isRetriable; 当然它的具体实现类,可能还有请求headers,body等信息。

IResponse, 是服务端响应的抽象,主要包括: body(payload),isSuccess(响应状态的简化),响应headers,请求url;

VipAddress 术语,是一个地址的逻辑名,该逻辑名代表一系列目标服务器。比如“apple.bar:80”。

RetryHandler,用来决定哪些异常(比如:ConnectException,SocketTimeoutException)发生时要做重试,哪些异常(SocketException,SocketTimeoutException)发生时表示应该熔断掉(对应服务器)的调用,默认的是不重试。

Ribbon-loadbalancer 模块

负载均衡,宏观上效果是希望将请求的流量均衡(不是简单意义上的平均)的负载到提供服务的服务器之上。而对于每次请求而言,是通过计算拿到一个目标服务器地址的。

  • ILoadBalancer

ILoadBalancer, 负载均衡器的接口。它的核心方法是 public Server chooseServer(Object key); 每次请求发生时根据参数传入的 loadBalancerKey对象,决定出一个目标的服务器地址。Server 表示一个服务器(包括:主机地址,端口号以及一些元数据标识信息)。 那么服务均衡器应该需要有一批可供选择的目标服务集合吧,所以它还有个重要方法 addServers(List<Server> newServers),一般在启动阶段就要完成初始化地调用。

  • BaseLoadBalancer

BaseLoadBalancer(实现 ILoadBalancer),这里声明了一个基础lb,应该关联个 IRule(负载均衡的规则)默认是轮询规则:RoundRobinRule)。 它还默认支持一个Ping检查功能(可以帮忙我们定时检查目标服务器是否可通信)的定时任务,开发者可以在构造实例时明确指定 Iping(判断一个服务是否还是活的),IPingStrateg 默认是串行地检查策略,但如果目标服务地址过多,或者IPing执行过慢就不太合适。

IRule 路由规则,Rule 和 LoadBalancer 是一对一的相互关联关系,Rule 是具体的负责均衡策略。常见的规则包括: 轮询,随机,基于响应的延迟等; public Server choose(Object key)核心方法的输入输出基本一致,区别是 Rule 拿取目标 server list 是通过借助对应依赖的 LoadBalancer 拿到的。

  • DynamicServerListLoadBalancer

DynamicServerListLoadBalancer(继承 BaseLoadBalancer),事实上从启动后一直不变的 ServerList 场景一般不太多,尤其在微服务场景:服务挂了,扩容,缩容等都会需要对服务消费方的客户端的服务列表做出实时调整(通常借助服务发现产品:eureka,consul,zk...),DynamicServerListLoadBalancer 顾名思义就是针对该类场景的。要做到运行时实时更新,既要保证更新的实时可见,也要保证更新操作本身的同步。

ServerListUpdater,是动态服务列表的更新器。现实场景中一般有个专门提供发布和查询/订阅服务列表服务的角色,这里暂时简称为”远程注册表服务”。更新 ServerList 常见的有两种实现模式:push 或者 pull。 push 机制就是客户端保持对“远程注册表服务”观察就行,服务器发生变化时会,客户端就会及时得到通知。 还有一种 pull 机制,一般是频繁的发请求进行询问“远程注册表服务”是否有变化发生。这个一般建议基于常见的服务发现产品进行实现。

ServerListFilter,是DynamicServerListLoadBalancer的可选构造参数之一。作用是在发生 ServerList 更新时筛选过滤出符合条件的一个子集。 因为 ServerList 可能比较大,包含成百上千台机器地址,如果都尝试去调用,那么客户端的连接数就会非常多,这也会造成必要的消耗。

Ribbon-httpclient 模块

ribbon-loadbalancer 模块中有个 ClientFactory 静态工具类,可以生成和管理多个名字唯一的 IClient 具体实例。ClientFactory.getNamedClient("sample-client"); ,这里因为未特殊配置(指定具体的 IClient 的实现类),所以选择的是默认的Client实现类 com.netflix.niws.client.http.RestClient。

  • RestClient

RestClient,是 ribbon-httpclient 模块中针对 IClient 的具体实现,通过使用 Jesery Client (实际依赖 apacheHttpClient4 发送 http),同样 HttpRequest 实现 ClientRequest,而HttpResponse 实现了 ClientResponse。

client.executeWithLoadBalancer(request),是client的父类 AbstractLoadBalancerAwareClient 中定义的方法,最终是调用 LoadBalancerContext#getServerFromLoadBalancer(URI,loadBalancerKey)方法,该方法主要LB逻辑如下:

Server svc = lb.chooseServer(loadBalancerKey);
if (svc == null){
    throw new ClientException(ClientException.ErrorType.GENERAL,
            "Load balancer does not have available server for client: "
                    + clientName);
}

//... check host not null

logger.debug("{} using LB returned Server: {} for request {}", new Object[]{clientName, svc, original});
return svc;

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
Redis主从复制原理以及常见问题(1)
Redis主从复制原理以及常见问题
6 0
万字速通单例模式
谈起单例模式,想必大家都不陌生,不仅在各种大厂的面试中频频出现,在实际的开发中,也应用广泛,如何设计一个优雅的单例模式,成为了重头戏。
6 0
Zuul技术分享
ZUUL是Netflix开源的微服务网关,它可以和Eureka、Ribbon、Hystrix等组件配合使用,Zuul组件的核心是一系列的过滤器,这些过滤器可以完成以下功能: 动态路由:动态将请求路由到不同后端集群 压力测试:逐渐增加指向集群的流量,以了解性能 负载分配:为每一种负载类型分配对应容量,并弃用超出限定值的请求 静态响应处理:边缘位置进行响应,避免转发到内部集群 身份认证和安全: 识别每一个资源的验证要求,并拒绝那些不符的请求。Spring Cloud对Zuul进行了整合和增强。 Spring Cloud对Zuul进行了整合和增强
5 0
白话微服务架构中的服务发现
如果你想跟朋友失去联系的最简单方法就是在不通知他们的情况下更改您的电话号码。同样适用于微服务架构系统中的服务。两个服务可能会愉快地相互通信,直到其中一个服务移动到另一个IP地址,而不通知对方,导致服务不可用。
5 0
如何实现多账号共享VPC
多账号共享VPC架构具备上下通吃的特点,今天就给大家介绍一下这个架构要如何落地实施。
8 0
手撸一款简单高效的线程池(一)
线程池大家应该都用过,不过如何从 0 到 1 的设计一款简单好用且性能较好的线程池?我们在接下来的几篇文章中,为您一一介绍。
4 0
手撸一款简单高效的线程池(二)
大家好,我是不会写代码的纯序员——Chunel Feng[1]。这篇文章是线程池优化系列连载的第二篇。主要跟大家介绍几种线程池优化思路,包括:local-thread 机制、lock-free 机制、work-stealing 机制。
6 0
手撸一款简单高效的线程池(三)—— 性能优化!
在上一章中,我们给大家介绍了一些 C++线程池中的优化思路和实现方案。这一章中,我们将继续这个主题,接着聊线程池中还有可以“压榨”的空间。为实现我们吹过的牛 B,而继续编程
5 0
手撸一款简单高效的线程池(四)
在前几章的内容中,我们给大家介绍了一些 C++线程池中的优化思路和实现方案。这一章中,我们来聊一聊在编程实现过程中,一些工程层面的优化。让我们的代码执行的速度,跟得上自己的思路。
4 0
手撸一款简单高效的线程池(五)
在之前的内容中,我们给大家介绍了 C++实现线程池过程中的一些常用线优化方案,并分析了不同机制使用时的利弊。这一篇,是线程池系列的最后一章。我们会介绍一下 CGraph 中的 threadpool 如何使用,给出性能对比,并对接下来的工作做一些展望。让我们在线程池性能优化和功能提升的道路上,越走越远。
5 0
+关注
luyiisme
https://luyiisme.github.io/
2
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
OceanBase 入门到实战教程
立即下载
阿里云图数据库GDB,加速开启“图智”未来.ppt
立即下载
实时数仓Hologres技术实战一本通2.0版(下)
立即下载