01:前言
Ribbon是一个基于http和tcp的客户端负载均衡工具,它基于netiflix ribbon实现。可以让我们轻松的将面向服务的Rest模板请求自动转换成客户端负载均衡的服务调用。
Ribbon几乎存在Cloud构建的微服务和基础设施中,因为微服务的调用,api网关的请求转发等内容,实际上都是通过ribbon实现的。包括Feign。
02:客户端端负载均衡
负载均衡在系统架构中是一个非常重要的,并且不得不去实施的内容。因为负载均衡是对系统的高可用,网络压力的缓解和处理能力扩容。
我们通常所说的负载均衡是服务端的负载均衡,主要包括软件负载均衡和硬件负载均衡。硬件就是安装专门的设备。就是我们平常说的F5就是硬件负载均衡的代表之一。
而软件负载均衡是通过在服务器上安装一些具有负载均衡的软件来完成请求分发的工作。我们熟悉的Nginx 不论是硬件负载均衡,还是软件负载均衡。
硬件负载均衡和软件负载均衡都会维护一下挂可用的服务端清单,通过心跳来剔除故障的服务器。采用轮询算法包括线性轮询,按权重负载,按流量负载等。
而客户端负载均衡和服务端负载均衡最大的不同点是在于上面所提到的服务 清单的位置。在客户端负载均衡中,所有的客户端节点都维护着自己要访问的服务器清单。
服务提供者只需要启动多个服务实例并注册到一个注册中心或多个相关联的服务注册中心。
服务消费者直接通过调用@LoadBlanced注解修饰过的restTemplete来实现面向服务的接口调用。
03:restTemplete详解
在restTemplete中,对GET请求可以通过如下两个方法进行调用实现。
第一种:getForEntity函数。该方法返回的是ResponseEntity。该对象是spring对HTTP请求响应的封装。
第二种:getForObject函数,该方法可以理解为多getForEntity的进一步封装。
对于post请求
在restTemplete 中,对post请求通过三个方法进行调用,第一中
PostForEntity();第二种postForObject函数,第三种是postForLoaction。
并且restTemplete也支持put请求,delete请求。而ribbon就是通过restemplete机制实现负载均衡的。通过源码分析。我们可以获取底层实现。
04:负载均衡器
AbstractLoadBalancer是IloadBalancer接口的抽象实现,该抽像类中定义了一个枚举类serverGROUP包括三种不同类型。All,status_up status_not_up分别对应所有服务实例,正常服务实例,停止的服务实例。而BaseLoadBalancer是Ribbon负载均衡服务器的基础实现类。
Ribbon提供了好多负载均衡策略,通过实现IRule接口。Spring cloud eureka 实现了实现了CAP原理的ap 可用性,可靠性,它不强调一致性,而zk强调cp 即一致性,可靠性。在极端情况下,宁愿接受故障实例,也不愿意舍弃健康实例。我们引入重试机制,就是要加强这部分的容错。
领取专属 10元无门槛券
私享最新 技术干货