目录
3.2.2 为什么Real Server需要处于同一个局域网内？
前言
在互联网发展早期，由于用户量较少,业务需求也比较简单。对于软件应用，我们只需要一台高配置的服务器，把业务所有模块全单机部署，这样的软件架构模式称为单体架构模式。
随着用户量的增加，客户端请求的并发量越来越大，在这个过程中单体架构会产生两个问题。
为了解决上述的问题，我们引入了将应用进行分布式集群化部署的架构，分为两种水平架构部署和垂直架构部署。
但是新的架构设计有两个问题亟待解决：
一：负载均衡概述
为了解决前言中提到的两个问题，于是引入了负载均衡技术的设计。简单来说负载均衡的核心目的就是做分治，将客户端的请求均匀的分发到多台目标服务器上，并支持目标服务器动态上下线的功能。
由于进行了分治处理，目标服务器多台的性能得到了释放，因此能够接受更大的客户端请求并发，实现了高并发负载均衡的目标。
那负载均衡的具体实现是什么呢？
首先第一种方案，在客户端层面做负载均衡显然是不可取的，因为每一台Real Server服务器都有一个提供服务的RIP,如果让客户端记录所有的Real Server对应的RIP显然是非常荒谬的。
比如想象这样一件事，百度的网页放在了多台Tomact目标服务器上部署，比如今天突然百度新上线了一台Tomcat服务器，难道要打电话给所有使用百度的用户，告诉他们新的Tomact服务器的IP地址，让后让他们去访问新的Tomcat服务器？这显然是不对的。
第二种方案显然是可行的，其基础设计图如下:
注意：在这种设计模型下，客户端其实根本就不知道后端服务器集群是否使用了负载均衡，这对客户端都是透明的，客户端只要向后端服务器集群暴露的统一流量入口VIP发起请求就行了，其内部是如何进行请求分发的，对客户端来根本就不重要。
此时我们再想一个问题，Real Server为啥要集群化部署呢？还不是因为单台Real Server扛不住很高的并发因此需要集群化部署。那么疑问就来了，为啥单台Real Server抗不住的并发，需要多台Real Server才能抗住的并发，单台负载均衡服务器就能抗住？
二：为啥负载均衡服务器这么快呢？
负载均衡服务器的功能是将客户端的请求均匀的分发给目标服务器，其是否快的根本原因就是在于计算机接受请求数据包->处理请求数据包->发出响应数据包的这个过程是否是足够快。
2.1 七层应用程序慢的原因
如上图所示应用程序服务器例如Tomcat等，是属于应用层的服务器，属于OSI七层的服务器。
2.2 四层负载均衡器LVS快的原因
首先LVS在逻辑上到了四层但又没有到四层，逻辑上到了四层是LVS只是看了一下请求报文中的目标地址和端口。如果是LVS负载均衡服务器的IP地址和端口号就进行负载，否则就不进行处理。
之所以需要看请求报文中的目标地址和端口号的本质目的就是，一台计算机上有很多端口号，但只有负载均衡器监听的端口号才需要进行处理。
之所以说LVS又没到四层的原因是，LVS在传输控制层不需要进行三次握手，只是看了一下端口号。
但是一定要注意的是使用LVS负载均衡服务器的时候，Real Server必须是镜像，也就是提供完全一样的服务。
三：LVS负载均衡器的三种模式
3.1 NAT模式
NAT模式实现LVS图示
3.1.1 什么是NAT模式
3.1.2 NAT模式实现LVS的缺点
这里着重讲一下上述第三点的原理
首先负载均衡机制的核心目的是让客户端的请求合理均分地分发给多台目标服务器上。其本质地目的是用多台目标服务器均摊客户端请求流量，以便能够承载更大地并发。那么目标服务器地响应应该由目标服务器直接返回给对应的客户端即可。这样LVS只需要承担客户端请求的网络带宽，而目标服务器响应的网络带宽由多台目标服务器共同承担，自然LVS的吞吐量就上升了。
请求和响应数据包大小不对称很常见，比如我们打开网页请求百度的主页。在这个情景下，请求数据包很小，但是响应数据包确实整个页面的文字和图片，响应数据包比请求数据包大很多，而请求和响应数据包都经过LVS，这种不对称，会进一步降低LVS的吞吐量。
3.1.3 NAT模式的注意事项
看看3.1的图例Real Server处理完客户端的数据包后，会封装(RIP->CIP)的响应数据包，如果默认网关不配置成LVS负载均衡服务器，这个响应数据包很可能不经过LVS负载均衡器将数据包转换为(VIP->CIP),就直接返回给客户端。但客户端发出的请求数据包确是(CIP->VIP)，因此(RIP->CIP)的数据包会被直接丢弃。
Real Server响应数据包在NAT模式下必须要经过LVS服务器做S-NAT之后，由LVS负载均衡器将数据包返回给客户端，
3.2 DR模式
DR模式重要的几个特点：
3.2.1 什么是MAC欺骗？
如上图所示LVS服务器接收到（CIP->VIP）的数据包之后，其并没有做D-NAT转换，修改其IP到某一台RIP。而是通过Real Server调度算法，选择一台目标服务器，根据其RIP通过arp协议获取到RIP对应的MAC地址，封装到当前数据包的MAC头上。
客户端请求的目标地址就是VIP，就是LVS负载均衡服务器本身，本应当接收包，但是却通过修改MAC地址到另一台Real Server的MAC地址而将数据包转发出去的过程称为MAC欺骗。
重点：MAC欺骗是基于二层数据链路层的技术，其速度要比基于四层的NAT技术要快。
3.2.2 为什么Real Server需要处于同一个局域网内？
在进行LVS部署的时候，需要注意同一台LVS负载均衡服务器所负载的多台Real Server需处于同一个局域网内。
3.2.3 如何实现VIP的对内可见，对外隐藏
因为需要达到目标服务器直接向客户端返回响应的目的，所以目标服务器返回的数据包应该是 （VIP->CIP），也就是说目标服务器Real Server 需要具备VIP的网络接口。
但是互联网中自然不能出现多个相同的VIP地址，所以只有负载均衡器LVS，能够将VIP暴露到公网中，而每一个Real Server都应该知道自己有VIP，但不能将VIP暴露出去。
那么如何实现VIP的对内可见，对外隐藏呢？
3.2.4 为什么DR模式要快
上面讲过NAT模式，这里讨论DR模式为什么要比NAT模式快，其原因主要有以下几点：
3.3 TUN隧道模式
DR模式的痛点：
DR模式虽然相较于NAT模式性能有较大的提升，但是其限制LVS服务器需要和所有的Real Server在同一个局域网中。无法突破地域的限制。
TUN隧道模式目的就是突破地域的限制，使得LVS服务器和所有的Real Server可以部署在不同的局域网中。
设计图：
3.3.1 实现原理
如上图可以知道在TUN隧道模式下，LVS负载均衡服务器在转发数据包前通告Real Server调度算法选择一台Real Server，且在目标数据包外层再封装一个（VIP->RIP）的数据包。这种情况可以理解为"数据包背着数据包"。
在这种情况下外层数据包是由(VIP->RIP),因此不需要做基于二层数据链路层的MAC欺骗，直接将数据包转发给Real Server，因此LVS服务器和Real Server自然不需要在同一个局域网内部署。
3.3.2 优缺点
四：Real Server调度算法
每种调度算法的详情可见：LVS的12种Real Server调度算法
4.1 如何监控每台Real Server的负载情况？
在使用动态调度算法的时候，需要监控各个Real Server的负载情况，比如连接数指标，那么LVS负载均衡器是如何知道每台Real Server上建立了多少长连接呢？
注意：在DR模式和TUN隧道模式下，Real Server的响应数据包会直接发回给客户端，不会经过LVS服务器，因此三次握手的全过程并不能完全监控到，四次握手也是如此。
4.2 客户端长连接
首先一定要明白的一点是LVS负载均衡服务器不会与客户端建立连接，也不会与Real Server建立连接，真正建立连接的是客户端与目标服务器。
