web服务器负载架构主流有DNS轮询、四层LVS、七层Nginx、硬件F5、云负载均衡五大类，选型关键看并发量、预算和可用性要求。
web服务器负载架构有哪些方案
web服务器负载架构有哪些方案，业内通常按网络层次拆成四类，理解这四类，你就能看懂大多数网站的流量调度逻辑。
链路层负载均衡（DR模式）
链路层方案修改的是MAC地址,用户请求到达负载设备后，设备直接改写目标MAC，把数据帧转发给后端服务器，后端服务器回包时绕过负载设备，直接回给用户，这种模式下，负载设备只承担入站流量压力，出站流量完全让后端自己走，吞吐量极高。
典型代表是LVS的DR模式,适合视频、文件下载这类“响应体远大于请求体”的业务，链路层方案的缺陷是后端服务器必须和负载设备在同一个物理网段，部署存在一定局限。
四层负载均衡（IP+端口转发）
四层方案工作在传输层,核心看IP和端口，常见实现包括LVS的NAT模式、简米云SLB的四层监听、华为云ELB的TCP/UDP监听，负载设备接收请求后，改写目标地址，将流量转发给选中的后端进程。
四层方案优势是性能极强,内核态处理，延迟低，基本不解析业务内容，但它无法感知URL路径、请求头等应用层信息，做不到按业务逻辑分流。
七层负载均衡（HTTP协议级调度）
七层方案工作在应用层,能解析HTTP请求中的URL、Cookie、User-Agent、请求头，Nginx和HAProxy是最主流的开源七层负载软件，负载设备拿到请求后，根据你配置的规则决定转发给哪个应用集群。
七层方案灵活度最高,可以做动静分离、灰度发布、限流熔断，也能实现基于Cookie的会话保持，代价是性能远低于四层，大流量下CPU开销明显。
全局负载均衡（GSLB，跨地域调度）
全局负载均衡解决的是用户访问哪个节点的问题,通常基于DNS解析来实现，用户查询域名时，GSLB设备根据用户来源IP、各节点当前负载、链路质量返回最优节点的IP地址，大厂常把GSLB和四层、七层组合成三级架构。
负载均衡方案对比：软件、硬件与云服务的取舍
对多数技术团队而言,方案对比才是决策的起点，下面这张对比表直接给出适用范围。
| 对比项 | 开源软件（Nginx/LVS） | 硬件设备（F5） | 云负载均衡（SLB/ELB） |
|---|---|---|---|
| 性能 | 极高，取决于服务器网卡和内核 | 极高，专用芯片处理 | 高，承载实例规格决定 |
| 核心能力 |
四层/七层，规则灵活 | 四层/七层，自带安全防护 | 四层/七层，自动弹性扩缩容 |
| 运维成本 | 自己装、自己调、自己监控 | 硬件维保，通常需要厂商支持 | 控制台操作，免运维 |
| 价格逻辑 | 只有服务器和带宽费用 | 单台设备数十万到上百万 | 按实例规格+流量计费，有包年包月折扣 |
| 适合规模 | 从几台到上千台服务器均可 | 金融、政企核心业务 | 中大型互联网业务 |
负载均衡方案对比中，选型决策往往卡在性能和成本之间，行业共识认为，多数互联网创业公司在日活十万以下时，用Nginx集群足够撑住流量，完全不需要上硬件设备。
Nginx和LVS怎么选
Nginx处理HTTP请求的细节能力远超LVS,比如按路径分流到不同服务群、根据Cookie粘住用户、配合Lua做复杂控制逻辑，LVS的优势则集中在超高并发场景，支持几十万的并发连接，且没有进程调度开销。
实际生产环境里,Nginx和LVS常搭配出现：LVS做入口流量分发到Nginx集群，Nginx再按业务规则把请求转发给后端的Java、PHP或Go服务，这也是目前最经典的四层加七层组合架构。
硬件负载均衡设备还有必要买吗
F5等硬件设备价格昂贵,但银行、政务系统依然大量采购，原因很简单：硬件设备有独立的管理通道、自带SSL硬件加速芯片、内置DDoS基础防护能力，合规审计上更容易通过，普通互联网业务不用追求这种形态，云负载均衡和开源软件能覆盖绝大多数需求。
四层+七层混合部署是主流高可用架构
把LVS和Nginx组合起来,是目前企业落地最多的模式，整条链路建议这样设计：
- 外部流量先到两个LVS节点,Keepalived提供VIP漂移，主节点宕机后备用节点毫秒级接管VIP。
- LVS将流量均匀分发到后端的Nginx集群,各Nginx节点保持无状态。
- Nginx根据请求路径、域名或Header信息，将不同业务转发到对应的应用服务器池。
- 每个后端应用池配置健康检查,Web服务器返回非2xx状态码时自动摘除节点，恢复后自动加回。
这套链路中,推荐在Nginx层开启keepalive连接缓存，减少后端服务器频繁建立TCP连接的开销，同时配置上游服务器的max_fails参数来控制故障转移灵敏度。
小型网站负载均衡配置实操
小网站同样需要负载调度,单台Nginx加多台后端是最轻的起步方案，以下是小型网站负载均衡配置的完整步骤。
安装和基础配置
在Ubuntu或CentOS上安装Nginx后,编辑nginx.conf里的http块，定义一个上游服务器组：
upstream web_cluster {
server 192.168.1.10 weight=3;
server 192.168.1.11 weight=2;
keepalive 32;
}
weak`weight=3`代表该服务器承担约60%的请求，按权重分配适合服务器配置不统一的情况。
### 转发规则与健康检查
接着在`server`块里配置反向代理：
```nginx
server {
listen 80;
location / {
proxy_pass http://web_cluster;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_next_upstream error timeout http_502 http_503;
}
}
proxy_next_upstream这条指令很重要，它定义了后端出错时的重试策略，建议把error和timeout加上，后端偶发超时时前端服务不中断。
会话保持的两种实现
后端服务要是有登录态,通常有两种处理方式：一种是把登录态存到Redis，后端无状态，任何节点都能处理请求；另一种是让Nginx用ip_hash算法把同一用户IP固定调度到同一台后端。
upstream web_cluster {
ip_hash;
server 192.168.1.10;
server 192.168.1.11;
}
ip_hash简单粗暴，但用户IP如果经常变化（如手机4G网络切换），会话可能还是会丢，业务允许的话，优先改造后端会话存储到Redis，这是长久的解法。
单机Nginx能扛住多大并发
一台普通2核4G云主机上的Nginx,保持系统参数优化后，静态文件处理能力可达每秒数千次请求，动态业务受后端处理速度影响，瓶颈很少出现在Nginx转发本身，日常几百并发的小网站，单台Nginx完全够用。
电商大促负载均衡如何规划
电商大促是负载架构压力最大的场景,流量峰值往往是平时的数倍，链路中每个节点都可能被打崩。
大促前扩容
提前联系云厂商开启负载均衡实例的弹性带宽,把后端服务器集群扩容到预计峰值的1.5倍，云控制台上修改监听器的连接空闲超时时间，避免长连接被过早断开，确保后端应用开启了优雅停机服务，这样摘除节点时不会中断正在处理的请求。
压测验证GSLB调度
大促前需要做全链路压测,重点观察全局负载均衡设备能否准确把华南用户调度到华南节点，华北用户调度到华北节点。电商大促负载均衡的容灾设计上，建议采取多活模式，任何一个地域的负载实例挂掉，流量自动切到相邻地域的实例上，域名解析的TTL建议调到60秒，缩短故障切换时间。
限流和降级方案
入口层配置单IP
限流阈值,超过阈值的请求直接返回友好错误页，后端依赖的数据库或缓存服务一旦繁忙，必须让负载均衡层立刻摘掉对应服务节点，避免请求堆积拖垮整个集群，支付接口这类关键链路，采用独立负载实例，避免和查询类业务互相干扰。
不同规模业务的选型与成本
预算有限时,哪家负载均衡价格便宜是绕不开的问题，国内主流的简米云、酷番云、华为云都提供按量计费和包年包月两种模式，短期流量波动大的业务选按量计费更划算，全年稳定运行的业务选包年包月可节省大约三成成本，需要注意的是，部分云厂商会针对负载均衡实例单独收取公网流量费，选购时要一并核算带宽成本，否则账单极易超预期。
小型网站也可以考虑完全免费的自建方案：一台廉价云主机跑Nginx，后端挂两台应用服务器，总成本只包含服务器费用，云负载均衡则胜在管理省心，且自带DDoS防护、访问日志、监控告警，不需要自建监控系统。
对初创项目和跨境电商业务,优先使用云负载均衡，少踩自建方案的坑，国内主要云厂商都有免费额度或试用期，实际测试后对比不同地域节点的延迟表现再做决定，部署时参考公司的业务密度，服务器集中在华北地区可选北京节点，集中华南地区可选广州或深圳节点，选型地域没有绝对优势，实测数据才可靠。
Q&A：web服务器负载架构有哪些常见问题
负载均衡和反向代理是同一回事吗
不是,反向代理是负载均衡的一种实现形式，负载均衡的重点在于调度多台后端服务器的流量分配，反向代理除了调度还能缓存静态资源、屏蔽后端真实IP、改写请求URL，Nginx同时具备两种角色，但LVS纯做流量调度，不去处理反向代理要做的那些应用层逻辑。
自建负载均衡和云负载均衡哪个更好
自建方案适合已经有运维团队、流量规模固定、需要深度定制负载策略的业务，云负载均衡适合大部分中小规模业务，尤其是弹性要求高、不希望投入运维精力的团队，从成本角度，如果你已经有多余的闲置服务器，自建Nginx几乎零成本；如果没有，云负载均衡加上后端服务器的综合支出往往低于自购硬件服务器自建。
如何判断当前负载架构是否到了瓶颈
持续观察整个链路的指标变化,负载设备CPU超过70%或连接数逼近上限、后端应用服务器平均响应时间持续增长、限流策略频繁触发，都属于瓶颈信号，另一个明显特征是，扩了几台后端服务器但系统整体吞吐量没有显著提升，此时瓶颈大概率不在Web服务器，而在数据库或上游依赖服务。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/706068.html
