负载均衡技术通过将用户请求分发到多台服务器，显著提升系统性能和可用性，是现代分布式架构的基石。
负载均衡的核心原理与分类
负载均衡的本质是流量调度，它隐藏在多台服务器前面，接收客户端请求，然后按照预定策略转发给后端服务器，这样一来，用户感觉不到单台服务器的存在，即使某台服务器宕机,流量也能自动切换到健康的节点。
常见的负载均衡算法
算法决定了流量如何分配,业内常用以下几种：
- 轮询：依次将请求发给每台服务器,适合后端配置相近的场景。
- 最少连接：优先转发给当前活跃连接数最少的服务器,适合长连接应用。
- IP哈希：根据客户端IP计算哈希值，确保同一IP的请求始终落在同一台服务器,常用于需要会话保持的场景。
- 加权轮询：给每台服务器设定权重，性能高的机器拿更多流量,实现差异化分配。
四层与七层负载均衡
根据OSI模型工作的层级,负载均衡分为两类：
- 四层负载均衡：工作在传输层，基于IP和端口转发，效率高，不关心应用协议内容，典型代表是LVS、HAProxy的TCP模式。
- 七层负载均衡：工作在应用层，能解析HTTP/HTTPS等协议内容，实现更精细的路由，如按URL、Cookie分发，典型代表是Nginx、HAProxy的HTTP模式。
选择哪种取决于业务需求，四层性能更优，七层灵活性更强，多数大型系统会同时使用两层，四层做入口流量分配,七层做应用层路由。
负载均衡和反向代理到底有什么区别？
不少开发者把这两个概念混为一谈。负载均衡和反向代理在功能上高度重叠，但侧重点不同。
- 负载均衡核心目标是流量分发，强调高可用和扩展性，主要解决“如何把请求均匀分配到多台服务器”。
- 反向代理核心目标是代理外部请求访问内部服务器，提供缓存、安全防护、压缩等功能，解决“如何隐藏后端服务器并提供统一入口”。
实际架构中，很多负载均衡器同时具备反向代理能力，比如Nginx既可以做反向代理，也可以配置多台后端实现负载均衡，行业共识认为，两者常常结合使用,但理解区别有助于方案选型。
| 对比维度 | 负载均衡 | 反向代理 |
|---|---|---|
| 主要目标 | 流量分发，提高扩展性 | 隐藏后端，提供统一入口 |
| 功能侧重 | 健康检查、调度算法、容错 | 缓存、SSL卸载、安全过滤 |
| 典型产品 | F5、LVS、HAProxy、ALB | Nginx、Apache mod_proxy、Caddy |
| 部署位置 | 通常位于反向代理之前 | 紧贴应用服务器之前 |
选型时，如果只需要流量分发，用纯负载均衡方案；如果需要统一入口和安全控制，反向代理更合适,大多数现代系统会在一层中同时实现两者。
负载均衡方案怎么选才对？
选择负载均衡方案需要综合考虑业务规模、预算、技术栈和运维能力,下面分场景给出建议。
小型网站或初创项目
- 推荐：软件负载均衡，如Nginx或HAProxy，部署在一台服务器上,成本极低。
- 配置：简单的upstream块即可实现轮询,几分钟内搞定。
- 注意：单点故障风险,建议至少两台机器做高可用。
中型电商或企业应用
- 推荐：云负载均衡服务，如简米云SLB、酷番云CLB、AWS ELB。
- 优势：免运维，内置健康检查、自动伸缩、跨可用区容错。
- 成本：按使用量付费，初期投入较低,但需注意流量突增费用。
大型互联网或金融系统
- 推荐：硬件负载均衡（F5、A10）或自研四层+七层组合方案。
- 理由：硬件设备性能稳定，适合高并发、低延迟场景；自研方案可定制调度逻辑。
- 注意：硬件负载均衡价格较高,但长期来看稳定性优于软件方案。
常见选型误区
- 过度追求功能：不要一开始就上七层负载均衡，如果业务不需要URL路由,四层更高效。
- 忽略健康检查：没有健康检查的负载均衡只是摆设,务必配置探活机制。
- 不考虑会话保持：很多应用依赖状态，一旦流量切换会话丢失，用户会投诉,用IP哈希或Redis存储会话。
负载均衡配置实战：Nginx操作示例
Nginx是最常用的七层负载均衡软件，配置简单，功能强大,下面给出一段真实可用的配置。
基本负载均衡配置
http {
upstream backend {
server 192.168.1.10:8080 weight=3;
server 192.168.1.11:8080 weight=2;
server 192.168.1.12:8080 backup;
}
server {
listen 80;
location / {
proxy_pass http://backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
}
- upstream：定义后端服务器池，weight控制权重,backup表示备用节点。
- proxy_pass：将请求转发到upstream定义的组。
- 健康检查：默认被动检查，如果后端返回错误（如502），Nginx会将其标记为不可用,一定时间后重试。
七层负载均衡的高级玩法
- 按URL路由：将不同路径的请求转发到不同后端。
location /api/ { proxy_pass http://api_backend; } location /static/ { proxy_pass http://static_backend; } - 会话保持：使用ip_hash指令绑定客户端IP。
upstream backend { ip_hash; server 192.168.1.10:8080; server 192.168.1.11:8080; } - SSL卸载：在负载均衡层解密HTTPS，减轻后端压力。
server { listen 443 ssl; ssl_certificate /path/to/cert.pem; ssl_certificate_key /path/to/key.pem; location / { proxy_pass http://backend; } }
负载均衡成本到底贵不贵？
成本因方案差异巨大,但多数情况下都有性价比之选。
开源软件方案
- 成本：免费,仅需服务器硬件费用。
- 适用场景：技术团队有运维能力,业务量可控。
- 隐形成本：人工维护、故障排查时间。
云负载均衡服务
- 成本：按使用量付费，包括流量费、实例费、跨域费用，以国内云厂商为例，小型实例每月几十元起步,流量另计。
- 优势：免运维，弹性伸缩,可用性有SLA保障。
- 注意：流量突增可能导致账单飞涨,需设置预算告警。
硬件负载均衡设备
- 成本：设备价格数万到数十万不等,加上每年的维保费用。
- 适用场景：金融、医疗、政府等对合规和性能要求严苛的行业。
- 价值：稳定性高，支持毫秒级切换,有专业售后支持。
业内人士指出，对于绝大多数企业，云负载均衡或开源软件方案已经足够，购买硬件前需仔细评估,避免过度投资。
负载均衡常见问题解答
负载均衡怎么做会话保持？
会话保持的方法有几种：一是使用IP哈希算法，确保同一客户端IP始终落在同一台后端；二是使用Cookie，负载均衡器会在首次请求时设置一个Cookie，后续请求根据Cookie转发；三是外部存储会话，将会话信息存入Redis或数据库，所有后端服务器共享，这样即使请求被分配到不同机器,也能读取到正确会话。
健康检查不通过怎么办？
首先检查后端服务器是否正常，端口是否监听，然后确认防火墙没有拦截负载均衡器的探活请求，再看健康检查配置，比如HTTP检查的路径（如/health）是否返回2xx状态码，如果使用Nginx，可以查看error日志,定位具体原因。
加权轮询和最少连接该选哪个？
加权轮询适合后端性能差异明显且请求处理时间相对均匀的场景，最少连接适合请求处理时间差异大的场景，比如有的请求需要大量计算，有的请求很快返回，最少连接可以避免某台机器积压太多长任务，如果不确定，先按业务特点测试,再根据实际表现调整。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/515786.html
