概述
在网络高并发场景下，单台机器往往是支撑不住大的并发，于是很自然的就联想到需要用多台机器来分担大量的并发，但是对外暴露的IP又只能有一个，于是负载均衡模型就出来了。
本期我们就是要讨论一下这个负载均衡的服务器的几种实现方式。
后端服务慢在哪
我们在考虑如何实现负载均衡服务器之前，先考虑一下为什么后端的server的瓶颈在哪里，发现了瓶颈之后才可以避免出现在负载均衡服务器上。
- 有业务处理，数据库等等读磁盘耗时(负载均衡服务器肯定没有业务，不用读db)
应用层软件，基于7层协议我们知道，tomcat等web服务器是基于7层协议的，需要跟客户端建立三次握手之后才可以开始工作。那么如果我这个负载均衡服务器只实现4层协议，在传输控制层的时候只需要看一眼端口号就封装一个对应的后台IP然后让网络层去转发服务，这样是不是就比传统的7层少了握手的情况，请求会更快呢？我们叫这样的负载均衡为4层负载均衡
4层负载均衡
通过上面的推理，我们已经知道了，负载均衡如果是4层的话转发速度会比7层的要快一点。接下来我们就根据之前学的计算机网络基础知识来推理这个模型的具体实现.
我们先画出这个网路的拓扑图。我们首先要记住一个点，
作为客户端，永远都是访问8.8.8.8他并不知道后面有多少台机器，使用了什么技术，客户端只管往 8.8.8.8发送数据，客户端收到的数据源IP地址不是8.8.8.8的时候，会被网络层丢弃.基于这个前提我们再来考虑如何实现负载均衡。
负载均衡 (D-NAT模式)
当负载均衡服务器收到来自客户端的请求后，随便找了一台服务器把数据转发了过去。如图
如果是直接转发请求包的话，server1的网络层看到目标ip地址不是192.168.1.2就会直接把包给丢弃。所以负载均衡服务器需要做一次转换
这种修改目标IP地址的我们成为D-NAT。继续跟着思路，我们看server1处理完数据之后再把数据发回默认网关192.168.1.1.这时候负载均衡服务器需要把来源的IP地址再改回自己的8.8.8.8返回给客户端。
弊端
我们来看看这种模式有没有什么弊端。我们知道客户端请求服务器往往是很少的数据，而服务端返回的往往是大量的数据，那么假设1W个请求可以同时进入服务器，但是服务器返回的数据可能5000个就把带宽占满了。
负载均衡 DR模型
上面看到了NAT模型的弊端是负载均衡服务器在处理服务器返回数据的时候可能性能会成为瓶颈。主要是因为如果server1直接把数据发给客户端，因为发来的数据源ip地址不正确就会被丢弃。那么我们能不能在发送的时候把源目标地址改成8.8.8.8然后直接发给客户端，那么负载均衡服务器就不用处理返回的数据了呢。如图
上面这个数据，在负载均衡服务器中，一个目标是8.8.8.8的数据包是发送不了给后端的server的，因为自己就是8.8.8.8。但是我们知道数据包其实还可以通过链路层的mac地址进行跳转，所以我们在负载均衡服务器中
修改链路层的代码，直接把下一跳的mac地址写成server1就可以发过去了。当数据包到了server1之后，server1自身也有8.8.8.8这个ip，所以网络层也不会把数据丢弃，所以模型长这样
弊端
这种DR模型下，负载均衡服务器因为修改的是MAC地址，所以规定了server1和负载均衡服务器一定是在同一个局域网内，可以直接通过mac地址跳过去。
