AWS欧洲站账号 亚马逊云负载均衡实测

话说那天凌晨三点，我盯着监控面板上那根突然飙升的CPU曲线，手指悬在键盘上方，像极了高考前夜背不完的《滕王阁序》——紧张、茫然，还带点自欺欺人的镇定。

服务器崩了？没崩。数据库卡了？没卡。查来查去，发现是单台EC2扛不住秒杀流量，而我之前图省事，把所有用户请求全塞进一台t3.medium里，美其名曰“轻量起步”。结果起步起得像火箭，落地落得像陨石。

于是，我决定亲手把亚马逊云的负载均衡器（Load Balancer）从说明书里拽出来，按在地上，挨个测试——不是看文档，是真刀真枪配、压、断、切、算。

一、先别急着选：AWS有仨“LB”，长得像，脾气差远了

AWS官方把负载均衡器分成三类：ALB（Application Load Balancer）、NLB（Network Load Balancer）、GLB（Gateway Load Balancer）。别被名字骗了，它们根本不是兄弟，是表亲+远房堂叔+隔壁村二舅。

• ALB：HTTP/HTTPS协议专家，懂Cookie、能路由到不同路径（/api → 后端A，/static → 后端B），还能干SSL卸载、WAF联动、重定向这种“精细活”；
• NLB：TCP/UDP硬汉，毫秒级延迟，扛得住百万级并发连接，但你跟它说“请把/user开头的请求转给灰度组”，它只会沉默并把你IP封进黑名单；
• GLB：专为防火墙、IDS这类“网络中间件”设计的网关型LB，普通业务几乎用不上——除非你正搭零信任架构，否则建议把它当彩蛋跳过。

我们这次实测主角：ALB 和 NLB。GLB？等我哪天要部署Suricata集群再约。

二、动手！10分钟搭出ALB：比煮泡面还顺

登录AWS控制台 → EC2 → Load Balancers → Create Load Balancer → Application Load Balancer。

关键配置四步走：

1. VPC与子网：必须选至少两个可用区（比如us-east-1a + us-east-1b），否则健康检查会报“Subnet not available”——别问，问就是AWS强制高可用，不惯单点懒癌；
2. 安全组：只开443和80，千万别手滑放行22或3389——那是给运维留的后门，不是给LB开的敞篷车；
3. 目标组：新建一个，协议HTTP:8080，健康检查路径设为/healthz（不是/！因为首页可能返回200但DB已挂，而/healthz必须查DB连通性）；
4. 注册实例：挑两台已装好Nginx、监听8080、且返回{"status":"ok"}的EC2——别忘了打标签Environment=prod，后面自动发现要用。

创建完成，等2分钟，状态从“provisioning”变成“active”，你就拥有了人生第一台ALB。域名长这样：myapp-123456789.us-east-1.elb.amazonaws.com。复制进浏览器，看到Nginx欢迎页？恭喜，你已超越80%只读文档不实操的同行。

三、NLB实测：快得反常，也“傻”得真实

创建NLB流程类似，但注意三个魔鬼细节：

• 协议只能选TCP/UDP/TLS，HTTP？不存在的；
• 健康检查只有TCP连接成功与否，不验HTTP状态码——哪怕你返回503，只要端口通，NLB就认为你活着；
• 它没有“路径路由”，没有“Host头匹配”，甚至不改源IP（开启“Preserve client IP”后，后端日志里能看到真实用户IP）。

我们拿NLB压测：用hey -n 10000 -c 200 https://alb-domain/ vs hey -n 10000 -c 200 http://nlb-ip:8080/（NLB默认不支持HTTPS直连，得套CloudFront或自己做TLS终止）。

结果：ALB平均延迟32ms，NLB仅8.3ms。快是真快，但当你发现用户上传头像失败，查日志全是502 Bad Gateway，才想起——ALB能自动重试失败请求，NLB不行。它只管转发，死活不背锅。

四、最痛一课：健康检查不是摆设，是生死线

某次发布新版本，我更新了后端API，忘了同步改/healthz接口逻辑。ALB持续探测返回500，30秒后就把两台实例全踢出目标组。用户打不开首页，我还在 Slack 里跟产品吹“灰度发布很稳”……

教训：健康检查路径必须独立、轻量、强语义。我们后来改成：

GET /healthz → 检查进程存活 + 本地Redis连通性
GET /readyz → 检查MySQL主库 + 外部支付网关
GET /livez → 仅检查进程（供K8s liveness用）

ALB只认/healthz，NLB只认端口通不通——所以，NLB后端建议加一层轻量代理（如Envoy），把TCP健康探针翻译成HTTP语义。

五、故障演练：拔网线、删实例、关服务

AWS欧洲站账号 我们故意在ALB后端停掉一台EC2：

• 30秒内，ALB标记该实例“unhealthy”，停止转发；
• 剩余实例流量翻倍，但P99延迟仅上涨7%，无错误；
• 重启实例后，ALB约45秒重新纳入——这45秒可配，最小10秒，但太短易误判抖动。

再暴力拔NLB后端服务器网线：

• NLB在3秒内检测到TCP连接中断（比ALB快得多）；
• 但不会重试，直接返回RST包给客户端——浏览器显示“ERR_CONNECTION_RESET”，而非503；
• 用户感知更差，但对游戏、IoT这类低延迟场景，反而更可控。

六、钱呢？这才是深夜惊醒的原因

ALB：$0.0225/小时 + $0.008/GB处理流量 + $0.0001/LCU小时（LCU≈1个新连接+1000个请求+1GB数据）；

NLB：$0.025/小时 + $0.006/GB + $0.006/每1000个新连接。

实测10万日活、峰值2000 QPS的小站：

• ALB月账单≈$43（含流量+LCU）；
• NLB月账单≈$31（连接数少，但小时费略高）；
• 如果加WAF、ACM证书、CloudWatch告警——ALB生态无缝，NLB得自己搭NGINX做SSL终止，人力成本早超差价。

七、终极建议：别抄架构图，抄场景

✔️ 选ALB：你跑Web、App、微服务，需要路径路由、重定向、WAF集成、蓝绿发布；
✔️ 选NLB：你跑实时音视频、在线游戏、高频交易，或后端是裸金属/K8s NodePort，且必须透传源IP；
❌ 别折腾GLB：除非你在写《企业级零信任实践白皮书》。

最后送一句血泪总结：LB不是万能胶，而是交通警察。它不修路，不造车，也不教司机开车——但它得认得清红绿灯，分得明左转右转，还得在事故现场冷静拉隔离带。

而你，得先搞懂自己的车，再决定请哪位交警上岗。