Amazon Elastic Load Balancing 负载均衡高可用架构：给你的服务器配一个顶级的“流量交警”

cloud 2026-05-27 阅读 10

在互联网世界里，最让架构师和老板睡不着觉的，莫过于两件事：一是突如其来的流量暴增把服务器冲垮，二是某台服务器突然“宕机”导致全站瘫痪。

如果把你的后端服务器集群比作一家银行的柜员，当只有一两个客户时，大家相安无事。但当双十一、黑五或者突发新闻来临，成千上万的客户瞬间涌入，单靠一个柜员不仅会排起长队（网站卡顿），柜员甚至会因为过劳而直接崩溃（服务器宕机）。

怎么破？你需要一个精明能干的“大堂经理”来维持秩序，把客户均匀地分配到各个空闲的窗口。在亚马逊云科技（AWS）的生态里，这个角色就是 ELB（Elastic Load Balancing，弹性负载均衡）。

今天，我们不用晦涩的 PPT 术语，而是用纯粹的实战派视角，深度拆解如何利用 ELB 搭建一套坚不可摧的“高可用负载均衡架构”。

一、核心选型：三大 ELB 家族成员，你该挑哪一个？

AWS 的 ELB 并不是一个单一的产品，而是针对不同的业务场景，派生出了三个主要方向。选错型号，就像是用跑车去拉货，或者用卡车去赛跑，既浪费钱又达不到效果。

1. ALB (Application Load Balancer) —— 应用负载均衡器

定位：专注于 HTTP/HTTPS 流量（也就是网络七层协议中的应用层）。
绝活：高级路由功能。它能看懂请求的内容。比如，用户访问 example.com/api，ALB 可以把请求转给 API 服务器集群；用户访问 example.com/images，它又可以把请求转给图片服务器集群。它还支持基于域名（Host）、Header 甚至查询字符串来分发流量。
适用场景：绝大多数的 Web 应用、微服务架构、容器化应用（ECS/EKS）。

2. NLB (Network Load Balancer) —— 网络负载均衡器

定位：专注于 TCP/UDP/TLS 流量（网络四层协议中的传输层）。
绝活：极致的性能与超低延迟。NLB 能够处理每秒数以百万计的突发请求。更厉害的是，它支持静态 IP 地址。每个可用区都可以绑定一个固定的弹性 IP，这对于需要做防火墙白名单的企业级对接来说，简直是刚需。
适用场景：游戏服务器、高频金融交易系统、物联网（IoT）数据接收端。

3. GLB (Gateway Load Balancer) —— 网关负载均衡器

定位：专门用来管理第三方虚拟安全设备的（如防火墙、入侵检测系统）。
适用场景：大厂用来做全站流量的安全审计和清洗。通常中小型业务很少直接用到它。

二、高可用架构设计：ELB 是如何实现“故障自愈”的？

很多新手会有个疑问：“我把流量都交给了 ELB，那万一 ELB 自己挂了怎么办？它不就成了单点故障（Single Point of Failure）了吗？”

AWS 早就考虑到了这一点。ELB 名字里的 Elastic（弹性） 包含两层含义：容量的弹性和架构的弹性。

1. 跨可用区（Multi-AZ）高可用

在设计 ELB 架构时，最核心的原则就是绝不把鸡蛋放在一个篮子里。

AWS 的每个地理区域（Region）都包含多个彼此独立的可用区（Availability Zone，简称 AZ）。每个 AZ 都有独立的电力、网络和散热系统。

当你创建 ELB 时，系统会强制要求你选择至少两个可用区。实际上，ELB 会自动在每一个你选中的可用区里，各部署一个负载均衡的“节点（Node）”。

当用户发起请求时，DNS 会把流量轮询分发到这些不同的可用区节点上。
如果 A 可用区遭遇暴雨断电彻底瘫痪，ELB 顶层的 DNS 解析会自动把流量切走，全部灌入 B 可用区的节点。整个过程对用户来说完全无感知。

2. 健康检查（Health Check）：精准剔除“害群之马”

ELB 能够保持高可用的另一大杀手锏是健康检查。

你必须为 ELB 配置一个规则，比如：每隔 10 秒，向后端服务器的 /health 路径发送一个 HTTP 请求。如果连续 3 次返回 200 OK，说明服务器活着；如果连续 2 次没有回应，就判定该服务器“生病”了。

一旦某台服务器被判定为不健康，ELB 会立刻将其拉黑，不再向它发送任何新流量，直到它恢复正常。这成功避免了“因为一台服务器死机，导致 1/3 的用户访问报错”的惨剧。

三、实战演练：手把手搭建一套 ALB + Multi-AZ 高可用 Web 架构

接下来，我们以最经典的 ALB 为例，走一遍生产环境的标准配置流程。

第一步：准备后端“目标组（Target Group）”

在配置负载均衡器之前，我们要先告诉它“把流量发给谁”。在 AWS 里，这个后端的集合叫做目标组。

打开 EC2 控制台，在左侧导航栏找到 Target Groups，点击 Create target group。
选择目标类型，通常选择 Instances（实例），输入名字。
协议与端口：选择 HTTP:80（或者你的应用运行的端口）。
Health checks（健康检查）：检查路径通常写你的服务状态接口，比如 / 或 /status.html。展开高级设置（Advanced health check settings），把“健康阈值”设为 3，“不健康阈值”设为 2，“超时时间”设为 5 秒，“间隔”设为 10 秒。
点击 Next，把你在不同可用区（比如 AZ-A 和 AZ-B）启动的 Web 服务器实例勾选进来，点击 Create target group。

第二步：创建 Application Load Balancer

在左侧导航栏点击 Load Balancers，点击 Create load balancer，选择 Application Load Balancer。
Scheme（方案）：选择 Internet-facing（面向互联网）。如果是对内网微服务做负载，才选 Internal。
Network mapping（网络映射）：选择你的 VPC。关键步骤：勾选至少两个可用区（例如 us-east-1a 和 us-east-1b），并选择每个可用区对应的公网子网（Public Subnet）。💡 架构避坑指南：ALB 自身必须驻留在公网子网中，这样它才能拿到公网 IP 接收互联网流量。但是！你的后端 Web 服务器（EC2）可以、且强烈建议放在**私网子网（Private Subnet）**里。这样，外界没有任何人能直接通过 IP 攻击你的服务器，所有的安全防护都由前端的 ALB 来扛，架构安全性瞬间拉满。

第三步：配置安全组（Security Groups）与监听器

Security groups：为 ALB 关联一个安全组，必须放通 TCP 80（HTTP）和 TCP 443（HTTPS）端口。
Listeners and routing（监听器与路由）：默认有一条 HTTP:80 的监听器，在 Forward to（转发至）下拉菜单中，选择我们第一步创建的那个“目标组”。如果有 SSL 证书，点击 Add listener，添加一条 HTTPS:443，并配置你的域名证书。

点击最下方的 Create load balancer。大约 2 分钟后，ALB 状态变为 Active，你将获得一个长长的 DNS 名称（例如：my-alb-123456789.us-east-1.elb.amazonaws.com）。

四、高级进阶：与 Auto Scaling（弹性伸缩）合体，成就终极高可用

如果你只配了 ELB，当流量真的超过后端服务器的总承受极限时，网站依然会卡死。ELB 只是个大堂经理，它没办法凭空变出更多的柜员。

要实现真正的“弹性自由”，你需要把 ELB 和 Auto Scaling（自动弹性伸缩） 绑定在一起。

[用户请求] -> [ELB] -> [根据流量自动增加/减少 EC2 数量 (Auto Scaling Group)]

当双十一零点来临，流量暴增：

CloudWatch 监控发现后端服务器的平均 CPU 飙升到了 80%。
Auto Scaling 收到信号，立刻自动打包创建 5 台全新的 EC2 服务器。
最奇妙的地方在这里：新服务器启动后，Auto Scaling 会自动向 ELB 的目标组报到：“报告经理，我是新来的柜员，已经准备就绪！”
ELB 收到通知，立刻开始把后续的流量分流给这 5 台新服务器，整个过程不需要人工改动任何一行配置或重启任何设备。
凌晨两点流量退去，CPU 降下来了，Auto Scaling 会自动销毁这 5 台机器省钱，ELB 也会优雅地断开连接（Deregistration Delay），确保正在处理的请求正常结束后，再把它们移出集群。

结语

在现代云原生架构中，Amazon ELB 绝对不是一个简单的“流量转发器”，它是整个高可用架构的指挥官。

它通过跨可用区的节点部署防范了物理级别的灾难，通过严格的健康检查隔离了系统内部的故障，又通过与 Auto Scaling 的完美配合赋予了业务无限延展的可能。搞懂了 ELB 的运行逻辑与配置细节，你就握住了搭建高并发、不宕机现代化网站最核心的那把钥匙。