“

1. 为什么负载均衡一般采用混合方式

2. 七层负载为什么比四层负载性能要低？

3. 四层负载概念真的对吗？

4. 文章较长，各位能不能持久到最后？

在正式开篇之前，先说几个瓜：

1. 硬件负载均衡的性能最高，其次是软件负载均衡的四层负载，最差的是七层负载，那为什么七层负载均衡反而应用最广泛呢？

2. 一般公司都会采用混合型的负载均衡，为什么四层负载一定要在七层负载之前呢？

说到负载均衡，目前可以说是程序员面试中的基础题了，如果连负载均衡都没搞过，B格多半会掉好几个层级。遥想很多年前单体时代，一个玩过负载均衡的程序员可是很吃香的，出去面试算是自带Buffer的那种。无论如何，在分布式横行的现代撸码过程中，负载均衡已然成为微服务乃至ServiceMesh中不可或缺的一部分。

负载均衡按照工程来说，都是围绕“分”字来做的，无论是硬件负载均衡还是软件负载均衡，最终目的都是为了提高系统整体的负载能力。

负载均衡分类

硬件负载均衡

典型的代表是F5，价格比较昂贵，一般中小企业不愿意采用。性价比不是F5的优势，F5有行业最全面和最领先的解决方案，志在为客户提供更加安全、智能、高效的应用服务。

硬件负载均衡独立于实际应用系统，所以它感知不到后端应用的状态，由于它处于网络层，所以要想做到自动踢出有问题的业务服务器比较难。

优点：能够直接通过智能交换机实现,处理能力更强，而且与系统无关，负载性能强，更适用大访问量、大企业使用

缺点：成本高，除设备价格高昂，而且配置比较麻烦，需要专业的运维人员去搞。

软件负载均衡

根据软件负载均衡中均衡器所在的OSI网络模型中的层次，业界把负载均衡分为了四层负载和七层负载。它们有着自己的优势和劣势，下边会详细的讲解。

优点：基于系统与应用的负载均衡，能够更好地根据系统与应用的状况来分配负载。这对于复杂应用是很重要的，性价比高，实际上如果几台服务器，用F5之类的硬件产品显得有些浪费，而用软件就要合算得多，因为服务器同时还可以跑应用做集群等。

缺点：负载能力受服务器本身性能的影响，性能越好，负载能力越大。

四层负载

无论是四层负载均衡还是七层负载均衡，都离不开OSI七层网络模型，如果你大学没有掌握，现在再给你一次机会

数据链路层负载

通过OSI七层网络模型可以知道，数据链路层传输的内容是“帧”，数据帧的格式这里不做详细介绍，我们只需要知道它包含了来源MAC地址和目标MAC地址，每一个MAC对应一个网卡或者说对应一台服务器（多网卡的服务器除外）。

数据链路层负载均衡器的工作就是修改接收到的数据中的目标MAC地址，把目标MAC地址修改为真实服务器的MAC地址，修改之后，交换机会根据修改之后的MAC地址，把请求发送给真实的处理服务器，由于只修改了目标MAC地址，并没有涉及网络层数据的修改，所以上层依然可以正确的进行数据处理。

“

OSI七层模型中，每一层关注的数据并不相同

在数据链路层只能做到修改MAC地址，这也就意味着目标机器必须要和负载均衡器能够联通才可以，不可以跨越网段，一般情况下，他们都处于同一个子网中。

“

计算机要想正确的处理请求，数据包中的MAC和IP地址必须要和自己对应，所以数据链路层负载均衡模式中，真实服务器的IP要和负载均衡器一样才可以，这也是VIP的用武之地

数据包的返回道理类似，只要目标机器的IP和MAC正确，服务器就可以直接把数据包返回，在数据链路层负载中，这两个数据并没有被修改，所以真实服务器处理完请求就可以绕过负载均衡器而直接返回数据包，整个的流程如下：

网络层负载

在OSI的网络层中，数据包中最重要的包含了请求的目标IP和来源IP，和数据链路层道理类似，网络层的负载均衡设备是通过修改目标IP来达到负载均衡的目的。交换机把请求转发到真实服务器之后，由于IP和MAC就是当前真实服务器IP和MAC，所以数据包可以被正确处理。

但是，当应答数据包返回的时候就有问题了，由于数据包目标IP被修改为了真实服务器IP（原来为负载均衡器的IP），如果直接返回给来客户端服务器，数据包将不会得到处理。因此，只能将应答数据包重新发回负载均衡器，负载均衡器把应答IP修改为自己的IP再发回客户端服务器，这样才可以保证和客户端服务器的正常通信。

相比较数据链路层负载来说，通过修改来源IP方式的负载均衡方式性能是比较低的，因为数据包的返回需要再次经过负载均衡器，这不仅使负载均衡器的工作量增加，而且占用了更多的出口带宽。

“

其实还有一种数据包二次包装的方式来实现网络层负载均衡，负载均衡器在真实的数据包外层又增加了一层数据包，然后发往真实处理服务器，有兴趣的同学可以研究一下“IP隧道”

七层负载

四层负载均衡通过直接修改数据包的方式来达到负载均衡功能，此时，客户端和真实应用服务器本质上维持着同一条TCP通道，或者说，OSI模型的下三层的数据包还未到达真实服务器。

当数据包一旦到达真实服务器，也就是OSI是上四层，数据包的MAC和IP地址就无法被修改了。所以基于七层的负载均衡器只能通过代理的方式把数据包发送给后端真实的服务器，这个过程会新建TCP连接，这也是七层负载均衡性能要比四层负载均衡器性能要低的重要原因。

而且，由于七层负载均衡器，无法修改IP和MAC信息，所以应答数据包只能通过再次返回负载均衡器的方式来应答客户端服务器，这同样会降低负载均衡器的性能以及占用出口带宽问题。

由于七层负载均衡器工作在应用层，它能够明确的感知应用层的协议内容，比如最常见的Http协议。这样就可以根据协议的具体内容来实现更加灵活的控制规则，像Nginx最常见的Session粘性规则，或者对资源的缓存等。

负载均衡策略

DNS响应均衡（Flash DNS）

在Internet上，无论是HTTP、FTP或是其它的服务请求，客户端一般都是通过域名解析来找到服务器确切的IP地址的。在此均衡算法下，分处在不同地理位置的负载均衡设备收到同一个客户端的域名解析请求，并在同一时间内把此域名解析成各自相对应服务器的IP地址（即与此负载均衡设备在同一位地理位置的服务器的IP地址）并返回给客户端，则客户端将以最先收到的域名解析IP地址来继续请求服务，而忽略其它的IP地址响应。在种均衡策略适合应用在全局负载均衡的情况下，对本地负载均衡是没有意义的。

轮循均衡（Round Robin）

这是最简单的一种负载均衡策略，每次网络请求都会依次分配给后端服务器，即：第一个请求分配给第一台服务器，第二个请求分配给第二台服务器，以此类推，然后不断重复循环。

如果后端服务器配置不尽相同，可能会造成有的服务器负载过高或者负载过低的现象。

权重轮循均衡（Weighted Round Robin）

此策略在轮训的基础上增加了权重的概念，根据服务器的处理能力分配不同的权重，处理能力强的权重会高一些，处理能力低的权重会低一些，这在一定程度上平衡了服务器处理能力，也很好的提高了服务器的利用率，尽量避免了造成服务器负载过高或过低的极端情况。

随机均衡（Random）

说实话，这种策略不提也罢，我觉得没有任何意义，本质上和轮训策略没有什么不同。

一致性哈希均衡（Consistency Hash）

一致性哈希策略其实是一种比较重要的规则，负载均衡器可以根据请求中的某些数据特征保证同样的请求会分配给同样的处理服务器，也就是会话粘性。最常见的，我们在nginx中利用此策略来实现Session机制，可以保证同一个用户的请求被分配到同一台服务器上，这种一致性的结果，就可以做很多事情了，完全可以玩出进程内缓存的花样。

响应速度均衡（Response Time）

响应速度策略是依据负载均衡器和真实服务器之间的响应时间来确定的，这种策略理论上可以自动踢出有故障的服务器，因为服务器超时或者无响应，负载均衡器将不会分配请求到此服务器。

最少连接数均衡（Least Connection）

这种方式可以保证每台真实服务器的连接均衡，站在连接数的维度来说，这才是真正的均衡，但是会造成不同配置的服务器的过高或者过低负载的现象发生。

故障探测

一个好的负载均衡器一定会有自动故障探测功能，即：当后端服务器发生问题或者down机的时候，会自动剔除有问题的服务器。一般主流的探测方式有以下几种：

1. Ping侦测：通过ping的方式检测服务器及网络系统状况，此种方式简单快速，但只能大致检测出网络及服务器上的操作系统是否正常，对服务器上的应用服务检测就无能为力了。

2. TCP Open侦测：每个服务都会开放某个通过TCP连接，检测服务器上某个TCP端口（如Telnet的23口，HTTP的80口等）是否开放来判断服务是否正常。

3. HTTP URL侦测：比如向HTTP服务器发出一个对main.html文件的访问请求，如果收到错误信息，则认为服务器出现故障。

写在最后

负载均衡已经成为了分布式中不可或缺的基础设施，基于四层负载的高性能和七层负载的高灵活性，很多公司都是采用混合型负载均衡，流量的入口处为四层负载，有的甚至有多层四层负载，四层负载之后是七层负载，然后是真实服务器。例如最常用的部署架构为：四层的LVS+七层Nginx+真实服务器，这也是为了把每层的负载均衡的优势最大化的一种体现。

END

往

期

回

顾

原创

一个搜索需求搞垮微服务

原创

微服务并不能解决你的烂代码问题