🚀 从单台服务器到数百万用户:负载均衡实用指南 ⚖️
Source: Dev.to
抱歉,您只提供了来源链接,而没有提供需要翻译的正文内容。请粘贴您想要翻译的文本,我会按照要求将其翻译成简体中文并保留原有的格式。
为什么负载均衡很重要
- 计算机有极限 – 单台服务器可能会过载、变慢或崩溃。
- 流量不均 – 突发流量会压垮单一实例。
- 故障不可避免 – 硬件或软件问题会发生。
负载均衡将传入请求分配到多台服务器上,避免单台服务器成为单点故障。
Users → Load Balancer → Server A Server B Server C
负载均衡器充当“脑 + 交通警察”,在运行时执行以下任务:
- 接收客户端请求。
- 检查哪些服务器可用。
- 应用路由算法。
- 转发请求。
- 监控服务器健康状态。
- 自动移除故障服务器。
这些步骤每秒会发生数百万次。
何时使用负载均衡
- 高流量平台(例如 Netflix、Amazon 销售、社交媒体信息流)
- 从单台服务器水平扩展到多台
- 服务器宕机时自动故障转移(无停机时间)
- 将请求路由到最快或最近的服务器(全球用户)
- API、机器学习推理、数据处理
- TCP/UDP 服务(非常快,智能性较低)
- 需要基于 URL 路径、请求头或 Cookie 路由的 HTTP/HTTPS 服务
算法及其工作原理
| 算法 | 描述 |
|---|---|
| Round Robin | 将请求逐个发送到服务器,假设各服务器容量相等。 |
| Least Connections | 选择活动连接最少的服务器——在真实流量下表现良好。 |
| Least Response Time | 将流量发送到响应时间最快的服务器,适用于低延迟应用。 |
| IP Hash | 将客户端 IP 映射到特定服务器,使会话保持粘性。 |
| Weighted | 将更多流量分配给性能更强的服务器;在硬件混合环境中很有用。 |
常见做法: Least Connections 与健康检查相结合。
流行实现
- 物理设备 – 非常快,成本高,银行和电信公司使用。
- 软件解决方案 – 在标准机器上运行:
- NGINX
- HAProxy
- Envoy
- 托管云负载均衡器:
- AWS – ELB / ALB / NNL
- Google Cloud – Cloud Load Balancing
- Azure – Azure Load Balancer
好处
- 自动扩展和内置冗余
- 简单设置;DNS 可以为全球流量返回不同的 IP
- 健康检查(
GET /health)自动将不健康的实例移出轮询
示例:使用最少连接的 NGINX
// server.js (Node.js)
const http = require("http");
const PORT = process.env.PORT;
const NAME = process.env.NAME;
http.createServer((req, res) => {
res.end(`Hello from ${NAME}\n`);
}).listen(PORT, () => {
console.log(`${NAME} running on port ${PORT}`);
});
运行三个实例:
PORT=3001 NAME=Server-A node server.js
PORT=3002 NAME=Server-B node server.js
PORT=3003 NAME=Server-C node server.js
NGINX 配置:
http {
upstream backend_servers {
least_conn;
server localhost:3001;
server localhost:3002;
server localhost:3003;
}
server {
listen 80;
location / {
proxy_pass http://backend_servers;
}
}
}
解释: upstream 定义服务器池,least_conn 选择活动连接最少的服务器,NGINX 会自动分配流量。
使用 IP 哈希实现粘性会话
upstream backend_servers {
ip_hash;
server localhost:3001;
server localhost:3002;
}
结果: 同一客户端 IP 会始终被路由到同一后端服务器,适用于已登录用户的场景。
负载均衡器 + 自动伸缩
- 根据需求动态添加或移除服务器。
- 防止过载,并在无需人工干预的情况下处理增长。
- 可以基于触发条件(例如 CPU 使用率、请求延迟)。
实际部署
- AWS 与 Kubernetes: Ingress 控制器 + Services。
- Netflix: 多层方法 – DNS → 最近的区域 → 边缘负载均衡器(CDN) → 区域负载均衡器 → 服务间负载均衡。
- 微服务: 服务网格负载均衡(例如 Istio、Linkerd)。
每个请求通常遵循以下路径:
User → DNS → Load Balancer → Service → Cache → Stream
安全特性
- SSL/TLS 终止
- 后端 IP 隐蔽
- 速率限制
- DDoS 缓解
- Web 应用防火墙 (WAF) 集成
避免单点故障: 部署多个负载均衡器或使用提供冗余的托管服务。
Conclusion
在当今的分布式世界中,负载均衡不再是一个优化选项——它是一项必需。无论你是为一个小型 Web 应用还是拥有数百万用户的全球平台提供服务,有效的负载均衡都能确保弹性、性能和可扩展性。通过选择合适的算法、配置健康检查,并利用合适的基础设施(软件、硬件或托管云服务),系统能够应对流量高峰、抵御故障,并在不间断的情况下实现增长。掌握负载均衡对于任何希望在压力下保持软件运行的系统工程师来说都是必不可少的。
快速回顾:相关主题
| # | 主题 |
|---|---|
| 1 | 分页 — 架构系列:第 1 部分 |
| 2 | 索引 — 架构系列:第 2 部分 |
| 3 | 虚拟化 — 架构系列:第 3 部分 |
| 4 | 缓存 — 架构系列:第 4 部分 |
| 5 | 分片 — 架构系列:第 5 部分 |
| 6 | 负载均衡 — 架构系列:第 6 部分 |