AWS 家族中新添对扩展友好的 Network Load Balancer

AWS 推出了一种称为 NLB （Network Load Balancer）的新服务，NLB 迎合了高性能应用的需求，扩展了 ELB（Elastic Load Balancer）服务。NLB 是 TCP 第四层的组件，设计用于处理突发流量和每秒百万次请求。

ELB 大约是在 2009 年推出的，用于 EC2 虚拟机的负载均衡。最初的负载均衡提供了 HTTP/S 及 TCP 路由、SSL 卸载（SSL Offloading）、对 VPC（Virtual Private Cloud）的支持以及与 EC2 Security Group 的集成。去年， Amazon 在 ELB 产品家族中添加了 ALB（Application Load Balancer）服务。ALB 是一种第七层的负载均衡器，实现了基于路径和主机的 HTTP 路由、对 WebSockets 的支持并且是对容器友好的。虽然经典的 ELB 服务和 ALB 都能根据需求做透明的扩展，但众所周知的是两者都存在着“预热延迟”（Warm-up Delay）问题。此外，两者都不提供静态IP 地址。新推出的NLB 解决了这两个问题。

NLB 从设计上就适用于“极端性能”情况，架构中考虑了“突发性不稳定流量模式和……极低的延迟”。它提供了静态IP 地址，可以被“硬编码到DNS 记录、用户定制的防火墙规则等之中”。NLB 为用户提供了与ALB 兼容的API、源IP 地址保持、长连接、健康检查及日志等功能。但是由于NLB 是一种第四层的负载均衡器，它并不提供 HTTP 可感知功能，例如基于路径或主机的路由、SSL 卸载或是粘性会话（Sticky Session）。尽管关注 NLB 的用户在 Nacker News 上表示出可接受的积极态度，但是他们对于缺失与Security Groups 的集成和TLS Termination 功能依然感到忧虑。

AWS力图澄清各负载均衡器服务的适用场景，并将“经典”的 ELB 清晰地定义为一种次要选项。

Network Load Balancer（NLB）的理想应用场景是 TCP 流量的负载均衡，NLB 具备在维持超低延迟的条件下每秒处理上百万次请求的能力。NLB 被优化用于在每个 Availability Zone 使用一个单一静态 IP 地址的情况下，处理突发的和不稳定的流量模式。

Application Load Balancer（ALB）的理想应用场景是 HTTP 和 HTTPS 流量的高级负载均衡，ALB 提供支持现代应用架构的高级请求路由，其中包括微服务和基于容器的应用。

Classic Load Balancer（CLB）的理想应用场景是那些构建在 EC2-Classic 网络内的应用。

对于公开云服务提供商而言，负载均衡是一个“入场筹码”。Google Cloud 为其客户提供了公开的或内部的负载均衡。声称具备无需“预热”（Warm-up）的突发处理功能，所交付的功能包括支持静态IP、HTTP/S 或TCP 路由、SSL 卸载、用户关联性（User Affinity）和跨多区域路由。Microsoft 也给出了用于Azure 云的全面负载均衡解决方案。其中，Azure Load Balancer 服务为同一Azure 数据中心中的各应用实例提供了第四层路由，Application Gateway 是一种可担当反向代理的第七层路由，Traffic Manager 对所有终端实现了由DNS 驱动的路由。

与ALB 一样，NLB 也采用“LCU”（Load Balancer Capacity Units）计费方式。单个 LCU 每小时的费用是 0.006 美元，根据用户在创建的连接数、活跃的连接数和带宽等维度上的最大使用情况计费。NLB 在所有的商用 AWS 区域上可用（除了中国地区），并已经集成到 AWS Cloud Formation、Amazon Elastic Container Service 和 EC2 Auto Scaling 中。

查看英文原文： AWS Adds Scale-Friendly Network Load Balancer to its Arsenal