【SpingCloud】客户端与服务端负载均衡机制，微服务负载均衡NacosLoadBalancer， 拓展：OSI七层网络模型

客户端与服务端负载均衡机制

可能有第一次听说集群和负载均衡，所以呢，我们先来做一个介绍，然后再聊服务端与客户端的负载均衡区别。

集群与负载均衡

负载均衡是基于集群的，如果没有集群，则没有负载均衡这一个说法。 先来看什么是集群

从图中可以看到，集群就是由同一个服务进行的水平扩展，只需要复制多方，就能组成一个群体，这个群体需要使用负载均衡器维系在一起，他们才能成为一个集群整体，才能说的上是一个集群架构。如果没有负载均衡器，单独靠自己无法成为一个整体，只能是单独的个体，所以负载均衡器也是他们和外部联系的沟通渠道，是一个领头羊。此外集群也提供了高可用的目的，如果只有一个节点，挂了则无法再继续为用户提供服务了，显然这不符合如今的市场，所以高可用一定要落地的。

负载均衡器： 此外，负载均衡器是可以用于平摊流量的，如果现在流量有300万，那么可以每台节点平摊100万的请求，这样并发量就提升了，压力也就平摊了。

多级网关（负载均衡器的类型）

• 硬负载均衡器：F5，性能非常强大，企业级应用可以完全依靠他，但是，是在太贵了，中小公司是无法承担的，少则几十万，多则上百万，我们的老系统就是用的F5，每年还要150万的维护费用，企业负担太大了。传统软件用F5的会比较多。
• 软负载均衡器：解决中小企业痛点，很便宜，通过软件来实现负载均衡。只需要安装配置则可以实现负载均衡的效果，比如Nginx，Apache，Haproxy，都可以，那么这也是目前java生态里用的最多的方式。

此外还有基于网络模型的四层负载和七层负载：

• 四层代理：基于TCP，比如LVS+Keepalived，这玩意就是云负载均衡器的底层，如果自己部署需要有独立的机房。配置起来相对比较麻烦一些，这个我在架构师课程中有手把手的搭建以及配置，有兴趣可以了解一下。
• 七层代理：基于HTTP，最具有代表的则是Nginx了，后续我们也会用到，这也是网关，所以也可以称之为7层网关。

四层和七层的理解区别，四层制作请求转发，不会处理请求，而七层可以处理请求的，比如添加headers请求头，修改cookie，甚至设置缓存，对数据压缩等等，所以我们的微服务网关gateway也是四层网关的负载均衡器。所以，相对来说四层的功能性会比七层少很多，因为他不能处理请求，正因为这样，他的处理执行能力是相当强大的，要比七层快很多。

举个例子，你到园区要面试，园区保安大爷只会跟你说，你往后走，左转走到底，就是我们公司了。这是七层，他不会带你去。而你到了大楼，大楼的前台会领着你到公司，带着你过去，那么他就是七层负载了。这样你就可以更好的理解四层和七层的区别了。

多级网关模型：

负载均衡算法

• 轮询
• 权重
• url_hash
• ip_hash

服务端与客户端负载均衡

• 服务端负载均衡 上面所说的都是基于服务端的负载均衡器，啥意思，这是因为请求的分发是需要通过在服务端进行计算的，如下图：

• 客户端负载均衡 客户端负载均衡拉取集群列表是相反，他会拉取ip列表到本地进行算法，随后携带地址去请求目标接口，如下图：

所以相对的，使用客户端负载均衡器的一个整体性能会更高一些，因为压力在客户端，服务端不需要进行计算了，如果是服务端负载均衡器，那么所有请求都会在一个地方进行计算，那么这台节点就会很热，所以往往使用的云服务器硬件配置也会更高更好一些。

此外，客户端负载均衡是支持动态扩容的，因为他是去中心化的，如果是服务端负载，那么每次扩展节点都需要修改配置并且重启；而客户端则不需要，直接复制一个新节点就行了，不需要做额外代码或配置的修改，非常方便。

微服务负载均衡NacosLoadBalancer

LoadBalancer 其实我们之前在演示用户集群的时候其实就加入了这个依赖，他就是用于处理微服务的负载均衡的，他有自己的一套负载均衡算法。早期其实使用的是Ribbon，只不过目前因为种种原因弃用了。现在所使用的都是LoadBalancer，而且这是SpringCloud官方出的客户端负载均衡器，目的就是用来替代Ribbon的。

测试负载均衡：

和用户微服务一样，构建2~3个工作微服务集群：

配置集群服务：

网关排除url，为了方便测试：

默认模式就是轮询规则。

Nacos的负载均衡

在nacos中设置微服务的负载均衡权重比例。但是设置后不生效。

早期版本自带ribbon，可以直接在容器中构建一个Bean对象的NacosRule即可。新版本SpringCloudAibaba已经没有ribbon了。

所以新版本可以直接在yml中进行配置即可： 在网关和用户服务中添加：

spring:cloud:loadbalancer:nacos:enabled: true

最后请求访问这个接口，观察结果即可。

拓展：OSI七层网络模型

网络模型就是 OSI（Open System Interconnect），意思为开放网络互联，是由国际标准化组织(ISO)和国际电报电话咨询委员会(CCITT)共同出版的，他是一种网络互联模型，也是一种规范。

网络模型分为七层，也就是当用户发起请求到服务器接收，会历经七道工序，或者说用户利用互联网发送消息给另一个用户，也会历经七道工序。这七层可以分为如下：

| 层级 | 名称 | 说明 | | --- | --- | --- | | 第七层 | 应用层 | 与用户行为交互 | | 第六层 | 表示层 | 定义数据格式以及数据加密 | | 第五层 | 会话层 | 创建、管理以及销毁会话 | | 第四层 | 传输层 | 创建、管理请求端到响应端（端到端）的连接 | | 第三层 | 网络层 | 请求端的IP地址 | | 第二层 | 数据链路层 | 提供介质访问与链路管理 | | 第一层 | 物理层 | 传输介质，物理媒介 |

以上七层每层可以与上下相邻层进行通信。每一层都是非常复杂的，我们不在这里深究，我们以举例的形式来阐述每一层是干嘛的。

• 应用层：这是面向用户的，最靠近用户，为了让用户和计算机交互，在计算机里会有很多软件，比如eclipse，idea，qq，nginx等，这些都是应用软件，用户可以通过这些应用软件和计算机交互，交互的过程其实就是接口的调用，应用层为用户提供了交互的接口，以此为用户提供交互服务。那么在这一层最常见的协议有：HTTP,HTTPS,FTP,SMTP,POP3等。Nginx在本层，为七层负载均衡。 举例：我要寄一封信给远在天边的老外LiLei，我会打开快递软件下单，这个时候我是用户，快递软件就是应用服务，是建立在计算机上的，提供给用户交互的一种服务或称之为手段。
• 表示层：该层提供数据格式编码以及加密功能，确保请求端的数据能被响应端的应用层识别。 举例：我写中文给LiLei，他看不懂，这个时候我就会使用翻译软件把中文翻译成英文，随后信中涉及到一些比较隐私的信息我会加密一下，这个时候翻译软件和加密器就充当了表示层的作用，他用于显示用户能够识别的内容。
• 会话层：会话可以理解为session，请求发送到接受响应的这个过程之间存在会话，会话层就充当了这一过程的管理者，从创建会话到维护会话最后销毁会话。 举例：我每次写信给LiLei都会记录在一个小本本上，寄信时间日期，收信时间日期，这本小本本上存有每次通信记录，这个小本本就相当于是一个会话的管理者。又或者说，我们平时在打电话，首先需要拨打电话，这是建立会话，对方接听电话，此时正在通话（维持并管理会话），通话结束后会话销毁，那么这也是一次会话的生命周期。
• 传输层：该层建立端到端的连接，他提供了数据传输服务，在传输层通信会涉及到端口号，本层常见的协议为TCP、UDP，LVS就是在传输层，也就是四层负载均衡。 举例：我和LiLei通信过程中会借助快递公司，快递公司会分配快递员取件和寄件，那么这个快递员则充当传输层的作用。
• 网络层：网络通信的时候必须要有本机IP和对方的IP，请求端和响应端都会有自己的IP的，IP就相当于你家地址门牌号，在网络上云服务器有固定的公网IP，普通计算机也有，只不过是动态IP，运营商每天会分配不同的IP给你的计算机。所以网络层也能称之为IP层，IP是互联网的基础根本。能提供IP分配的设备则为路由器或交换机。 举例：对于拥有固定IP的云服务来说，他们都是由腾讯云、阿里云等这样的供应商提供的，他们为云服务器提供固定ip；电信、移动、联调等运营商为你的计算机动态分配ip，每天都不同；则这些供应商和运营商都是网络层。同理，快递员由物流公司分配和管理，那么物流公司就是网络层咯。
• 数据链路层：这一层会提供计算机MAC地址，通信的时候会携带，为了确保请求投递正确，所以他会验证检测MAC地址，以确保请求响应的可靠性。 举例：快递员在投递派送的时候，他（或客服）会预先提前打电话给你，确认你家地址对不对、有没有人、货到付款有没有准备好钱等等，这个时候快递员（或客服）就充当了数据链路层的职责。
• 物理层：端到端请求响应过程中的媒介，物理介质，比如网线、中继器等等设备，都是你在端到端交互过程中不可缺少的基础设备。 举例：快递员在投递的过程中，你写的信会历经一些交通运输工具，比如首先通过飞机运输到国外，在海关统一拿到信以后会通过汽车运输到LiLei所在城市的物流集散地，最后快递员通过三轮电频车寄到LiLei家里，这个时候，飞机、汽车、三轮电瓶车都是物理层的媒介。

那么以上就是七层网络模型，大家需要理解其意义即可。需要注意的是Nginx存在于第七层，属于七层负载均衡；而第四层会有LVS，属于四层负载均衡。