四层负载均衡技术

通常使用的nginx负载均衡技术， 在网络分层中处于应用层（第七层），nginx与客户端建立连接（握手），然后再根据请求信息以及本地配置信息，将请求灵活的分发到不同的服务上。nginx这类7层负载均衡的优缺点都很明显。

除了nginx这种7层负载均衡策略，还有基于传输层（4层）的负载均衡策略。通过分析请求的 IP地址以及端口号 进行请求的负载均衡。根据请求处理模式的不同，4层负载均衡 算法 可以分为： NAT , DR 以及 TUN隧道技术 等。4层负载均衡的实现方式有： LVS 。

NAT(Network Address Translation，网络地址转换)技术，在专用内部网络中，分配一台实现了NAT技术的路由或服务Load Balance Service。这台负载均衡服务器分配了公网IP(VIP, Virtual IP)，所有客户端请求服务都请求此IP。LB通过不同的算法，将请求数据包的源IP以及目标IP修改，转发到真实服务器（Real Service）上进行业务处理。其具体的步骤可以分为：

可以看到通过NAT模式进行负载均衡，所有的请求以及响应都要通过LB服务器，当访问量较大时，LB服务器会成为瓶颈 。

DR(Direct Routing, 直接路由模式)，LB通过修改请求数据包的目标MAC地址，并且在Real Service服务配置只有 自己可见的lo:VIP ，实现数据包的接收（自己没有VIP的话，服务并不会接收数据包）。整个转发的流程为：

TUN思想跟DR类似，在Real Service上配置一个内部可见的lo:VIP地址，LB通过封装或修改数据包信息实现请求的转发。不同于DR模式LB修改MAC地址，为了 实现不同网段 的Real Service负载，TUN模式通过在原有的数据包外 封装一层IP Tunnel ，实现数据的转发。由于封装完 IP Tunnel 后数据包和正常的数据包结构不同，所以Real Service的 OS需要支持Tunnel功能 。TUN转发的具体流程为：

LB虽然没有完全解析数据包无法得知请求信息，但是可以通过监听请求头信息（例如，SYN、FIN等）判断客户端与Real Service之间的连接情况。LB通过监听请求信息，维护了各个Real Service的连接信息表。通过这些信息实现不同的调度算法进行负载均衡。

LB将请求依次转发至不同的Real Service

给Real Service分配不同的权值，LB根据RS的权值的高低转发请求

根据请求的目标地址（资源，例如同一URL）进行Hash，转发至RS上

对客户端的域名或者IP进行Hash，转发至RS上

LB将请求转发至连接最少的RS上

LB通过加权轮询以及RS的连接情况来转发请求

LB维护 目标IP到一台RS 的映射表（目标IP最近使用的RS），通过映射表将请求转发至RS，若RS不存在或者超载，通过 最少连接 策略选出一台新的RS进行转发

LB维护 目标IP到一组RS 的映射表（目标IP最近使用的RS），通过 最少连接 策略从服务器组选择一个RS进行转发，若RS不存在或者超载，通过 最少连接 策略选出一台新的RS进行转发，并将此RS加入映射组中。

      在实际生产环境中负载均衡是一个至关重要的位置，负载均衡关乎着整个网站访问的命脉，所以运维人员对于它的处理机制和高可用的重视非常高，负载均衡存在单点故障无疑是对整个网站埋下了定时炸弹，nginx +keeplive实现负载高可用，保障业务持续提供服务避免负载均衡的单点故障。

角色                IP地址                主机名

负载01            10.0.0.2               LB01

负载02            10.0.0.3               LB02

虚拟服务         10.0.0.4                       

      两台nginx负载均衡+keepalive实现负载高可用两台LB的IP地址分别为：10.0.0.2、10.0.0.3 keepalive的vip为：10.0.0.4,当10.0.0.2正常在vip工作在10.0.0.2,10.0.0.3服务出现宕机则vip自动跳转到10.0.0.3的LB

    我们可以看见两台LB中的负载配置相同，server name为vip,当请求到达vip所在的LB服务器则会代理到对应的node池进行负载均衡，通过keepalive的vip漂移为我们的服务提供高可用，保障网站7*24提供服务

         通过演示视频我们模拟LB01宕机，发现vip漂移至第二台LB并且这个切换对于用户是无感知的，今天nginx+keepalive的测试就到这里谢谢！

主备服务器因为硬件或者软件问题（网线松动或者nginx进程）造成keepalived服务无法检测到心跳信息，nginx服务down掉keepalive还在正常运行没有进行主备切换等等都会造成高可用没有达到理想的效果我们可以通过主备机脚本来规避这些因素造成keepalive无法正常主备切换

    主机能不通，VIP在备机则认为非正常主备切换可能主机状态正常vip在主备机都存在

判断主机nginx服务是否正常，如果nginx服务down掉尝试启动，如果nginx尝试启动未成功则停掉主机keepalive服务切换至备机保证业务正常运行  

通过以上两个脚本检测，我们能够做到规避主备之间心跳检测不正常，但是主备机服务正常会存在主备之间都会有VIP导致负载脑裂的问题以及负载服务down掉，keepalive服务正常导致业务中断问题。

---