测试开发进阶——Spring cloud——理解——微服务中负载均衡理解(转载)

一、概述


负载均衡
组件库: Spring Cloud Netflix 组件库
组件: Ribbon

二、负载均衡介绍


(一)、什么是负载均衡


负载均衡建立在现有网络结构之上,它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。
负载均衡(Load Balance)其意思就是分摊到多个操作单元上进行执行,例如Web服务器、FTP服务器、企业关键应用服务器和其它关键任务服务器等,从而共同完成工作任务。——

(二)、微服务中客户端负载均衡模式和服务端负载均衡模式之间如何选择


1.客户端负载均衡模式

使用背景: 客户端在注册时,能通过Eureka的服务发现获取微服务集群中的服务节点列表和节点状态。

前提: 1.机器列表要保存在客户端;2.机器列表要能够及时的动态更新,以便于获取节点的最新状态。

使用: 有了上诉背景和前提条件,客户端本地就能实现负载均衡策略了

2.服务端实现负载均衡策略

使用背景: 使用背景同样是微服务(spring cloud)集群服务节点

前提:与客户端负载均衡策略不同的是,服务端负载均衡策略需要由中间件来实现,例如Nginx、F5。

使用: 有了上诉背景和前提条件,就可以使用服务端负载均衡策略了。

3.spring cloud中两种负载均衡模式的比较

4.总结

一般而言,大型应用通常是客户端+服务端负载均衡搭配来使用的。

三、深入Ribbon
(一)、Ribbon实现负载均衡策略和原理,加载方式,IPing机制


1.特点:


组件库丰富:整套负载均衡由7个具体的策略组成,无论你是什么特殊需求,都有合适的策略供你选择。


适配性强:给谁都能用,跟多个组件都能搭配,能跟Sprig Cloud里的多个组件(eureka、feign、gateway、zuul、hystrix)搭配使用;


此外,Ribbon可以脱离SpringCloud应用在一般项目中

2.Ribbon的基本工作模式(IPing+IRule)

当Eureka接到Http请求时,此时Eureka虽然拥有所有服务节点的信息,但它不知道该如何选择才能满足负载均衡,所以Eureka将请求转到Ribbon。

IPing:IPing是Ribbon的healthcheck机制,检查目标节点是否还在线,一般不会主动向服务节点发起healthcheck,而是Ribbon后台静默处理。


IRule: Ribbon 组件库,各种负载均衡策略都继承自IRule接口。所有经过Ribbon的请求,都会先请求IRule,由IRule通过负载均衡策略选择指定的目标机器。


3.Ribbon负载均衡七龙珠之底层七种负载均衡策略


Ribbon的LoadBalancer的更底层内置了7中负载均衡策略


第一种:随机策略(RandomRule),自然是随性而为,随机选择服务名称对应的服务节点。


第二种:轮询策略(RoundRobinRule),一个一个来,谁不用急,底层使用了CAS+自旋锁的方式来保证线程安全。


第三种:重试策略(RetryRule),一次不行再来第二次,使用了类似于装饰器设计模式,相当于重试+实际模式的方式,所以需要指定真正被执行的负载均衡策略。


第四种:权重策略(WeightedResponseTimeRule),谁响应快,那么谁被选中的几率就高,该规则会自动根据服务节点的响应时间来计算权重,响应快则权重高。该Rule继承自                                                                                              RoundRobinRule,所以服务器刚启动时采用轮询策略,当权重数据积累足够后才使用WeightedResponseTimeRule模式。


第五种:空闲策略(BestAvailableRule),谁最闲谁先来,在过滤掉故障服务后,选择过去30分钟类并发量最小的服务节点。当然服务器刚启动时,统计结果未生成时,依然使用轮                  询的方式。


第六种:下限策略(AvailabilityFilteringRule),基于RoundRobinRule来选择服务节点,但必须满足它的最低要求,否在不予采纳,10次以内选择种为止。


第七种:自主策略(ZoneAvoidanceRule),以机房大区(Zone)和可用性作为过滤条件,选择可用的服务节点。满足大区要求,且服务可用且并发量不大的节点才会被选中。

IPing机制


IPing机制是一种主动机制,他能主动判断当前服务器节点的状态,并决定该节点是否可作为目标节点,只用可用的节点才会作为负载均衡的目标节点。


三种机制:


Dummy:默认返回true,即认为所有节点都是可用的


NIWSDiscoveryPing:借助Eureka服务发现机制获取节点状态,节点状态为UP则认为节点可用


PingUrl: 主动向服务节点发起HTTP调用,如节点响应,才认为节点可用。


在与Eureka组件搭配使用时,默认使用NIWSDiscoveryPing机制,以此减少服务节点负担。

(三)、工作中如何选择负载均衡策略


Ribbon 一共提供了七种负载均衡策略,默认使用的RoundRobinRule(轮询)策略,那么我们该如如何选择呢?


提前说一下,如非必要,不用更改负载均衡策略,除非有相应的业务要求或者其他情况。


1.连接数敏感模型
当正常负载下,连接数与业务复杂度是非线性相关的接口,可以采用基于可用连接数的负载均衡策略(BestAvailableRule)。通俗的讲就是接口本身处理业务的时间不会因参数的变化而有较大的波动的接口

2.RT数敏感模型
当正常负载下,就是接口本身处理业务的时间会因参数的变化而有较大的波动的接口,可以采用基于服务响应时间的负载均衡策略(WeightedResponseTimeRule)

3.成功率敏感模型
当正常负载下,业务对于响应时间没有太高的要求,但是对成功率要求很高的系统,比如我曾经历过的报文系统,他对响应时间并没有太高的要求,但要求报文发送一定要成功,这种可以采用重试策略(RetryRule)

原文地址:https://www.cnblogs.com/xiaobaibailongma/p/15356688.html