负载均衡网络本质上是一套流量调度体系，它把海量请求均匀分配到多台后端服务器上，避免单节点过载，同时通过健康检查自动摘除故障节点，保障业务持续可用。
负载均衡网络是什么
负载均衡网络不是指某一台设备或某个软件,而是由入口网关、调度策略、健康检查、会话保持等机制共同组成的完整流量分发体系，它的核心目标只有一个：让每一台后端服务器都工作在相对饱和但不超载的状态。
用拟人化的方式来理解,负载均衡器就像机场的地勤调度员，旅客（请求）不断涌入航站楼，调度员根据每个登机口（服务器）的排队情况，把新旅客引导到当前最空闲的登机口，某个登机口临时关闭（服务器宕机），调度员立刻把旅客改签到其他登机口，整个过程对旅客完全透明。
一个标准的负载均衡网络通常包含以下组件：
- 流量入口：接收来自公网或内网的请求，是整个系统的第一道关卡
- 调度算法：决定请求该去往哪台后端节点，常见算法有轮询、加权轮询、最少连接数、一致性哈希
- 健康检查机制：定期探测后端节点的存活状态和响应延迟，异常节点会被自动摘除
- 会话保持：通过Cookie或源IP绑定，让同一用户的多次请求始终落在同一台服务器上
这套体系的价值在业务量增长时体现得最明显,没有负载均衡，单台服务器的处理能力就是系统天花板，扩容意味着迁移和停机，有了负载均衡，你可以随时横向添加服务器，系统吞吐量随节点数量接近线性增长，扩容过程对用户完全无感。
负载均衡网络的核心架构
理解了基本概念,下一个问题是：负载均衡网络在真实部署中分哪些层级？不同业务场景应该选哪种架构？
四层负载均衡和七层负载均衡区别
这是负载均衡领域最常被问到的技术问题,四层和七层对应OSI模型的传输层和应用层，两者的工作方式、性能特征和适用场景差异很大。
四层负载均衡（L4） 工作在传输层，只解析IP地址和TCP/UDP端口号，不检查数据包内部的应用层内容，它收到请求后，直接根据调度算法把整个连接转发给后端节点，因为不解析应用层协议，转发速度极快，吞吐量非常可观，适合处理海量并发连接。
七层负载均衡（L7） 工作在应用层，能够完整解析HTTP、HTTPS、WebSocket等协议内容，它可以根据URL路径、请求头、Cookie、请求参数等条件做精细化路由，把 /api/ 开头的请求转发给后端API集群，把 /static/ 开头的请求转发给CDN或对象存储。
选择四层还是七层,取决于业务特征：
- 纯TCP/UDP长连接场景，如游戏服务器、消息推送、数据库中间件，优先选四层
- HTTP/HTTPS业务，需要URL路由、HTTPS证书卸载或跨域策略控制的场景，选七层
- 主流云厂商的负载均衡产品同时支持四层和七层,购买实例时按需选择协议类型即可
行业共识认为,在微服务架构快速普及的背景下，七层负载均衡的使用比例持续上升，因为API网关本身就需要对请求做深度路由和策略控制。
硬件负载均衡与软件负载均衡怎么选
硬件方案以F5、Citrix ADC为代表，性能强悍、功能丰富，但价格动辄数十万元起步，且需要专业硬件知识来维护，软件方案以Nginx、HAProxy、LVS为代表，成本低、灵活性高，近年来在互联网行业占据绝对主流。
| 对比维度 | 硬件负载均衡 | 软件负载均衡 |
|---|---|---|
| 单机性能 | 极高，支持百万级并发 | 依赖服务器硬件，通常十万到百万级 |
| 成本 | 几十万到上百万元 | 免费或极低 |
| 灵活性 | 硬件扩容周期长 | 纯软件配置，秒级变更 |
| 运维门槛 | 需要专业硬件技能 | 熟悉Linux命令行即可上手 |
中小型业务完全没必要考虑硬件方案,一台配置尚可的云服务器跑Nginx，吞吐量已经能覆盖绝大多数场景，只有金融、电信、政务等对稳定性和合规性有极致要求的行业，才会为硬件负载均衡的高额溢价买单。
负载均衡和反向代理的区别
不少刚开始接触网络架构的人会把这两个概念混为一谈,负载均衡和反向代理确实有大量功能重叠，但看待问题的角度截然不同。
反向代理的核心动作是“代访问”，它代替客户端去请求后端服务器，再把响应结果返回给客户端，客户端只与反向代理建立连接，后端服务器完全隐藏在代理之后，Nginx最基础的反向代理功能，就是通过
proxy_pass 指令把收到的HTTP请求转发给上游应用服务器。
负载均衡的核心动作是“做调度”，它关注的是如何把流量均匀地分配到多个后端节点上，一个纯粹的负载均衡器可以不承担反向代理的职责，比如LVS在TCP层直接改写数据包的目标地址，客户端和后端服务器之间建立的实际上是直连连接，数据包只是经过LVS中转了一下。
实际生产环境中,两者经常叠加使用，一个典型的架构是：LVS作为四层流量入口，Nginx作为七层反向代理和负载均衡器，各司其职，形成两级流量调度体系。
负载均衡器的选型与实操
理论讲完,落到实际操作层面，无论自建还是购买云服务，最终都要回答一个问题：负载均衡器怎么选？
负载均衡器怎么选
选型需要从流量规模、业务类型、预算和运维能力四个维度综合评估。
- 日均请求量百万级以下：单台Nginx加Keepalived高可用方案足够，部署简单，社区资料丰富
- 日均请求量千万级：Nginx集群配合LVS做两级负载均衡，或者直接使用云厂商的企业级负载均衡实例
- 日均请求量亿级以上：多级负载均衡架构配合DNS地域调度，需要专门的性能优化和容量规划
- 业务有特殊协议需求：WebSocket长连接优先考虑HAProxy，gRPC场景Nginx从1.13版本起已经支持
预算方面,中小型业务直接使用云厂商的负载均衡服务是性价比最高的选择，以简米云为例，按量付费的负载均衡实例每小时费用从几分钱到几毛钱不等，具体取决于规格、带宽和地域，自建方案的软件成本虽然为零，但服务器资源、公网带宽和运维人力都是隐形成本，需要通盘计算。
Nginx负载均衡配置实操
Nginx是目前使用率最高的软件负载均衡方案,下面演示一个最基础的HTTP负载均衡配置。
http {
upstream backend_pool {
server 192.168.1.10 weight=3;
server 192.168.1.11 weight=1;
server 192.168.1.12 backup;
}
server {
listen 80;
location / {
proxy_pass http://backend_pool;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
}
这段配置的几个关键动作：
upstream块定义了后端服务器池，weight参数控制权重分配比例，上面的配置意味着每4个新请求中有3个打到192.168.1.10backup标记的节点是备用节点，只在其他节点全部不可用时才接管流量proxy_set_header把客户端的真实IP和Host信息传递给后端，否则后端日志里记录的IP全部是Nginx的内网地址
配置完成后,执行 nginx -t 检查语法是否正确，确认无误后执行 nginx -s reload 热加载配置，整个过程不需要重启服务，业务零中断。
负载均衡网络常见问答
负载均衡网络解决不了什么问题？
负载均衡负责流量分发和高可用,不负责数据一致性、分布式事务、缓存同步这些业务层面的问题，跨节点的Session共享需要引入Redis等外部存储，数据库的主从切换需要数据库层的高可用方案，这些都需要在负载均衡之外单独设计。
负载均衡网络会增加请求延迟吗？
任何中间层都会引入额外的网络跳数和处理开销,四层负载均衡的延迟损耗通常在微秒到毫秒级别，七层负载均衡因为要解析应用层协议，延迟会略高一些，对于绝大多数业务来说，这个延迟完全可接受，远小于后端应用处理请求本身的耗时，但如果业务对延迟极其敏感，比如高频量化交易场景，就需要考虑DPDK等高性能数据面方案来压缩转发延迟。
自建负载均衡和云负载均衡哪个更划算？
自建方案的优势是可控性强、没有按量计费的成本压力，但需要自行承担高可用架构、安全防护和日常运维，云负载均衡的优势是开箱即用、弹性伸缩、免运维，中小业务按量付费的成本非常低，据IDC公开趋势报告，采用云负载均衡的企业比例近年来持续上升，大多数中小型业务选择云服务是更务实的选择。
负载均衡网络的本质,是用一套统一调度机制把分散的服务器资源组织成高可用、高吞吐的逻辑整体，选型时先明确业务规模和协议类型，再决定四层还是七层、自建还是上云，最后通过健康检查和监控告警把系统维持在一个健康水位，这套逻辑在很长一段时间内，仍然是互联网架构的基石。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/555153.html
