关于开发部署中(4层/7层/C端/S端)软负载均衡笔记

Posted 2023-02-21

参考技术A

关于 LVS 和 kube-proxy、F5 我们这里之后在和小伙伴分享， F5 没有接触过， LVS 的demo容器的方式一直没有成功， kube-proxy 这一块我还没学到，只是简单的了解.

如果能深刻理解苦难，苦难就会给人带来崇高感 。 ——路遥

处理传输层到应用层的数据，为了能通一个URL或者IP+PORT将前端的访问分发到后台的多个服务器上

Dev 即开发角度的负载均衡。开发中的负载均衡一般是在 微服务 中涉及。服务提供方一般以多实例的形式提供服务， 负载均衡功能能够让服务调用方连接到合适的服务节点 。 并且， 服务节点选择的过程对服务调用方来说是透明的 。

所以这里理解为是客户端的负载均衡，是相对服务端负载均衡而言。

客户端负载均衡来讲,就是调用的客户端本身是知道所有服务信息,当需要调用服务上的接口的时候,客户端从自身所维护的服务列表中,根据提前配置好的负载均衡策略,自己挑选一个服务来调用,此时,客户端知道它所调用的是哪一个服务.

在 Spring Cloud 中使用在 RestTemplate 进行服务调用,要想使用负载均衡功能,需要使用 Spring Cloud Ribbon 。

Spring Cloud Ribbon 是一个基于HTTP和TCP的客户端负载均衡工具,它基于 Nettlix Ribbon 实现。通过 Spring Cloud 的封装,可以让我们轻松地将面向服务的 REST 模板请求自动转换成客户端负载均衡的服务调用。

使用时需要给 RestTemplate 实例上添加一个 @LoadBalanced 注解即可,此时, RestTemplate 就会自动具备负载均衡功能,这个 负载均衡 就是 客户端负载均衡 。

Ops 即运维角度的负载均衡,这里的负载我们也称为服务端负载

所谓服务端负载均衡,比如传统的Nginx的方式，调用的客户端并不知道具体是哪个服务提供的服务,它也不关心,反正请求发送给Nginx, 或者hyproxy作为代理的服务器，然后 Ngixn 在请求负载任意服务,客户端只需要记着Nginx的地址即可。

Nginx 7层负载是最常见的一种负载,所谓7层负载，即应用层负载，即基于应用层协议(TELNET,SSH,HTTP,SMTP,POP…)做的代理，7层负载需要解析数据包的具体内容，需要消耗额外的cpu，然后根据具体内容(url, 参数, cookie, 请求头)匹配相应的路径，然后转发到相应的服务器。转发的过程是：建立和目标机器的连接，然后转发请求，收到响应数据再转发给请求客户端。

使用docker构建一个内部网络

内网里运行两个httpd服务
10.1.1.22

10.1.1.33

Ngixn实现到上面两个httpd服务的负载

运行Nginx容器

测试一下

所谓四层负载，即在传输层协议的基础上来做负载，基于TCP,UDP等协议，传输层的作用是确保数据被可靠的传输送到目标地址，能够让应用程序之间实现通信，所以彼此传递的是数据包，标识的只有IP+端口。不涉及具体的url其他结构解析。路径匹配等，不会涉及具体的应用层协议，所以理论上四层负载要比七成负载快。

nginx 四层代理是nginx1.9.0开始新增的功能，需要开启 --with-stream 模块，可以实现四层协议的转发、代理、负载等功能 。

这里的话，我们还是用容器的方式。配置方式和七层主要是配置文件的区别

启动4层负载的Nginx

测试一下

HAProxy 是一款提供高可用性、负载均衡以及基于TCP（第四层）和HTTP（第七层）应用的代理软件，支持虚拟主机，它是免费、快速并且可靠的一种解决方案。

HAProxy特别适用于那些负载特大的web站点，这些站点通常又需要 会话保持 或 七层处理 。HAProxy完全可以支持数以万计的并发连接。

这里我们还用之前的连个httpd服务演示

haproxy.cfg配置文件

测试下

四层负载和七层负载也是配置文件的区别

运行容器并测试