NLB和ALB结合的场景和优缺点

要理解 NLB（网络层负载均衡，L4）与 ALB（应用层负载均衡，L7）结合 的场景和优缺点，首先需要明确两者的核心定位差异——NLB 聚焦于 L4（TCP/UDP 协议层） 的高性能流量分发，ALB 聚焦于 L7（HTTP/HTTPS 应用层） 的精细化路由与业务功能，二者结合本质是 “L4 高性能打底 + L7 业务灵活性补位” 的架构设计。

一、先明确：NLB 与 ALB 的核心差异

在分析结合场景前，需先理清两者的核心能力边界，这是“结合”的逻辑基础：

二、NLB + ALB 结合的典型场景

当业务同时满足 “高性能/高并发需求” 和 “L7 精细化业务需求” 时，单独使用 NLB 或 ALB 均存在短板，此时二者结合成为最优解。以下是核心场景：

1. 大型互联网应用：高并发 + 多业务模块路由

场景描述：电商平台、短视频 App、大型官网等，高峰期需承载百万级并发，且后端拆分为多个业务模块（如商品详情、购物车、支付、用户中心），需按 URL 路径分发流量。
为什么需要结合：

• 单独 NLB 不足：仅能按“IP + 端口”转发，无法区分 /product（商品）、/pay（支付）等路径，无法将不同模块流量路由到对应后端集群。
• 单独 ALB 不足：在高峰期（如双 11），ALB 的并发能力可能成为瓶颈（多数 ALB 并发上限低于 NLB），无法扛住超大流量冲击。
  结合逻辑：
  客户端流量 → NLB（L4 层，抗高并发，跨可用区分发）→ 多台 ALB（每台 ALB 负责一个或多个业务模块，如 ALB1 处理商品，ALB2 处理支付）→ 后端业务集群。
  示例：AWS 电商平台用 NLB 作为入口扛住峰值流量，再转发到不同 ALB 处理“商品搜索”“订单提交”等细分场景。

2. 微服务架构：多服务隔离 + 横向扩展

场景描述：微服务架构下，后端有数十个微服务（如用户服务、订单服务、库存服务），每个服务需独立的流量入口、SSL 证书和路由规则，且需支持服务实例的动态扩缩容。
为什么需要结合：

• NLB 负责“入口收敛”：将外部流量统一接入 NLB，避免为每个微服务暴露独立入口（减少攻击面），同时 NLB 支持动态更新目标组（ALB 集群扩缩容时自动适配）。
• ALB 负责“服务隔离”：每个微服务对应一个 ALB（或 ALB 中的一个目标组），ALB 可针对该服务配置专属 SSL 卸载（如支付服务用 EV 证书）、L7 健康检查（如检查 /health 接口返回 200）。
  结合逻辑：
  客户端 → NLB（统一入口，负载到 ALB 集群）→ 各 ALB（绑定不同微服务，如 ALB-User 对应用户服务）→ 微服务实例。

3. 跨可用区/跨区域部署：高可用 + 就近访问

场景描述：业务部署在多个可用区（AZ）或跨区域，需保证“单 AZ 故障不影响服务”，且让用户流量优先转发到就近的 AZ，降低延迟。
为什么需要结合：

• NLB 支持跨 AZ 转发：多数云厂商的 NLB（如 AWS NLB、阿里云 SLB 四层）可跨 AZ 部署，当一个 AZ 的 ALB 故障时，NLB 自动将流量切换到其他 AZ 的 ALB，实现全局高可用。
• ALB 负责 AZ 内精细路由：每个 AZ 内部部署 ALB，处理该 AZ 内的服务流量，避免跨 AZ 转发带来的延迟（NLB 仅在 AZ 故障时跨 AZ 切换）。
  结合逻辑：
  用户 → NLB（跨 AZ 负载，优先转发到就近 AZ）→ AZ 内 ALB → 该 AZ 的后端服务。

4. 混合流量场景：HTTP 与非 HTTP 流量共存

场景描述：业务同时对外提供 HTTP 服务（如 Web 页面）和非 HTTP 的 TCP 服务（如 MySQL 只读库、WebSocket 长连接、MQ 集群），需统一入口且分开处理不同流量。
为什么需要结合：

• NLB 支持多协议：可同时处理 HTTP（转发到 ALB）和 TCP（直接转发到后端服务，如 MySQL）流量，实现“一口多能”。
• ALB 专注 HTTP 优化：将 HTTP 流量交给 ALB 处理，利用其 SSL 卸载、路径路由等功能；非 HTTP 流量由 NLB 直接转发，减少中间层延迟。
  结合逻辑：
  用户流量 → NLB（按端口区分：80/443 转发到 ALB，3306 转发到 MySQL 只读库）→ ALB（处理 HTTP）/ 后端 TCP 服务。

三、NLB + ALB 结合的优点

二者结合的核心价值是 “扬长避短”，将 L4 的性能与 L7 的灵活性叠加，具体优点如下：

1. 性能与灵活性兼顾

• NLB 扛高并发：解决 ALB 在超大流量下的性能瓶颈，支持百万级并发连接和每秒数十万请求（RPS），满足秒杀、直播等峰值场景。
• ALB 做精细控制：实现路径路由（如 /api/v1 转发到新服务，/api/v2 转发到旧服务）、基于主机头的虚拟主机（如 a.example.com 和 b.example.com 共用一个入口）、会话保持（如用户登录后固定转发到同一后端实例）。

2. 高可用与扩展性更强

• 多层高可用：NLB 跨 AZ 部署，ALB 集群内多实例部署，形成“NLB 级 + ALB 级 + 后端服务级”的三层冗余，单节点故障不影响整体服务。
• 动态扩展适配：后端服务实例扩缩容时，仅需更新 ALB 的目标组；ALB 集群扩缩容时，仅需更新 NLB 的目标组，无需修改客户端配置（入口 IP 不变）。

3. 功能叠加与安全增强

• 功能互补：NLB 提供静态公网 IP（便于 DNS 解析和防火墙配置）、客户端 IP 透传（后端服务可获取真实用户 IP）；ALB 提供 SSL 卸载（减少后端服务 CPU 消耗）、L7 健康检查（比 L4 更精准，避免“端口通但服务挂”的问题）、WAF 集成（防御 SQL 注入、XSS 等 L7 攻击）。
• 安全分层：NLB 作为外层屏障，可过滤 L4 级攻击（如 TCP 洪水攻击）；ALB 作为内层屏障，通过 WAF 防御 L7 级攻击，形成“多层防护”。

四、NLB + ALB 结合的缺点

结合架构也带来了 复杂度、成本、延迟 等问题，需在设计时权衡：

1. 架构复杂度提升

• 部署与维护成本高：需同时配置 NLB 和 ALB 的目标组、监听规则、安全组（如 NLB 需允许客户端流量，ALB 需允许 NLB 流量），且需确保两层配置的一致性（如端口映射、SSL 证书有效期）。
• 故障排查难度大：流量经过两层转发，故障定位需分步骤（先查 NLB 是否转发正常 → 再查 ALB 路由是否正确 → 最后查后端服务），需配套完善的监控（如 NLB 转发成功率、ALB 4xx/5xx 错误率）。

2. 额外延迟开销

• 虽然 NLB 转发延迟极低（微秒级），但“NLB → ALB”的额外一跳会增加 1~5ms 的延迟（具体取决于网络环境）。对于超低延迟场景（如高频交易、实时游戏），可能需要评估是否可接受。

3. 资源与成本增加

• 云资源成本：多数云厂商的负载均衡服务按实例/流量收费，两层负载均衡的成本比单层（仅 NLB 或仅 ALB）高 50%~100%（如 AWS NLB + ALB 的组合费用高于单独 ALB）。
• 计算资源消耗：ALB 集群需占用额外的计算资源（如 CPU、内存），尤其在 SSL 卸载场景下，ALB 的 CPU 消耗会显著增加。

五、总结：适合与不适合的场景

总之，NLB + ALB 结合是 “高性能场景下的精细化方案”，核心是用 NLB 解决“流量入口的性能与高可用”，用 ALB 解决“应用层的业务灵活性与安全”，但需承担额外的复杂度和成本。