NLB

NLB 是什么？

NLB 全称为 Network Load Balancer，是在开放系统互连（OSI）模型的第四层运行。它每秒可以处理数百万个请求。在负载均衡器收到连接请求后，它会从默认规则的目标组中选择一个目标，尝试在侦听器配置中指定的端口上打开一个到该选定目标的 TCP 连接。

当您为负载均衡器启用可用区时，Network Load Balancing 会在该可用区中创建一个负载均衡器节点。默认情况下，每个负载均衡器节点仅在其可用区中的已注册目标之间分配流量。如果您启用了跨区域负载均衡，则每个负载均衡器节点会在所有启用的可用区中的已注册目标之间分配流量。

有关更多信息，请参阅：

https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#cross-zone-load-balancing

如果为负载均衡器启用多个可用区，并确保每个目标组在每个启用的可用区中至少有一个目标，那么这将提高应用程序的容错能力。例如，如果一个或多个目标组在可用区中没有运行状况良好的目标，我们会从 DNS 中删除相应子网的 IP 地址，但其他可用区中的负载均衡器节点仍可用于路由流量。如果一个客户端不遵守生存时间（TTL）而将请求发送到已从 DNS 删除的 IP 地址，则请求会失败。

负载均衡器节点基于协议、源 IP 地址、源端口、目标 IP 地址、目标端口和 TCP 序列号，使用流式哈希算法选择目标。来自客户端的 TCP 连接具有不同的源端口和序列号，可以路由到不同的目标。每个单独的 TCP 连接在连接的有效期内路由到单个目标。

Network Load Balancing 为您启用的每个可用区创建一个网络接口。可用区内的每个负载均衡器节点使用该网络接口来获取一个静态 IP 地址。在您创建面向 Internet 的负载均衡器时，可以选择将一个弹性 IP 地址与每个子网关联。

您可以配置一个目标组，以便通过实例 ID 或 IP 地址注册目标。如果您使用实例 ID 指定目标，则客户端的源 IP 地址将保留并提供给您的应用程序。如果您用 IP 地址指定目标，则源 IP 地址是负载均衡器节点的私有 IP 地址。

您可以根据需求变化在负载均衡器中添加和删除目标，而不会中断应用程序的整体请求流。Network Load Balancing 根据传输到应用程序的流量随时间的变化对负载均衡器进行扩展。Network Load Balancing 能够自动扩展来处理绝大部分工作负载。

 

NLB 的特色

• 高度可扩展且低延迟

NLB 在微秒级别提供非常低的延迟，这对于像 Ad Tech 和 IoT 等对延迟敏感的行业客户极为重要。此外，它还可以按需扩展以负载平衡数百万请求/秒。

• 高可用性

NLB 提供高度可用的负载均衡器服务，这是大量客户在过去使用 ELB 服务时期望获得并且也一直能获得的保证。

• Route-53 的 DNS 故障转移

如果您的应用程序没有响应，Route 53 将从服务中删除不可用的 NLB 端点，并将流量引导到另一个区域中的备用负载均衡器。同样，如果没有向负载均衡器注册健康的 EC2 实例，或者给定区域中的负载均衡器节点不健康，则 Route-53 会将流量定向到其他可用区中的负载均衡器节点。NLB 可以和 Route 53 结合，无论是该区域的 NLB 下面没有健康的主机，还是该区域的 NLB 发生故障，Route53 都会负责将流量导向其他的 AZ。（Route 53 目前仅由其他全球区域提供服务）

• 同可用区内分发流量

客户端的流量到达 NLB 在某个可用区提供的 IP 后，NLB 会向相同可用区内的后端实例分发流量，通过避免跨可用区的流量分发能够获得更好的延迟性能。注意：默认情况下 NLB 只会转发给当前添加 AZ 的后端实例，如果需要跨 AZ 转发，需要打开“ Cross-Zone Load Balancing ”的功能。

• 保留客户端源IP地址

当后端应用程序或服务收到流量时，NLB 会保留客户端源 IP（无需任何自定义标头）。然后，客户可以使用它进行进一步处理。 NLB 会保持客户端的源 IP，不会对通过的数据包做处理。

• 固定IP支持

NLB 允许客户为负载均衡器分配每个可用区（子网）的弹性 IP，为其提供固定的 IP 功能。如此设计使得 NLB 能够被纳入企业现有的防火墙安全策略中，并且能够避免 DNS 缓存带来的问题。

• 内置运行状况检查

NLB 自动检测失败的后端实例，并仅路由到健康实例。

• 与 AWS 服务集成

NLB 可轻松与其他 AWS 服务集成，如 Amazon Elastic Container Service（ECS），AWS CloudFormation 和 AWS Elastic BeanStalk。

• 支持 TCP 长连接

NLB 支持 TCP 长连接，即使是在 NLB 的扩展期间或更新期间也不会断开资源连接，从而能更好地支持包括 IoT、游戏、消息应用等在内的业务场景。

• 支持资源组

NLB 支持与 Application Load Balancer 相同的资源，其中包括 Listeners、Targets、TargetGroups 和规则。与 Application Load Balancer 不同，规则不会基于内容。NLB 和 ALB 一样支持 Target Group 的配置方式。

• 兼容所有现在 ELB 的 API

我们将使用与 Application Load Balancer 相同的底层 API。您可以通过调用 elbv2 create-load-balancer API，使用 AWS CLI 创建网络负载均衡器。

从上一代负载均衡器服务（Classic Load Balancer）迁移到 NLB 的好处

 

既然 NLB 有这么多优势和特点，那么您可以开始考虑从现有的 AWS 架构中的CLB 迁移到 NLB 了，因为 NLB 具有如下好处：

• 可以处理急剧波动的工作负载，并可以扩展到每秒处理数百万个请求。

• 支持将静态 IP 地址用于负载均衡器，还可以针对为负载均衡器启用的每个子网分配一个弹性 IP 地址。

• 支持通过 IP 地址注册目标，包括位于负载均衡器的 VPC 之外的目标。

• 支持将请求路由到单个 EC2 实例上的多个应用程序。可以使用多个端口向同一个目标组注册每个实例或 IP 地址。

• 支持容器化的应用程序。计划任务时，Amazon Elastic Container Service（Amazon ECS）可以选择一个未使用的端口，并可以使用此端口向目标组注册该任务。这样可以高效地使用您的群集。

• 支持单独监控每个服务的运行状况，因为运行状况检查是在目标组级别定义的，而且许多 Amazon CloudWatch 指标也是在目标组级别报告的。将目标组挂载到 Auto Scaling 组的功能使您能够根据需求动态扩展每个服务。