企业官网建设流程全解析

负载均衡这事，做过线上业务的人都懂，入口流量大了之后，单台服务扛不住，加机器是必然的，但加完机器之后怎么把请求均匀打到后端、怎么在某一台挂了之后自动摘除，才是真正折腾人的地方。硬件负载均衡设备效果好但贵，软件方案里Nginx性能不错却偏七层，要是纯四层高流量转发，LVS依然是绕不开的经典方案。这篇主要把LVS的NAT、DR、TUN三种搭建方式掰开揉碎讲清楚，包括我实际操练时的环境配置、踩过的坑、以及最后为什么在不同场景下选择了不同模式，希望对正在研究这块的人有实在的参考作用。

1. 整体思路：先把LVS三种模式的核心差异搞明白

1.1 LVS到底是什么，为什么四层负载均衡还要分模式

LVS全称是Linux Virtual Server，工作在TCP/UDP四层，原理说白了就是通过内核里的ipvs模块，把进来的流量按预设规则转发给后端真实服务器，再由真实服务器把响应返回给客户端。它不像Nginx那样需要解析HTTP协议，所以吞吐量高、性能损耗小，特别适合大流量的TCP长连接和UDP场景。

但选择模式之前得先想清楚一个关键问题：数据包从客户端进来之后，从负载均衡器到后端，再从后端回给客户端，这条路径要怎么走？三种模式的本质区别就藏在这里。有的模式是双向流量都经过负载均衡器，有的模式是请求经过、响应直连，有的模式干脆把数据包用隧道封装丢出去。理解了这个路径问题，后面搭建起来才不会蒙蒙的。

1.2 三种模式的直观区别与适用场景速览

NAT模式最容易被理解，因为它跟常见的端口转发、反向代理思路一致：客户端访问VIP，负载均衡器把目标地址改写成后端真实IP，后端处理完后把响应原路返回给负载均衡器，再由负载均衡器改回源地址交给客户端。整个过程里，负载均衡器是必经之路，所以后端服务器完全可以只保留内网IP，安全性和隔离性最好，但问题也很明显——进出流量都压在同一台设备上，很容易成为瓶颈。

DR模式的做法是完全不一样的，负载均衡器只负责把进来的请求通过改写MAC地址转给后端，后端处理完之后，响应包绕过负载均衡器直接以VIP的身份回给客户端。因为出方向不经过LVS，所以性能上限非常高，对大规模业务来说也是最常用的部署方式，但前提是负载均衡器和后端必须在同一物理二层网络，VIP还要在后端服务器上做本地绑定。

TUN模式则把目光放得更远，通过IP隧道把数据包封装转发给后端，后端解封装处理后直接响应客户端。它解决的是跨机房、跨地域的负载均衡需求，让后端服务器不用跟负载均衡器在同一网络，但代价是要额外配置隧道模块，而且运营商偶尔会对封装后的包大小有意见，MTU问题也比较烦人。

用一张对比表来看会更清晰：

这三种模式选型时最核心的判断依据就一句话：后端跟客户端之间的响应路径是否必须经过LVS。如果后端本身就在安全内网里、不需要直接暴露，选NAT；如果追求极致的转发性能且网络条件允许，选DR；如果后端要分布在不同地域还要统一入口，选TUN。

2. 动手准备：环境和内核模块是搭建的基础

2.1 实验环境规划

我实际的实验环境中用了六台机器，全是CentOS 7.9系统，内核版本3.10，Linux发行版的差异对LVS搭建影响不大，但内核必须支持ipvs模块。规划如下：

• 一台做LVS负载均衡器，在NAT模式中充当网关，在DR和TUN模式中只做转发，不做业务处理。
• 两台后端Web服务，安装Nginx并启一个静态测试页面，页面内容分别写上后端主机名，方便后面验证负载均衡效果。
• 一台客户端用来测试访问效果。
• 三套模式共用同样的后端服务，只是网络拓扑和IP配置不同。

NAT模式测试时，因为负载均衡器要充当内网网关，我给它配了两块网卡，一块接外网测试网段，一块接内网后端网段。DR模式测试时把所有机器放到同一个网段里，不再区分内外网。TUN模式测试时后端服务器用了另一段IP，模拟跨网段的效果。

2.2 安装与检查LVS核心组件

LVS本身不需要安装额外的用户态软件也能运行，因为ipvs是内核内置模块，但管理规则的工具ipvsadm必须要装。CentOS里直接执行：

yum install -y ipvsadm

装完之后立刻确认内核模块是否加载成功：

modprobe ip_vs lsmod | grep ip_vs

能看到ip_vs相关输出才算正常。如果lsmod里没有内容，检查一下内核是否支持，一般默认是支持的。为了确认管理命令可以正常工作，顺手执行一下ipvsadm -L，如果没有报错，说明基础环境没问题。

注意：虽然LVS工作在四层，但后端服务本身依然可以上七层的东西，比如Nginx、Tomcat、MySQL。LVS只负责把TCP/UDP包转发过去，业务协议完全无感知。这也是万能搭法的原因所在。

2.3 网络配置前必须先想清楚转发问题

配置LVS之前，建议先把操作系统的转发开关打开，尤其NAT模式必须开，因为负载均衡器要当作路由器来用。即使DR模式不依赖转发，我也顺手开了，免得后续调其他功能时多一道排查阻碍。

echo 'net.ipv4.ip_forward = 1' >> /etc/sysctl.conf sysctl -p

sysctl -p执行完不会有提示，但通过cat /proc/sys/net/ipv4/ip_forward确认输出是1就说明生效了。这一步看似简单，却是很多人搭了半天不通时的第一大元凶——转发开关没开，NAT模式的响应包就永远回不来。

3. NAT模式搭建：最直观但最容易出问题的模式

3.1 NAT模式的网络拓扑与IP规划

NAT模式的请求流向是客户端访问VIP、LVS做DNAT改写、后端处理、LVS再SNAT返回给客户端，因此IP规划必须分清楚哪段是外网哪段是内网。我的规划如下：

• LVS外网网卡eth0：192.168.200.100/24，此IP就是VIP，客户端访问的入口。
• LVS内网网卡eth1：192.168.10.100/24，此IP作为后端服务器的网关。
• Web后端A：192.168.10.10/24，网关必须指向192.168.10.100。
• Web后端B：192.168.10.20/24，网关同样指向192.168.10.100。
• 客户端：192.168.200.50/24，跟LVS外网同网段。

网关这一点必须要反复确认：NAT模式下的后端服务器默认网关必须指向LVS的内网IP，别默认指向自己网段内的路由器。否则后端把响应包扔出去后，根本不知道往哪走，连接直接卡死在半路。

3.2 后端服务器的Nginx配置

后端Nginx页面干扰项越少越好，我直接改默认首页来标记身份。在两台后端机器分别执行：

echo "Backend Server A - 192.168.10.10" > /usr/share/nginx/html/index.html echo "Backend Server B - 192.168.10.20" > /usr/share/nginx/html/index.html

然后启动Nginx，用curl在本地验证一下：

curl http://127.0.0.1/

能看到对应后端标记就算OK。Nginx的端口默认80，生产环境如果改了端口，注意后面ipvsadm规则里的端口要跟后端实际监听端口保持一致。

3.3 在LVS上添加NAT模式的转发规则

配置核心就在ipvsadm这条命令链路上。先清空历史规则：

ipvsadm -C

然后定义VIP和调度算法。这里用轮询算法rr来演示，生产环境根据业务特点再换成wrr、lc这些带着权重的算法。完整规则如下：

ipvsadm -A -t 192.168.200.100:80 -s rr ipvsadm -a -t 192.168.200.100:80 -r 192.168.10.10:80 -m ipvsadm -a -t 192.168.200.100:80 -r 192.168.10.20:80 -m

注意每条参数的含义：-A表示添加虚拟服务，-t表示TCP协议加VIP地址和端口，-s rr表示调度算法是round-robin轮询，-a表示添加后端真实服务器，-r指定后端地址和端口，最后的-m关键中的关键，代表NAT模式的全称masquerade。如果这里不小心写成-g，流量就直接从另一条路走了，整个实验逻辑都变了。

配置完毕后立刻查看规则和转发计数：

ipvsadm -L -n ipvsadm --stat

初始状态下转发计数都是0。

3.4 验证NAT模式转发效果

在客户端机器上连续请求VIP：

for i in {1..10}; do curl -s http://192.168.200.100/; echo; done

正常情况应该看到响应交替出现，一半是Backend Server A，一半是Backend Server B，说明轮询调度生效了。再回到LVS上看统计：

ipvsadm -L -n --stats

会发现ActiveConn和InOctets都在增长，而且两台后端机的数据基本上是等比例增加的。同时Iptables里的NAT表也能看到动态建立起来的映射关系。

这个模式我实操中最常碰到的现象是：curl VIP的时候卡住不返回，或者返回了但速度极慢。十有八九是走后端的默认网关忘记改了。判断方法很简单，在LVS上用tcpdump抓内网网卡流量，看有没有来自后端IP的响应数据，再看这些数据是不是发给了LVS的内网口。只要响应方向不对，整个链路就断掉了。

还有一个隐蔽的点，防火墙规则清理。我实验中直接把firewalld停掉避免干扰，如果生产环境需要保留防火墙，必须在Iptables里放行VIP端口和所有后端网段的访问，否则进来的连接被DROP后连报错的机会都没有。

注意：NAT模式下，后端服务器千万不要再配置VIP，也不需要配置回程路由之类的内容，只需要把网关指到LVS。后端对客户端IP的感知会统一显示为LVS的内网地址，这种设计天然带有地址隐藏的效果。

4. DR模式搭建：高并发场景的主力模式

4.1 DR模式的关键思想与网络前提

DR模式的转发原理是，负载均衡器收到客户端请求后，通过改写数据链路层的目标MAC地址，把包直接交给某一台后端服务器的物理网卡，后端处理完包之后，直接把响应包以VIP为源地址发回客户端。整个过程中，负载均衡器完全不出现在响应路径上，性能上限因此非常高。

但这个模式有一个硬性前提：LVS和后端必须处于同一个广播域，也就是说，它们之间的二层网络是可达的。如果中间隔了三层路由，MAC改写这套玩法就完全失效了，必须改走TUN模式。

4.2 全部机器同一网段的IP规划

我的DR模式实验IP规划如下：

• VIP：192.168.100.100/24，由LVS对外提供。
• LVS实际物理IP：192.168.100.10/24。
• 后端Web A物理IP：192.168.100.11/24。
• 后端Web B物理IP：192.168.100.12/24。
• 客户端：192.168.100.200/24。

全部在同一个192.168.100.0/24网段内，这样才能保证MAC改写可以直达后端。

4.3 LVS上配置DR模式转发规则

先清空规则，然后添加VIP，调度算法还是选rr方便演示：

ipvsadm -A -t 192.168.100.100:80 -s rr ipvsadm -a -t 192.168.100.100:80 -r 192.168.100.11:80 -g ipvsadm -a -t 192.168.100.100:80 -r 192.168.100.12:80 -g

这里的-g参数就是director routing，代表DR模式。注意后端地址的端口80跟VIP端口保持一致，因为DR模式下包的目标端口不会被改写，后端服务必须监听跟VIP一样的端口。如果后端Nginx换了端口，DR模式下就不太灵活了。

配置完成后查看规则：

ipvsadm -L -n

可以看到输出中每台后端的Forward列是Route，说明走的是DR模式。

4.4 后端服务器绑定VIP并抑制ARP响应

DR模式下后端服务器内核里也要有VIP，但绝不能宣告自己拥有VIP，否则客户端的ARP请求一来，后端机器也会抢着响应，整个网络就乱了。官网习惯的解法是在回环地址lo上绑VIP，同时用sysctl调整ARP响应策略。

后端两台机器分别执行：

ifconfig lo:0 192.168.100.100 netmask 255.255.255.255 up route add -host 192.168.100.100 dev lo:0

注意子网掩码写死成四个255，目的是不让后端机器通过ARP广播宣告这个地址在局域网内存在，只在本地悄悄收包。

然后在/etc/sysctl.conf里追加下面四行：

net.ipv4.conf.all.arp_ignore = 1 net.ipv4.conf.all.arp_announce = 2 net.ipv4.conf.lo.arp_ignore = 1 net.ipv4.conf.lo.arp_announce = 2

执行sysctl -p使配置生效。这套参数的含义解释一下：arp_ignore=1的意思是本机只回答目标IP是本机网卡物理IP的ARP请求，不回应对VIP的请求；arp_announce=2的意思是ARP通告时尽量使用网卡物理IP来回应，避免对外通告VIP。两者配合，VIP就成了只有LVS能广播、后端只埋头收包的透明地址。

这块是整个DR模式搭建中最容易翻车的点。我见过不少人在这一步只加VIP不调ARP参数，然后整个业务时就通时断，网络里到处是ARP冲突的提示。正确顺序是先改内核参数、再做lo:0配置，顺序反了有时候配置文件会被默认策略覆盖掉。

4.5 DR模式验证方法与观察指标

客户端发起持续请求：

for i in {1..10}; do curl -s http://192.168.100.100/; echo; done

正常情况响应依然交替出现。这时候去LVS上看统计：

ipvsadm -L -n --stats

能看到两个后端的流量分配均衡。进一步验证DR模式的特点是去看响应路径——如果在后端Web A上执行tcpdump抓包，会看到来自客户端的请求包，同时也能看到回复给客户端的响应包直接发往客户端IP，根本没有经过LVS。

从实际性能测试的感受来说，DR模式下LVS的CPU占用率确实低得惊人。我试过用压测工具打满后端，LVS那台机器CPU却一直徘徊在个位数，整机处理瓶颈全在后端。这就是DR模式一直霸榜的终极原因。

注意：DR模式对后端的要求是必须支持配置VIP和ARP内核参数，这在绝大多数Linux发行版里都没问题，但像Windows后端、或者某些云主机不支持自定义网卡IP的托管环境里就麻烦了。用手里的环境试一试，如果虚拟交换机把lo:0的VIP包给过滤了，就只能换NAT或TUN。

5. TUN模式搭建：跨地域容灾的正确打开姿势

5.1 TUN模式的封装原理与适用边界

TUN模式全称是IP Tunneling，思路是把进来的数据包再用一层IP头部封装起来，通过物理网络转发给后端，后端收到后解封装恢复成原始请求，处理完成后直接以VIP为源地址回客户端。因为封装过程避开了二层MAC寻址的限制，负载均衡器跟后端完全可以是跨机房的不同网段，只要三层网络能通就能工作。

这个模式的适用场景很明确：异地多活、跨机房容灾、后端分散在不同地域的架构。但反过来也要清楚它的代价——每发一个包都要多一层IP头部开销，MTU问题也会时不时蹦出来。

5.2 跨网段环境下的IP规划

按跨网段的思路规划：

• VIP：192.168.200.100/24，配置在LVS的eth0上，客户端访问入口。
• LVS物理IP：192.168.200.10/24。
• 后端Web A物理IP：192.168.20.11/24，与LVS不同网段。
• 后端Web B物理IP：192.168.20.12/24，与LVS不同网段。
• 客户端：192.168.200.200/24。

LVS到后端之间要保证路由可通，我实验里直接通过中间路由器实现两个网段的互通，生产环境里当然就是机房专线或者内网互联。

5.3 两端内核隧道模块的加载配置

TUN模式需要ipip模块，先检查：

modprobe ipip lsmod | grep ipip

LVS和后端所有机器都要加载这个模块。加载成功后在LVS上配置虚拟VIP和转发规则，跟DR模式的区别只在最后一条参数：

ipvsadm -A -t 192.168.200.100:80 -s rr ipvsadm -a -t 192.168.200.100:80 -r 192.168.20.11:80 -i ipvsadm -a -t 192.168.200.100:80 -r 192.168.20.12:80 -i

这里的-i就是IPIP隧道模式。

后端的配置跟DR模式略有不同，不是绑到lo:0，而是要建立一个tunl0隧道口并把VIP绑上去：

ifconfig tunl0 192.168.200.100 netmask 255.255.255.255 up route add -host 192.168.200.100 dev tunl0

同样需要设置ARP抑制，参数跟DR模式一样：

net.ipv4.conf.all.arp_ignore = 1 net.ipv4.conf.all.arp_announce = 2 net.ipv4.conf.tunl0.arp_ignore = 1 net.ipv4.conf.tunl0.arp_announce = 2

注意这里把默认枚举网卡替换成了tunl0这一项，确保后端不会通过tunl0对外宣告自己拥有VIP。

5.4 TUN模式的验证与MTU坑处理

配置完成后，在LVS上用tcpdump看封装过程：

tcpdump -i eth0 host 192.168.20.11 -n

正常会看到IPIP协议的包，也就是协议号4的封装包。客户端持续请求时，响应流量依然由后端直接返回。因为响应不经过LVS，出方向性能也不错。

TUN模式最磨人的是MTU问题。原始请求数据包本来是标准的1500字节MTU，封装后变成1540字节左右，如果链路中某一跳设备的MTU设置比较小，就会出现能连上但传输大内容时卡住或丢包的情况。解决思路是调整网络设备的MTU设置，或者让后端服务的TCP MSS降下来，具体做法是在后端的iptables里加入：

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

这句的作用是让TCP握手阶段自动探测路径MTU，协商出一个不会分片的MSS值。不过实测下来最稳妥的还是优先保证整条链路MTU统一。

注意：TUN模式实验完成后要记得把隧道接口和VIP配置清理掉，如果直接带着tunl0配置去调DR模式，ARP参数可能会冲突，我踩过一次这样的坑，排查到怀疑人生才想起来是上一个实验的残留。

6. 三种模式的选型建议与性能印象

三种模式放在一起对比，选型的逻辑其实特别简单。

如果你的应用跑在纯内网环境，后端不希望对客户端暴露任何真实地址，或者你的负载均衡器需要顺带做安全过滤，NAT模式足够用了。搭建成本低、理解成本低，运维接手也容易。它最大的软肋是处理性能受限于单台LVS的进出流量总和，如果业务高峰期总流量超过几Gb这个量级，就得考虑升级方案了。

DR模式在大多数IDC机房场景下都是最优解，它是三个模式里吞吐上限最高的，LVS这台机器的瓶颈几乎不存在，因为出方向流量根本不过它。代价是你必须保证后端服务器跟LVS在同一个二层域，而且每台后端都得老老实实配置lo:0和ARP抑制参数。目前大型互联网业务里核心入口的负载均衡绝大多数用的是DR模式，这么多年下来稳定性是被验证过的。

TUN模式是跨机房场景的救星，但别因为封面好看就无脑上。封装开销、MTU问题、隧道维护这些都是额外成本。除非你确实有分布式多地部署的硬需求，不然同机房场景优先DR，不想折腾二层就直接NAT，TUN留到真有跨地域需求时再上也不迟。

就我个人操练完这三套环境后的体会是：LVS最大的门槛不在命令本身，而在于理解数据流向。同一个VIP、同一套后端，NAT模式下后端网关指错就全断，DR模式下ARP参数写错就半通半断，TUN模式下隧道口少配一个就封装失败。命令就那么几条，真正决定成败的是你对网络每一层细节的把控程度。

建议有条件的话，把三种模式在真实环境里各搭一遍，搭的时候开着tcpdump盯数据流向，亲眼看着数据包从入口到后端再到返回，比看一百篇文档都管用。一开始不要上复杂的调度算法，rr轮询足够用来验证链路，链路通了再去折腾wrr权重、wlc最少连接这些高级玩法。记住一个原则：先跑通最简单的路径，再逐步叠加功能，排错时沿着数据流的方向一段一段查，比漫无目的地猜要高效太多。

这套内容多半过个五年也还实用，因为LVS不是某个版本里的一次性功能，而是内核级的稳定能力。把三种模式的原理和配置逻辑吃透了，以后不管公司网络架构怎么变，你都能很快找到对应的落地方案。