应用负载均衡（Application Load Balancer, ALB）是现代云架构中至关重要的组件，它位于用户和后端服务器之间，负责将传入的网络流量智能地分发到多个目标实例上，与传统的网络层负载均衡不同，ALB 工作在 OSI 模型的第 7 层（应用层），这意味着它不仅能基于 IP 地址和端口进行转发，还能深入解析 HTTP/HTTPS 请求的内容，从而实现更精细化的流量控制和安全防护。
核心工作原理与架构
ALB 的核心价值在于其“智能分发”能力，当客户端发起请求时，ALB 会监听特定的监听器端口（如 80 或 443），并根据配置的规则将请求路由到相应的目标组，目标组通常由 EC2 实例、容器或 IP 地址组成，ALB 通过持续的健康检查机制监控后端实例的状态，确保只有健康的实例才会接收流量，如果某个实例响应超时或返回错误状态码，ALB 会自动将其从可用目标列表中移除，待其恢复健康后再重新加入，从而保障服务的高可用性。
为了更直观地理解 ALB 的关键组件及其功能，可以参考下表：
| 组件名称 | 功能描述 | 关键特性 |
|---|---|---|
| 监听器 (Listener) | 配置用于处理请求的协议和端口。 | 支持 HTTP、HTTPS、TCP 等协议；可配置 SSL/TLS 终止。 |
| 规则 (Rule) | 定义如何将请求路由到目标组。 | 支持基于主机名、路径、HTTP 头、方法等条件进行匹配。 |
| 目标组 (Target Group) | 接收来自 ALB 流量的后端资源集合。 | 支持健康检查配置；支持基于权重的流量分发。 |
| 主机名路由 | 根据请求中的 Host 头将流量分发到不同后端。 | 实现单 ALB 托管多个域名或微服务。 |
| 路径路由 | 根据 URL 路径前缀将流量分发到不同后端。 | 实现 API 网关功能，如 /api 路由到后端服务，/static 路由到静态资源服务器。 |
高级流量管理策略
ALB 提供了多种高级策略来优化用户体验和系统稳定性，首先是的路由，这是 ALB 最显著的优势之一，在一个微服务架构中，你可以配置规则使得所有以 /api/v1 开头的请求被路由到处理业务逻辑的后端集群，而 /images 开头的请求则被路由到静态内容分发网络（CDN）或专门的图片处理服务，这种细粒度的控制使得单一入口点能够管理复杂的应用架构。
加权路由与蓝绿部署，在版本更新期间，ALB 允许将流量按比例分配到新旧两个目标组，初期可以将 10% 的流量引导至新版本，经过监控验证无误后，逐步增加比例直至 100%，这种策略极大地降低了发布风险，实现了平滑升级，ALB 还支持会话保持（Sticky Sessions），通过 Cookie 将特定用户的后续请求始终路由到同一后端实例，这对于需要本地缓存或无状态性较差的应用场景非常有用。
安全性与性能优化
在安全性方面,ALB 原生集成了 AWS WAF（Web 应用防火墙）和 AWS Shield 高级防护，WAF 允许用户定义自定义规则，以阻止常见的 Web 攻击，如 SQL 注入、跨站脚本（XSS）等，ALB 还可以配置 SSL/TLS 证书，在负载均衡器层面终止加密连接，从而减轻后端服务器的计算负担，提高整体吞吐量。
在性能优化上,ALB 支持HTTP/2 和 WebSocket，HTTP/2 的多路复用特性显著减少了连接开销，提升了页面加载速度；而 WebSocket 支持则使得实时通信应用（如聊天室、在线游戏）能够建立持久连接，ALB 能够透明地转发这些双向数据流，无需额外的代理配置。
常见问题与解答
问题 1：应用负载均衡器（ALB）与网络负载均衡器（NLB）的主要区别是什么？在什么场景下应选择 ALB？
解答：
ALB 和 NLB
的主要区别在于它们工作的 OSI 层级不同，NLB 工作在传输层（第 4 层），主要基于 IP 地址和端口进行转发，性能极高，延迟极低，适合处理 TCP/UDP 流量，如游戏服务器或金融交易系统，而 ALB 工作在第 7 层，能够解析 HTTP/HTTPS 内容，支持基于路径、主机名的高级路由策略，并具备 SSL 终止和 WAF 集成能力。
选择建议： 如果您的应用是基于 Web 的（HTTP/HTTPS），需要复杂的 URL 路由、域名托管或需要集成 Web 应用防火墙，应选择 ALB，如果您的应用需要极高的吞吐量、低延迟，或者使用非 HTTP 协议（如 TCP、UDP），则应选择 NLB。
问题 2：如何确保 ALB 后端实例的健康状态准确反映应用的实际运行情况？
解答：
确保健康状态准确的关键在于配置合理的健康检查（Health Check）参数，健康检查的路径应指向一个轻量级且能真实反映应用状态的端点（如 /health 或 /ping），避免使用需要复杂业务逻辑的接口，应设置合适的阈值，包括“健康阈值”（连续成功多少次标记为健康）和“不健康阈值”（连续失败多少次标记为不健康），对于高流量应用，建议缩短检查间隔（如每 10-30 秒一次），以便快速剔除故障实例，还可以配置自定义响应码，如果应用内部逻辑出错但 HTTP 状态码仍为 200，可以通过中间件返回特定的非 200 状态码，让 ALB 能更敏锐地识别异常。
原创文章，发布者：酷盾叔，转转请注明出处：https://www.kd.cn/ask/471763.html
