阿里云部署LVS实测：高可用负载均衡搭建踩坑总结

在很多技术团队的认知里，提到负载均衡，第一反应往往是云厂商现成的SLB、ALB，或者直接上Nginx、HAProxy。但在一些对转发性能、网络控制能力、协议适配性要求更高的场景中，LVS依然是一个非常值得认真考虑的方案。尤其是当企业已经有明确的网络规划，希望掌握更底层的流量调度逻辑时，阿里云 部署lvs就成了一个既现实又容易踩坑的技术课题。

本文不讲泛泛而谈的概念，而是结合一次实际搭建经历，完整复盘在阿里云环境中部署LVS高可用负载均衡时遇到的问题、绕过的坑，以及最终稳定运行的架构思路。如果你正在规划基于ECS自建四层负载均衡，或者想理解云上环境和传统机房部署LVS的差异，这篇文章会更有参考价值。

LVS为什么在云上依然有价值

LVS本质上是Linux内核层的负载均衡技术，具备高性能、低开销、支持多种调度算法等优势。相比用户态代理，LVS在处理大量短连接、高并发TCP转发时表现非常稳定。很多团队会疑惑：既然阿里云已经提供成熟的负载均衡服务，为什么还要自己折腾？

答案往往来自三个方面。第一，成本和可控性。有些内部系统流量结构固定，自建LVS在长期运行下反而更经济。第二，协议和拓扑定制。某些特殊业务希望自己控制VIP、调度策略、健康检查逻辑以及后端真实服务器的接入方式。第三，混合架构需求。有些企业并不是把所有流量都挂在云服务上，而是希望把自建网关、WAF、灰度节点、专线环境整合在一套统一链路中，这时候自己掌控LVS会更灵活。

不过，阿里云 部署lvs和物理机房部署最大的区别在于：云网络不是完全透明的二层环境，很多你在线下理所当然能做的动作，到了云上未必成立。尤其是在VIP漂移、ARP处理、Keepalived高可用切换、DR模式网络要求这些关键点上，稍不注意就会遇到莫名其妙的问题。

这次实测的业务场景和架构目标

我们当时需要支撑的是一套内部业务入口，主要承担TCP层流量接入，后端是多台应用服务器。业务方提出了几个明确要求：

• 入口必须高可用，单节点故障不能影响访问。
• 希望负载层尽量轻量，减少额外代理开销。
• 后端节点后续可横向扩容，调度策略可调整。
• 希望在可接受成本内完成，不依赖过多托管组件。

基于这些要求，我们最终选择了两台ECS部署LVS + Keepalived，实现双机高可用；后端挂多台Real Server提供业务服务。最初我们也评估过LVS-DR、LVS-NAT和LVS-TUN三种模式，结果证明，在阿里云环境下，方案选型不是看书本最优，而是看云网络实际支持程度。

先说结论：阿里云上优先考虑LVS-NAT，别轻易迷信DR

很多资料在讲LVS时，都会把DR模式列为“性能最好、最推荐”的模式。没错，从传统数据中心视角看，DR模式确实优雅：请求经过Director，响应由Real Server直接返回客户端，负载机压力小，扩展性强。

但问题在于，DR模式对网络环境要求很高，依赖同一二层广播域，对ARP行为、VIP绑定、报文回流路径都有严格要求。在线下机房，你可以控制交换机、ARP广播、网卡参数，很多问题都能通过网络配置解决。可是在阿里云ECS环境里，你面对的是虚拟化网络、VPC、云平台安全策略以及受限制的二层行为。结果就是，理论上最强的模式，往往在云上最容易失灵。

我们一开始就是按DR思路做实验。两台LVS节点装好ipvsadm和Keepalived，Real Server也配好了lo:0上的VIP，并设置了arp_ignore、arp_announce等参数来抑制ARP响应。按传统经验，这套配置应该能跑起来。但实际测试时，出现了两个典型异常：

1. 客户端偶发访问成功，偶发超时，表现非常不稳定。
2. 主备切换后，VIP虽然漂移了，但流量并没有稳定落到新主节点。

最初我们怀疑是Keepalived配置问题，后来抓包排查才发现，云上虚拟网络环境对这种依赖二层邻居解析和VIP直返的模式并不友好。尤其在不同网卡绑定、辅助IP处理、ARP广播行为不完全可控的情况下，DR模式虽然不是绝对不能做，但实施成本和排障成本明显偏高。

于是我们调整策略，改为LVS-NAT模式。虽然NAT模式下请求和响应都经过LVS，理论上扩展性不如DR，但对于中小规模内部业务入口来说，完全够用，而且在阿里云环境中稳定性明显更好。这个选择后来被证明非常正确。

实际落地架构：两台LVS + Keepalived + 多台ECS后端

最终稳定运行的架构大致如下：

• 两台ECS作为LVS节点，部署Keepalived实现主备切换。
• 一组后端ECS作为Real Server，部署业务服务。
• 通过VPC内网通信，LVS节点负责内外请求的转发与健康检查。
• VIP通过Keepalived在主备之间漂移。
• 后端默认网关或策略路由确保回包经过LVS，满足NAT模式要求。

这里的关键点，不是把软件装上，而是让整个流量路径闭环。很多人在阿里云 部署lvs时失败，不是LVS本身配置错，而是忽略了“请求怎么来、响应怎么回、故障切换时ARP和路由如何更新”这三件事。

第一个大坑：阿里云辅助IP和VIP漂移并不等于传统浮动IP

在线下环境里，Keepalived接管VIP是一件相对直接的事，主节点绑定VIP，备节点不绑定；一旦主节点故障，备节点立刻接管，同网段内通过ARP通告刷新邻居缓存即可。

但在阿里云上，很多人会误以为ECS上直接加一个VIP就等于完成漂移。实际上，云上IP管理往往和底层虚拟网络控制平面密切相关。你在操作系统层面加了一个地址，不代表云网络一定认可这个地址具备完整的收发能力。不同网络产品、不同实例配置下，对辅助私网IP、弹性公网IP、辅助网卡地址的支持方式都不一样。

我们一开始图省事，直接在网卡上手工绑定了一个备用内网IP作为VIP，Keepalived切换时看起来一切正常，ip addr也能看到VIP漂移。但外部访问仍然时好时坏。后来才意识到，云平台网络控制面和系统内核状态并不是一回事。最终我们采用了符合阿里云网络机制的私网IP配置方式，并确保VIP使用的是网络侧可识别、可漂移、可路由的地址，而不是单纯在系统里“伪造”一个IP。

这个问题很典型：很多教程默认你拥有完整二层网络控制权，但云环境下你只拥有“虚拟机里的那一部分网络权限”。所以做方案前，一定先确认阿里云当前网络产品对辅助IP、私网地址绑定、弹性地址关联的实际限制。

第二个大坑：安全组放行了，不代表链路就真的通

这是很多云上排障中最容易浪费时间的一点。我们曾遇到一次现象：客户端访问VIP超时，LVS上抓包能看到请求，后端也偶尔能收到包，但回程异常。团队第一反应是应用没监听或者LVS规则写错，结果查了一圈都没问题。

后来继续排查，发现是安全组、系统防火墙、内核转发参数三者叠加导致的链路不通。云上部署LVS时，至少要同时确认以下几层：

• 阿里云安全组是否放行客户端到VIP对应端口。
• 后端ECS安全组是否允许来自LVS节点的转发流量。
• 系统自身iptables或firewalld是否误拦截了FORWARD链路。
• net.ipv4.ip_forward是否开启。
• rp_filter等反向路径检查参数是否影响回包。

尤其是NAT模式下，数据包会经过转发链路而不仅仅是INPUT链。很多人看到服务端口已放开，就以为网络一定没问题，实际上FORWARD链默认策略、内核转发开关、SNAT/DNAT规则顺序都有可能把包悄悄丢掉。我们的经验是：凡是LVS不通，不要先猜，先抓包。客户端抓、LVS抓、后端抓，一层层确认数据包到底停在了哪里。

第三个大坑：Keepalived能切换，不代表业务就真正高可用

很多部署文章把Keepalived讲得很简单：装上、写个vrrp_instance、配置优先级，主备切换就实现了。可真正上线后你会发现，Keepalived“切换成功”和“业务无感知切换”之间，还差着不少细节。

我们第一次演练主备切换时，Keepalived日志显示非常正常，VIP也到了备机上，ipvsadm规则也都在。但业务侧仍然短暂出现了几十秒访问波动。原因主要有三个：

1. 部分客户端和中间节点存在ARP/邻居缓存未及时更新的问题。
2. 原主机上的连接状态丢失，长连接业务切换时自然会中断。
3. 健康检查脚本只判断Keepalived进程和端口，不判断真实转发能力。

这里尤其要强调第三点。很多人会写一个简单的检查脚本，只要LVS节点本机某个端口还在监听，就认为服务正常，Keepalived继续保持MASTER状态。但实际上，LVS真正的可用性应该至少包含：

• ipvs规则是否存在。
• 后端Real Server是否还有可用节点。
• 本机到后端的健康检查是否成功。
• 必要时是否能完成一次真实业务探测。

后来我们重写了健康检查脚本，不再只看进程，而是结合ipvsadm输出、后端探活结果和实际TCP连接测试综合判断。一旦主节点虽然“活着”但不具备转发能力，就主动降权甚至释放VIP。这样做之后，故障切换才真正接近生产可用水平。

第四个大坑：回包路径错误是LVS-NAT最常见故障源

在阿里云环境中选择NAT模式后，稳定性提升非常明显，但新的重点变成了回包路径控制。LVS-NAT的基本要求是：客户端请求先到LVS，LVS做地址转换后发给后端，后端响应再回到LVS，由LVS再发给客户端。如果后端服务器把回包直接发到别的网关，连接就会异常。

我们在初次接入新增后端节点时，就遇到过“健康检查通过，但实际访问偶发失败”的情况。最终定位是新机器初始化时走了默认云助手模板，默认网关没有按LVS设计修改，导致一部分响应绕开了LVS。结果从后端看服务正常，从客户端看就是时通时断。

这个坑的经验非常简单但非常重要：所有后端节点必须严格统一网络出口策略。如果你不想改默认网关，也可以考虑策略路由，让业务VIP相关流量经过LVS回程。但无论选择哪种方式，都必须确保回包路径一致。否则，LVS配置再标准，业务体验也会非常差。

调度算法怎么选，不要只会轮询

说到LVS调度，很多人默认就用rr轮询。实际上在生产环境中，调度算法是否合适，对整体稳定性影响很大。我们的业务有明显的请求时长差异，部分后端机器性能也并不完全一致。最早用轮询时，看起来分配均匀，但高峰期个别节点连接堆积严重。

后来我们改用了wlc，也就是加权最少连接。对于连接持续时间不均匀、节点配置存在差异的场景，这个算法明显更实用。再配合后端权重调整，可以把流量更合理地分发到资源更强的机器上。

所以在阿里云 部署lvs时，不要把重点全放在“能不能跑起来”，更要考虑“跑起来之后是否稳”。调度算法、会话保持、健康检查周期、失败重试策略，这些参数往往决定了系统是在高峰期平稳运行，还是表面正常、实际上暗藏隐患。

一次真实故障复盘：并不是LVS挂了，而是时间同步惹的祸

这里分享一个很有代表性的线上案例。有一次凌晨告警显示VIP切换异常，业务入口出现短暂抖动。值班同事第一反应是LVS主机负载过高或者Keepalived异常，于是先重启了服务，但问题并没有彻底消失。

后来我们仔细排查日志，发现两台LVS节点的系统时间出现了偏差，导致Keepalived相关检查与告警时间线混乱，同时健康检查脚本中依赖超时判断的部分逻辑也受到了影响。简单说，不是LVS本身转发失效，而是周边保障机制出现了时间不一致，最终引发状态判断异常。

这件事给我们的启发很大。高可用系统从来不是只看一个组件，而是一整套协同机制，包括：

• 时间同步服务是否稳定。
• 系统日志是否完整可追踪。
• 监控指标是否覆盖VIP状态、连接数、后端健康度。
• 切换脚本是否具备幂等性和异常兜底。

很多团队自建LVS失败，不是因为LVS这个技术过时，而是因为把它当成一个简单的软件安装任务，没有把它放进完整的可运维体系里。

云上部署LVS的正确心态：不是照搬教程，而是适配平台特性

经过这次实测，我们越来越明确一个观点：云上做基础设施，最忌讳的就是照搬传统机房经验。尤其是像LVS这类和网络栈强相关的组件，如果不理解云平台的边界，很容易陷入“配置明明都对，为什么就是不通”的困境。

对于阿里云 部署lvs，更稳妥的思路应该是：

1. 先确认业务到底需不需要自建LVS，而不是盲目为了技术而技术。
2. 明确阿里云网络环境约束，尤其是VIP、辅助IP、VPC路由和安全策略。
3. 优先选择实现复杂度更低、与云网络兼容性更好的模式。
4. 把抓包、日志、监控、演练纳入部署计划，而不是出了问题再补。
5. 在高可用设计上关注“业务可用”，而不是只关注“组件存活”。

适合哪些团队自建，哪些团队更应该直接用云负载均衡

客观地说，不是每个团队都适合在阿里云上自建LVS。如果你的业务规模不大，团队没有专门的运维和网络经验，或者只是想快速上线一个稳定入口，那么直接使用阿里云官方负载均衡服务，往往是性价比更高的选择。毕竟云产品已经帮你解决了大量高可用、弹性扩展、网络兼容、故障迁移问题。

但如果你满足以下条件，自建LVS仍然值得考虑：

• 对四层转发性能和控制粒度有明确要求。
• 已有成熟的运维体系和监控告警体系。
• 需要结合特殊网络拓扑、自定义探活和灰度逻辑。
• 能够接受前期测试、调优和长期维护成本。

换句话说，自建LVS不是过时方案，而是更偏“工程能力导向”的方案。它适合那些知道自己为什么要做、也有能力把它做稳的团队。

最后总结：这次阿里云部署LVS，最大的收获不是搭起来，而是少走弯路

回头看这次实践，最大的感受不是“LVS很难”，而是“云上网络和传统网络真的不是一回事”。很多经典教程里的配置，在本地虚拟机或者物理机房里完全成立，但到了阿里云环境下，就必须重新审视VIP绑定方式、ARP行为、路由路径、安全策略和故障切换机制。

如果让我用一句话总结这次阿里云 部署lvs实测经验，那就是：在阿里云上部署LVS，技术重点不在命令本身，而在对流量路径和云平台网络边界的理解。选对模式，比执着于理论最优更重要；把高可用做成业务可用，比Keepalived状态显示MASTER更重要；提前做好监控和演练，比上线后临时救火更重要。

对于准备动手的团队，我的建议是：先做小规模验证，优先采用NAT模式，严格梳理请求与回包路径，完善健康检查脚本，反复做主备切换演练，再考虑生产接入。只要方法对、边界清、验证充分，LVS在阿里云上依然可以成为一套可靠、高性能、可控性很强的负载均衡方案。