(非代码)微服务负载均衡和Ribbon详解

最新推荐文章于 2022-05-23 19:35:37 发布

CR553

最新推荐文章于 2022-05-23 19:35:37 发布

阅读量209

点赞数

分类专栏：微服务文章标签： java 后端

本文链接：https://blog.csdn.net/weixin_44273948/article/details/107860219

版权

微服务专栏收录该内容

8 篇文章 0 订阅

订阅专栏

微服务(非代码)负载均衡和Ribbon

文章目录

微服务(非代码)负载均衡和Ribbon
Ribbon
总结

一，什么是负载均衡

LB（Load Balance，负载均衡）是一种集群技术，它将特定的业务（网络服务、网络流量等）分担给多台网络设备（包括服务器、防火墙等）或多条链路，从而提高了业务处理能力，保证了业务的高可靠性。

二，为什么需要负载均衡

互联网的发展，业务流量越来越大并且业务逻辑也越来越复杂，单台机器的性能问题以及单点问题凸显了出来，因此需要多台机器来进行性能的水平扩展以及避免单点故障。但是要如何将不同的用户的流量分发到不同的服务器上面呢？早期的方法是使用DNS做负载，通过给客户端解析不同的IP地址，让客户端的流量直接到达各个服务器。但是这种方法有一个很大的缺点就是延时性问题，在做出调度策略改变以后，由于DNS各级节点的缓存并不会及时的在客户端生效，而且DNS负载的调度策略比较简单，无法满足业务需求，因此就出现了负载均衡。

三，负载均衡的原理

所谓四层就是基于IP+端口的负载均衡；七层就是基于URL等应用层信息的负载均衡；同理，还有基于MAC地址的二层负载均衡和基于IP地址的三层负载均衡。换句换说，二层负载均衡会通过一个虚拟MAC地址接收请求，然后再分配到真实的MAC地址；三层负载均衡会通过一个虚拟IP地址接收请求，然后再分配到真实的IP地址；四层通过虚拟IP+端口接收请求，然后再分配到真实的服务器，七层通过虚拟的URL或主机名接收请求，然后再分配到真实的服务器。所谓的四到七层负载均衡，就是在对后台的服务器进行负载均衡时，依据四层的信息或七层的信息来决定怎么样转发流量。 比如四层的负载均衡，就是通过发布三层的IP地址（VIP），然后加四层的端口号，来决定哪些流量需要做负载均衡，对需要处理的流量进行NAT处理，转发至后台服务器，并记录下这个TCP或者UDP的流量是由哪台服务器处理的，后续这个连接的所有流量都同样转发到同一台服务器处理。七层的负载均衡，就是在四层的基础上（没有四层是绝对不可能有七层的），再考虑应用层的特征，比如同一个Web服务器的负载均衡，除了根据VIP加80端口辨别是否需要处理的流量，还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。举个例子，如果你的Web服务器分成两组，一组是中文语言的，一组是英文语言的，那么七层负载均衡就可以当用户来访问你的域名时，自动辨别用户语言，然后选择对应的语言服务器组进行负载均衡处理。负载均衡器通常称为四层交换机或七层交换机。四层交换机主要分析IP层及TCP/UDP层，实现四层流量负载均衡。七层交换机除了支持四层负载均衡以外，还有分析应用层的信息，如HTTP协议URI或Cookie信息。这里我们主要谈一下软件负载均衡中的我们最常用的四层个七层负载均衡。

所谓四层负载均衡，也就是主要通过报文中的目标地址和端口，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。以常见的TCP为例，负载均衡设备在接收到第一个来自客户端的SYN 请求时，即通过上述方式选择一个最佳的服务器，并对报文中目标IP地址进行修改(改为后端服务器IP），直接转发给该服务器。TCP的连接建立，即三次握手是客户端和服务器直接建立的，负载均衡设备只是起到一个类似路由器的转发动作。在某些部署情况下，为保证服务器回包可以正确返回给负载均衡设备，在转发报文的同时可能还会对报文原来的源地址进行修改。

所谓七层负载均衡，也称为“内容交换”，也就是主要通过报文中的真正有意义的应用层内容，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。以常见的TCP为例，负载均衡设备如果要根据真正的应用层内容再选择服务器，只能先代理最终的服务器和客户端建立连接(三次握手)后，才可能接受到客户端发送的真正应用层内容的报文，然后再根据该报文中的特定字段，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。负载均衡设备在这种情况下，更类似于一个代理服务器。**负载均衡和前端的客户端以及后端的服务器会分别建立TCP连接。**所以从这个技术原理上来看，七层负载均衡明显的对负载均衡设备的要求更高，处理七层的能力也必然会低于四层模式的部署方式。

四，负载均衡的作用

解决并发压力，提高应用处理性能（增加吞吐量，加强网络处理能力）；
提供故障转移，实现高可用；
通过添加或减少服务器数量，提供网站伸缩性（扩展性）；
安全防护；（负载均衡设备上做一些过滤，黑白名单等处理）

五，负载均衡的分类

DNS负载均衡，HTTP负载均衡，IP负载均衡，反向代理负载均衡、链路层负载均衡

六，负载均衡的算法

1、轮询法

将请求按顺序轮流地分配到后端服务器上，它均衡地对待后端的每一台服务器，而不关心服务器实际的连接数和当前的系统负载。

2、随机法

通过系统的随机算法，根据后端服务器的列表大小值来随机选取其中的一台服务器进行访问。由概率统计理论可以得知，随着客户端调用服务端的次数增多，

其实际效果越来越接近于平均分配调用量到后端的每一台服务器，也就是轮询的结果。

3、源地址哈希法

源地址哈希的思想是根据获取客户端的IP地址，通过哈希函数计算得到的一个数值，用该数值对服务器列表的大小进行取模运算，得到的结果便是客服端要访问服务器的序号。采用源地址哈希法进行负载均衡，同一IP地址的客户端，当后端服务器列表不变时，它每次都会映射到同一台后端服务器进行访问。

4、加权轮询法

不同的后端服务器可能机器的配置和当前系统的负载并不相同，因此它们的抗压能力也不相同。给配置高、负载低的机器配置更高的权重，让其处理更多的请；而配置低、负载高的机器，给其分配较低的权重，降低其系统负载，加权轮询能很好地处理这一问题，并将请求顺序且按照权重分配到后端。

5、加权随机法

与加权轮询法一样，加权随机法也根据后端机器的配置，系统的负载分配不同的权重。不同的是，它是按照权重随机请求后端服务器，而非顺序。

6、最小连接数法

最小连接数算法比较灵活和智能，由于后端服务器的配置不尽相同，对于请求的处理有快有慢，它是根据后端服务器当前的连接情况，动态地选取其中当前

积压连接数最少的一台服务器来处理当前的请求，尽可能地提高后端服务的利用效率，将负责合理地分流到每一台服务器。

七，负载均衡的实现

1 - DNS域名解析负载均衡

在这里插入图片描述

利用DNS处理域名解析请求的同时进行负载均衡是另一种常用的方案。在DNS服务器中配置多个A记录,每次域名解析请求都会根据负载均衡算法计算一个不同的IP地址返回，这样A记录中配置的多个服务器就构成一个集群，并可以实现负载均衡。

DNS域名解析负载均衡的**优点是将负载均衡工作交给DNS，省略掉了网络管理的麻烦，缺点就是DNS可能缓存A记录，不受网站控制。**事实上，大型网站总是部分使用DNS域名解析，作为第一级负载均衡手段，然后再在内部做第二级负载均衡。

2 - 数据链路层负载均衡

在这里插入图片描述

数据链路层负载均衡是指在通信协议的数据链路层修改mac地址进行负载均衡。

这种数据传输方式又称作三角传输模式，负载均衡数据分发过程中不修改IP地址，只修改目的的mac地址，通过配置真实物理服务器集群所有机器虚拟IP和负载均衡服务器IP地址一样，从而达到负载均衡，这种负载均衡方式又称为直接路由方式（DR）.

在上图中，用户请求到达负载均衡服务器后，负载均衡服务器将请求数据的目的mac地址修改为真实WEB服务器的mac地址，并不修改数据包目标IP地址，因此数据可以正常到达目标WEB服务器，该服务器在处理完数据后可以经过网关服务器而不是负载均衡服务器直接到达用户浏览器。

使用三角传输模式的链路层负载均衡是目前大型网站所使用的最广的一种负载均衡手段。在linux平台上最好的链路层负载均衡开源产品是LVS(linux virtual server)。

3 - IP负载均衡

在这里插入图片描述

IP负载均衡：即在网络层通过修改请求目标地址进行负载均衡。

用户请求数据包到达负载均衡服务器后，负载均衡服务器在操作系统内核进行获取网络数据包，根据负载均衡算法计算得到一台真实的WEB服务器地址，然后将数据包的IP地址修改为真实的WEB服务器地址，不需要通过用户进程处理。真实的WEB服务器处理完毕后，相应数据包回到负载均衡服务器，负载均衡服务器再将数据包源地址修改为自身的IP地址发送给用户浏览器。

这里的关键在于真实WEB服务器相应数据包如何返回给负载均衡服务器，一种是负载均衡服务器在修改目的IP地址的同时修改源地址，将数据包源地址改为自身的IP，即源地址转换（SNAT），另一种方案是将负载均衡服务器同时作为真实物理服务器的网关服务器，这样所有的数据都会到达负载均衡服务器。

IP负载均衡在内核进程完成数据分发，较反向代理均衡有更好的处理性能。但由于所有请求响应的数据包都需要经过负载均衡服务器，因此负载均衡的网卡带宽成为系统的瓶颈。

4 - HTTP重定向负载均衡

在这里插入图片描述

HTTP重定向服务器是一台普通的应用服务器，其唯一的功能就是根据用户的HTTP请求计算一台真实的服务器地址，并将真实的服务器地址写入HTTP重定向响应中（响应状态吗302）返回给浏览器，然后浏览器再自动请求真实的服务器。

这种负载均衡方案的优点是比较简单，缺点是浏览器需要每次请求两次服务器才能拿完成一次访问，性能较差；使用HTTP302响应码重定向，可能是搜索引擎判断为SEO作弊，降低搜索排名。重定向服务器自身的处理能力有可能成为瓶颈。因此这种方案在实际使用中并不见多。

5 - 反向代理负载均衡

在这里插入图片描述

传统代理服务器位于浏览器一端，代理浏览器将HTTP请求发送到互联网上。而反向代理服务器则位于网站机房一侧，代理网站web服务器接收http请求。

反向代理的作用是保护网站安全，所有互联网的请求都必须经过代理服务器，相当于在web服务器和可能的网络攻击之间建立了一个屏障。

除此之外，代理服务器也可以配置缓存加速web请求。当用户第一次访问静态内容的时候，静态内存就被缓存在反向代理服务器上，这样当其他用户访问该静态内容时，就可以直接从反向代理服务器返回，加速web请求响应速度，减轻web服务器负载压力。

另外，反向代理服务器也可以实现负载均衡的功能。

由于反向代理服务器转发请求在HTTP协议层面，因此也叫应用层负载均衡。优点是部署简单，缺点是可能成为系统的瓶颈。

Ribbon

一，什么是Ribbon

Ribbon is a client side load balancer which gives you a lot of control over the behaviour of HTTP and TCP clients. Feign already uses Ribbon, so if you are using @FeignClient then this section also applies.

-----摘自官网

二，Ribbon与负载均衡

负载均衡在业界有不少分类：最常见的有软负载和硬负载，代表产品为nginx和F5.另外一组分类为集中式负载和进程内负载，即服务端负载均衡和客户端负载均衡。这种分类下，nginx和F5都为集中式负载，Ribbon为进程内负载。

Ribbon是Spring Cloud框架中相当核心的模块，负责着服务负载调用，Ribbon也可以脱离SpringCloud单独使用;Ribbon是客户端的负载均衡框架，即每个客户端上，独立维护着自身的调用信息统计，相互隔离；也就是说Ribbon的负载均衡表现在各个机器上变现并不完全一致;Ribbon 也是整个组件框架中最复杂的一环，控制流程上为了保证服务的高可用性，有很多比较细节的参数控制，在使用的过程中，需要深入理清每个环节的处理机制，这样在问题定位上会高效很多。

三，Ribbon的作用

负载均衡
容错
多协议（HTTP，TCP，UDP）支持异步和反应模型
缓存和批处理

四，Ribbon核心原理

在这里插入图片描述

五，LoadBalancer–负载均衡器的核心

LoadBalancer 的职能主要有三个：

维护Sever列表的数量(新增、更新、删除等)
维护Server列表的状态(状态更新)
当请求Server实例时，能否返回最合适的Server实例

1.负载均衡器的内部基本实现原理

在这里插入图片描述

Server

Server 作为服务实例的表示，会记录服务实例的相关信息，如：服务地址，所属zone，服务名称，实例ID等

ServerList

维护着一组Server实例列表,在应用运行的过程中，Ribbon通过ServerList中的服务实例供负载均衡器选择。ServerList维护列表可能在运行的过程中动态改变

ServerStats

作为对应Server 的运行情况统计，一般是服务调用过程中的Server平均响应时间，累计请求失败计数，熔断时间控制等。一个ServerStats实例唯一对应一个Server实例

LoadBalancerStats

作为 ServerStats实例列表的容器，统一维护

ServerListUpdater

负载均衡器通过ServerListUpdater来更新ServerList,比如实现一个定时任务，每隔一段时间获取最新的Server实例列表

Pinger

服务状态检验器，负责维护ServerList列表中的服务状态注意：Pinger仅仅负责Server的状态，没有能力决定是否删除

PingerStrategy

定义以何种方式还检验服务是否有效，比如是按照顺序的方式还是并行的方式

IPing

Ping，检验服务是否可用的方法，常见的是通过HTTP，或者TCP/IP的方式看服务有无认为正常的请求

2.如何维护Server列表？(新增、更新、删除)

在这里插入图片描述

Server列表的维护从实现方法上分为两类:

基于配置的服务列表

这种方式一般是通过配置文件，静态地配置服务器列表，这种方式相对而言比较简单，但并不是意味着在机器运行的时候就一直不变。netflix 在做Spring cloud 套件时，使用了分布式配置框架netflix archaius ，archaius 框架有一个特点是会动态的监控配置文件的变化，将变化刷新到各个应用上。也就是说，当我们在不关闭服务的情况下，如果修改了基于配置的服务列表时, 服务列表可以直接刷新

结合服务发现组件（如Eureka）的服务注册信息动态维护服务列表

基于Spring Cloud框架下，服务注册和发现是一个分布式服务集群必不可少的一个组件，它负责维护不同的服务实例（注册、续约、取消注册）。

3.负载均衡器如何维护服务实例的状态？

在这里插入图片描述

Ribbon负载均衡器将服务实例的状态维护托交给Pinger、 PingerStrategy、IPing 来维护，具体交互模式如下所示：

4.如何从服务列表中挑选一个合适的服务实例？

(1)服务实例容器：ServerList的维护

负载均衡器通过 ServerList来统一维护服务实例，具体模式如上图，基础的接口定义如下：

/**
 * Interface that defines the methods sed to obtain the List of Servers
 * @author stonse
 *
 * @param <T>
 */
public interface ServerList<T extends Server> {
    //获取初始化的服务列表
    public List<T> getInitialListOfServers();
    
    /**
     * Return updated list of servers. This is called say every 30 secs
     * (configurable) by the Loadbalancer's Ping cycle
     * 获取更新后的的服务列表
     */
    public List<T> getUpdatedListOfServers();   
 
}

在Ribbon的实现中，在ServerList（负责维护服务实例，并使用ServerListFilter过滤器过滤出符合要求的服务实例列表List）中，维护着Server的实例，并返回最新的List集合，供LoadBalancer使用。

在这里插入图片描述

(2)服务实例列表过滤器ServerListFilter

传入一个服务实例列表，过滤出满足过滤条件的服务列表

public interface ServerListFilter<T extends Server> {
    public List<T> getFilteredListOfServers(List<T> servers);
}

Ribbon 的默认ServerListFilter实现1：ZoneAffinityServerListFilter
- Ribbon默认采取了区域优先的过滤策略，即当Server列表中，过滤出和当前实例所在的区域（zone）一致的server列表
Ribbon 的ServerListFilter实现2：ZonePreferenceServerListFilter
- ZonePreferenceServerListFilter 集成自 ZoneAffinityServerListFilter，在此基础上做了拓展，在返回结果的基础上，再过滤出和本地服务相同区域(zone)的服务列表。
- 当指定了当前服务的所在Zone，并且 ZoneAffinityServerListFilter 没有起到过滤效果时，ZonePreferenceServerListFilter会返回当前Zone的Server列表。
Ribbon 的ServerListFilter实现3：ServerListSubsetFilter
- 这个过滤器作用于当Server数量列表特别庞大时（比如有上百个Server实例），这时，长时间保持Http链接也不太合适，可以适当地保留部分服务，舍弃其中一些服务，这样可使释放没必要的链接。
  此过滤器也是继承自 ZoneAffinityServerListFilter,在此基础上做了拓展，在实际使用中不太常见。

(3)LoadBalancer选择服务实例的流程

**LoadBalancer的核心功能是根据负载情况，从服务列表中挑选最合适的服务实例。**LoadBalancer内部采用了如下图所示的组件完成：

在这里插入图片描述

LoadBalancer 选择服务实例的流程

通过ServerList获取当前可用的服务实例列表；
通过ServerListFilter将步骤1 得到的服务列表进行一次过滤，返回满足过滤器条件的服务实例列表；
应用Rule规则，结合服务实例的统计信息,返回满足规则的某一个服务实例；

通过上述的流程可以看到，实际上，在服务实例列表选择的过程中，有两次过滤的机会：第一次是首先通过ServerListFilter过滤器，另外一次是用过IRule 的选择规则进行过滤。

总结

负载均衡是是一种集群技术，将业务分担给多台网络设备或多条链路，提高业务处理能力，保证业务的高可靠性。

随着业务流量增大,需要多台机器进行性能扩展和避免单点故障.DSN已经无法满足当前使用,故出现了负载均衡。

四到七层负载均衡，就是在对后台的服务器进行负载均衡时，依据四层的信息或七层的信息来决定怎么样转发流量。

负载均衡可以解决并发压力，提高应用处理能力；提供故障转移，实现高可用；通过添加或减少服务器数量，提供网站伸缩性；安全防护；

负载均衡的可分为DNS负载均衡，HTTP负载均衡，IP负载均衡，反向代理负载均衡、链路层负载均衡

负载均衡的常见算法有轮询法，随机法源地址哈希法，加权轮询法，加权随机法，最小连接数法。

Ribbon是客户端的负载均衡框架

Ribbon可以起到负载均衡，容错，支持异步和反应模型，缓存和批处理等作用

当前使用,故出现了负载均衡。

四到七层负载均衡，就是在对后台的服务器进行负载均衡时，依据四层的信息或七层的信息来决定怎么样转发流量。

负载均衡可以解决并发压力，提高应用处理能力；提供故障转移，实现高可用；通过添加或减少服务器数量，提供网站伸缩性；安全防护；

负载均衡的可分为DNS负载均衡，HTTP负载均衡，IP负载均衡，反向代理负载均衡、链路层负载均衡

负载均衡的常见算法有轮询法，随机法源地址哈希法，加权轮询法，加权随机法，最小连接数法。

Ribbon是客户端的负载均衡框架

Ribbon可以起到负载均衡，容错，支持异步和反应模型，缓存和批处理等作用

Ribbon的核心组件LoadBalancer 的原理：如何维护Sever列表的数量？如何维护Server列表的状态？当请求Server实例时，如何返回最合适的Server实例？

CR553

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
(非代码)微服务负载均衡和Ribbon详解

微服务(非代码)负载均衡和Ribbon文章目录微服务(非代码)负载均衡和Ribbon一，什么是负载均衡二，为什么需要负载均衡三，负载均衡的原理四，负载均衡的作用五，负载均衡的分类六，负载均衡的算法七，负载均衡的实现1 - DNS域名解析负载均衡2 - 数据链路层负载均衡3 - IP负载均衡4 - HTTP重定向负载均衡5 - 反向代理负载均衡Ribbon一，什么是Ribbon二，Ribbon与负载均衡三，Ribbon的作用四，Ribbon核心原理五，LoadBalancer–负载均衡器的核心1.负载均衡器
复制链接

扫一扫