阿里云负载均衡 SLB 终极教程：从零构建高性能网站高可用部署方案

本文由阿里云官方代理商lingducloud零度云撰写

在互联网业务爆发式增长的今天，单机架构（Single Point of Failure，单点故障）已经成为制约企业数字化发展的致命瓶颈。当面对突发洪峰流量、代码遭遇未知异常导致进程崩溃，或者底层物理硬件突发故障时，单台云服务器（ECS）的宕机直接意味着业务的中断与客户的流失。

为了实现真正的生产级高可用（High Availability）与弹性伸缩，引入负载均衡（Load Balancer）是系统架构演进的必经之路。

阿里云的负载均衡 SLB（Server Load Balancer）作为阿里生态的流量总入口，能够将公网大并发流量根据特定的调度算法，合理分发到后端的数台甚至数百台 ECS 实例上。配合健康检查机制，SLB 可以在毫秒级内自动隔离故障节点，从而确保业务的 7×24 小时连续性。

作为一名深耕云计算与高并发架构多年的资深从业者，今天我将带你跳过流于表面的概念，用干货满满的实战视角，彻底攻克基于阿里云 SLB 的网站高可用部署方案。

一、 系统架构设计：高可用拓扑蓝图

在动工之前，我们要明确一个标准的、具备容灾能力的 Web 高可用拓扑结构。一个合格的方案绝对不是简单地把两台服务器挂在负载均衡后面，而是需要考虑跨可用区（Available Zone）的物理容灾。

1. 核心高可用拓扑要素

• SLB 实例：选择应用型负载均衡 ALB（Application Load Balancer）或网络型负载均衡 NLB。本文以专注于 7 层（HTTP/HTTPS）协议、最适合网站业务的 ALB / CLB（传统型） 为例。SLB 本身在阿里云底层是多可用区主备高可用的。
• 后端 ECS 实例集群：至少准备 2 台 ECS，且分别部署在同一个地域的不同可用区（例如：北京可用区 A 和 北京可用区 B）。这样即使阿里云的某个物理机房因不可抗力断电，另一个机房的 ECS 也能无缝接管全部流量。
• 数据一致性底座：
• 代码与静态资源：通过阿里云对象存储 OSS 或网络文件系统 NAS 实现多机共享，或通过 CI/CD 自动化流水线同步部署。
• 数据库（RDS）：绝对不能部署在单台 ECS 上，必须使用阿里云 RDS MySQL 高可用版（一主一备跨可用区），所有后端 ECS 均连接同一个 RDS 实例。
• 会话管理（Session）：配置为无状态服务。会话数据持久化到阿里云 Redis 版（KVStore）中，或在 SLB 上开启“会话保持”。

二、 第一阶段：后端 ECS 运行环境与无状态准备

在配置 SLB 之前，我们需要确保后端的 Web 服务器已经就绪，且能够吐出相同的业务内容。

1. 规范化同步部署 Web 服务

假设我们有两台 ECS 实例：

• ECS_01（可用区 A，内网 IP：192.168.1.10）
• ECS_02（可用区 B，内网 IP：192.168.2.20）

在两台机器上分别安装 Nginx，并确保 80 端口正常提供服务。为了方便后续测试 SLB 分发效果，我们可以在两台机器的默认首页中写入不同的标识（生产环境中必须保持两台机器的代码与内容完全一致）：

# 在 ECS_01 上执行
echo "Welcome to Web Server 01 (Zone A)" > /usr/share/nginx/html/index.html

# 在 ECS_02 上执行
echo "Welcome to Web Server 02 (Zone B)" > /usr/share/nginx/html/index.html

2. 数据库与挂载检查

确保两台 ECS 的网站配置文件（如 WordPress 的 wp-config.php 或 Java 的 application.yml）中的数据库连接地址，全部指向外部的云数据库 RDS 内网连接串，确保两台服务器写入的数据是实时同步、完全同源的。

三、 第二阶段：阿里云 SLB 实战配置四步走

环境就绪后，我们登录阿里云控制台，搜索并进入传统型负载均衡 CLB 或 应用型负载均衡 ALB 页面（此处以标准的 7 层 HTTP 网站分发为例）。

1. 创建 SLB 实例

点击“创建实例”，根据业务需求选择关键参数：

• 商品类型：按量付费（生产环境建议选择性能保障型实例）。
• 地域与可用区：必须与你的 ECS 实例完全一致（例如华北2-北京）。主可用区选可用区 A，备可用区选可用区 B。
• 网络类型：选择公网。系统会自动分配一个独享的公网 IPv4 地址。

2. 构建“后端服务器组（VServer Group）”

实例创建完成后，不要急于配置监听，先拉拢我们的服务器团队。

1. 创建虚拟服务器组:
   在左侧导航栏点击“后端的服务器” -> “虚拟服务器组”，点击“创建虚拟服务器组”。

1. 添加 ECS 实例:
   在弹出的窗口中，勾选处于相同 VPC 下的 ECS_01 和 ECS_02，点击添加。

1. 分配权重（Weight）:
   为每台服务器设置权重，默认均为 100。

💡 从业者性能调优提示：如果两台 ECS 的硬件配置不同（如一台是 2核4G，另一台是 4核8G），可以按比例调整权重（如分别设为 50 和 100）。SLB 会根据权重比例进行流量倾斜。由于我们配置完全相同，保持 100:100 即可。

1. 配置服务端口:
   将两台 ECS 的端口均设置为 80（即 Nginx 监听的端口），点击保存。

3. 配置核心“监听规则（Listener）”与调度算法

回到实例列表，点击目标 SLB 实例右侧的“配置监听”，进入核心策略路由设置：

• 监听协议与端口：选择 HTTP 协议，端口输入 80。
• 高级配置 - 调度算法：阿里云提供了多种业界主流算法，网站业务常见的有：
• 轮询（RR, Round Robin）：流量极其均匀地一递一发地分发到后端服务器，适合后端服务器处理能力对等的场景（推荐首选）。
• 加权轮询（WRR）：依照上述设置的权重比例分配流量。
• 最小连接数（WLC）：优先将流量分发给当前并发连接数最少、压力最小的那台 ECS，适合后端处理动态长链接、执行大计算的业务场景。

• 高级配置 - 会话保持（Session Persistence）：
• 如果你的 Web 应用本身是有状态的（会话保存在本地内存中），必须开启会话保持。
• 选择“植入 Cookie”，超时时间设为 1000秒。这样，在 Cookie 有效期内，来自同一个用户的请求会始终固定发送给同一台 ECS，避免用户刷新网页出现“需要重新登录”的尴尬现象。

4. 配置“健康检查（Health Check）”（高可用的灵魂）

健康检查是 SLB 实现主动容灾的核心。SLB 会定期向后端 ECS 发起微型探测，一旦发现异常，立即切断其流量。

• 开启健康检查：勾选“开启”。
• 检查路径（URI）：输入 /index.html（或一个专门用于健康检查的轻量化页面文件，如 /health.txt）。
• 健康检查端口：保持默认，或指定 80。
• 核心阈值调优：
• 响应超时时间：5秒（5秒内不响应视为一次超时）。
• 健康检查间隔：2秒（每隔2秒探测一次）。
• 不健康阈值：3次（连续3次失败，SLB 会在第 15 秒左右彻底断开该 ECS 的公网流量，将其标记为“异常”）。
• 健康阈值：3次（ECS 修复后，必须连续 3 次成功，SLB 才会重新将其纳管进集群拉起业务）。

点击提交，配置正式生效。

四、 高可用效果验证与故障演练

配置完成后，控制台的监听状态会显示为“运行中”。在浏览器中输入阿里云 SLB 分配的公网 IP 地址，开启我们的高可用验证之旅。

1. 流量分发验证

在新开的无痕浏览器中不断刷新页面，你会发现网页内容在 Welcome to Web Server 01 和 Welcome to Web Server 02 之间交替切换（在关闭会话保持的情况下）。这证明轮询算法已经完美生效，两台服务器正并肩作战、共同分担公网压力。

2. 模拟机房宕机/服务崩溃演练

为了验证高可用方案的容灾能力，我们登录 ECS_01，手动执行命令强行关闭 Nginx 服务，模拟程序崩溃或单机断电：

# 在 ECS_01 上强行停止 Web 服务
sudo systemctl stop nginx

此时，我们掐表观察：

1. 5~10 秒内：登录阿里云 SLB 控制台，刷新健康检查列表，你会看到 ECS_01 的状态由“正常”瞬间变红，提示“异常”。
2. 用户侧体验：持续疯狂刷新刚才打开的网站域名，网页依然能够秒开，只是内容固定在了 `Welcome to Web Server 02`。整个过程中，公网用户除了极个别在切换瞬间正在发起请求的用户可能会遭遇一次短暂的微秒级延迟外，没有任何一个人会看到“502 / 无法访问”的崩溃页面。
3. 服务自愈：当我们在 ECS_01 上重新执行 sudo systemctl start nginx 修复服务后，10秒内 SLB 探测成功，自动将其拉回集群，流量重新开始均衡分发。

五、 云计算资深从业者的高阶架构建议

完成以上配置后，你的网站已经具备了抵抗单物理节点故障的能力。但如果要达到金融级、大厂级的在线可用率（99.99% 以上），我还建议你在后续的系统演进中，将以下高阶技术栈纳入考量：

1. HTTPS 卸载（SSL 加密加速）：
   将企业的 SSL 证书直接上传并部署在 SLB 实例上，在 SLB 端终结 HTTPS 流量。SLB 内部与后端 ECS 之间继续走高效的 HTTP 80 端口传输。这样做能够将繁重的 SSL 握手与加解密计算全部交由 SLB 底层的硬件芯片加速，彻底释放后端 ECS 的 CPU 算力。
2. 联动弹性伸缩（Auto Scaling）：
   将虚拟服务器组与阿里云的“弹性伸缩”服务绑定。当遇到双11大促或突发热点，后端 ECS 整体 CPU 利用率超过 70% 时，阿里云会自动秒级创建全新的 ECS 实例，自动安装代码并动态塞入 SLB 的后端服务器组中参与分流；当洪峰退去，自动缩容销毁，帮企业将 IT 成本卡到最省。
3. 安全防护一体化（WAF 联动）：
   SLB 负责转发，但无法抵御高深的 Web 攻击。将 Web 应用防火墙（WAF） 部署在 SLB 之前，让所有流量先经过 WAF 洗白（过滤 SQL 注入、XSS 跨站脚本、恶意爬虫），再由 SLB 分发，是保障高可用与核心数据安全的黄金防御链。

总结

负载均衡 SLB 绝不仅仅是一个简单的流量转发器，它是现代分布式云原生架构的“交通警察”与“安全网关”。通过跨可用区混布 ECS，配合严密的健康检查参数设计，你便亲手用阿里云的最简基础设施，为企业搭建起了一座坚不可摧、随时横向扩容的高可用 Web 架构堡垒。