多台服务器如何做负载均衡？SLB配置方案详解
当单台服务器无法承载访问量，或者需要保证高可用时，就需要引入负载均衡把流量分摊到多台服务器。很多人对负载均衡的工作原理和配置细节不太清楚，本文从架构设计到实际配置一步步讲清楚。
什么时候需要引入负载均衡？
并非所有网站都需要负载均衡，判断标准如下：
| 场景 | 是否需要SLB | 说明 |
|---|---|---|
| 单台服务器CPU/内存长期低于50% | 不需要 | 单机资源充足，暂无必要 |
| 访问量增长，单机扛不住并发 | 需要 | 横向扩展多台服务器分摊压力 |
| 要求99.9%以上可用性 | 需要 | 单点故障会导致整站不可用 |
| 业务处于验证期，流量很小 | 不需要 | 过早引入增加复杂度和成本 |
当单台服务器CPU利用率经常超过70%，或者业务对高可用有明确要求时，就应该考虑引入负载均衡架构。
负载均衡架构怎么设计？
典型的多服务器负载均衡架构：
多台服务器负载均衡后，如果Session还存在本地内存中，用户请求被分配到不同服务器会导致登录状态丢失。必须先做好应用无状态化改造，才能顺利上线负载均衡。
应用型和网络型负载均衡怎么选？
阿里云SLB分为不同类型，适用场景不同：
| 类型 | 工作层级 | 适用场景 |
|---|---|---|
| ALB（应用型） | 七层（HTTP/HTTPS） | Web应用、需要URL路由、SSL卸载 |
| NLB（网络型） | 四层（TCP/UDP） | 高性能要求、非HTTP协议、游戏服务器 |
| CLB（传统型） | 四层+七层 | 兼容老架构，逐步迁移到ALB/NLB |
大部分Web网站和API服务选ALB即可，它支持基于URL路径的路由规则、HTTPS证书统一管理，功能更贴合应用层需求。
健康检查怎么配置？
健康检查是负载均衡的核心机制，配置不当会导致流量分配异常：
- 设置检查路径：配置一个轻量的健康检查接口（如
/health），避免用首页做检查（首页逻辑复杂，检查慢） - 设置检查间隔：建议5-10秒一次，间隔太短增加服务器压力，太长故障发现慢
- 设置失败阈值：连续2-3次失败才判定为不健康，避免网络抖动误判
- 设置恢复阈值：连续2次成功才恢复流量，避免服务器刚恢复又被打垮
- 检查路径：/health（返回200即为健康）
- 检查间隔：10秒
- 超时时间：3秒
- 失败阈值：3次
多可用区部署怎么配置才靠谱？
要实现真正的高可用，服务器不能全部部署在同一个可用区：
- 跨可用区部署：至少2个不同可用区各部署1台以上服务器，避免单可用区故障导致整体不可用
- SLB自动跨区调度：阿里云SLB本身支持多可用区部署，自动将流量分配到健康的后端服务器
- 数据库同步：确保RDS也配置了多可用区高可用版，避免数据库成为单点
负载均衡本身消除了应用层的单点故障，但如果数据库、存储等依赖资源仍是单点，整体可用性提升有限。要做全链路的高可用设计，而不只是加个负载均衡。
常见问题
只有一台服务器需要上SLB吗？
一般不需要。单台服务器上SLB不能提升可用性（服务器故障SLB也无法转发），只有在需要SSL卸载、统一入口管理等特殊需求时才考虑，日常场景没必要增加这层复杂度和成本。
SLB怎么收费？
阿里云SLB主要按实例费+流量费计费：实例费按小时/包年包月计算，流量费按实际转发的数据量或按带宽峰值计算。日常访问量不大的网站，SLB月费用大概在几十到一百多元。
总结
多台服务器做负载均衡的核心思路是：先判断是否真的需要（并发压力或高可用需求），再设计无状态化架构（Session外置、静态资源分离），选择合适的SLB类型（Web应用选ALB），配置好健康检查参数，并尽量做跨可用区部署实现真正的高可用。负载均衡只是整体架构的一环,要配合数据库、存储的高可用设计才能发挥最大价值。