负载均衡高可用篇4层7层负载均衡

Posted 2021-04-15 健身IT青年

随着业务的发展以及用户访问量的不断增加，运维系统往往会遇到单台服务器无法承载全部请求和处理负荷的情况。同时，对于系统的可用性也有更高的要求。如何使业务的压力能够基本均衡地分布到不同的服务器上，同时减少单台服务器宕机导致的业务连续性不可用的时间，是运维工程师需要面对和解决的问题。————《Linux运维最佳实践》

OSI七层互联模型是分析问题的重要参考，作为技术铺垫，先来了解一波OSI七层互联模型：

最佳实践1：数据链路层负载均衡

什么情况用到数据链路层负载均衡？

在某个应用环境中，服务器配备2个吞吐量均为1Gbps的网卡，但是测试发现单台Memcached服务器的吞吐量可能达到1.3Gbps左右，明显超过了单个网卡的处理能力；此时又不可能替换成10Gbps网卡（架构和成本限制）。数据链路层负载均衡成为唯一可以采用的方案。

对网卡功能高可用性的要求。比如业务需要在单网卡故障的情况下保证连续性。

怎么实现数据链路层负载均衡？

    对于Linux系统来说，实施方案是双网卡绑定（Bonding），在思科交换机上这一技术被称作EtherChannel。

最佳实践2：4层负载均衡

网络协议的4层是指传输层，包括TCP和UDP等协议（《TCP/IP详解卷一：协议》有对传输层协议进行相依而专业的讲解）

    所谓的4层负载均衡，就是由负载均衡器（负载均衡设备或者软件）通过TCP或者UDP的Header信息（如源端口或者目标端口）进行直接判断由哪个实际的后端服务器来实际处理该连接，从而进行转发。在实践中，负载均衡器以目的端口进行调度为主。

下面看看4层负载均衡的时序图

最佳实践3：7层负载均衡

7层负载均衡，又称为“内容交换”，是指负载均衡器通过分析应用层请求的数据特征，进行负载均衡调度。如请求方法 RequestMethod、请求的URI RequestURI、请求的Host信息 Host。（可用wireshark抓包分析，也可以用Google浏览器自带的开发者工具）

下面看看7层负载均衡的时序图

总结下4层负载均衡的特点

         模型复杂度高。

根据上调分析，CPU处理逻辑复杂，吞吐量小。。

对后端选择的精细化控制。因为负载均衡器能够解析到应用层特征，所以能够对客户端的请求更加合理地选择，提高后端的执行效率。比如针对域名、目录结构等。

总结4层、7层负载均衡

1、调度依据

1. 4层负载均衡根据源端口和目标端口进行调度，实际中，负载均衡器以目的端口进行调度为主。

2. 7层负载均衡根据 请求方法（Request Method）、请求URI（Request URI）、请求Host信息 进行调度。

2、使用场景

4层负载均衡

    使用在要求较高吞吐量，后端服务器的业务逻辑为私有实现，无法直接获取到应用层业务逻辑的场景。

7层负载均衡

1、后端服务器应用的通信协议比较开放、业务逻辑比较容易实现，有成熟的开源或者商业方案； 2、需要提高后端服务器的计算效率（如内存缓存Memcached、HTTP缓存Squid Web Cache等，基于请求的key、URL等进行调度，可以提高后端服务器的执行效率，增加命中率）。

1、负载均衡器收到来自客户端TCP SYN包后，即可进行负载调度。

2、第⑥步以后，客户端、负载均衡器、后端服务器均达到ESTABLISHED状态。

总结下4层负载均衡的特点

模型简单。负载均衡器不需要关心业务逻辑，只进行负载调度、网络转发和对后端服务器的健康检查。

吞吐量大。根据上条分析，CPU处理逻辑简单，相对于更高层次的负载均衡，可以提供更大的吞吐量。

应用范围广。工作在4层，所以它几乎可以对所有应用做负载均衡，包括HTTP、数据库、在线聊天等。