新一代负载均衡器服务 NLB 概述

在去年 9 月份，AWS 发布了托管的网络负载均衡器服务 Network Load Balancer，NLB 是继 Classic Load Balancer，Application Load Balancer 之后，AWS 发布的第三款负载均衡器服务，本文将着重介绍 NLB 的工作原理，特点以及在使用配置上的注意事项，帮助读者更好地在自己的业务场景中运用 NLB 服务。

NLB 能够在极低的延迟下，支持每秒数千万的请求，在 API 上兼容现有的 ALB 应用负载均衡器，下面是 NLB 的一些主要功能和特点：

• 静态 IP 地址

每个 NLB 在每个可用区中提供单个静态 IP 地址，用户端发往该 IP 地址的流量会被负载分发到同可用区内的多个后端实例上，用户可以为 NLB 在每个可用区中分配固定的弹性 IP，如此设计使得 NLB 能够被纳入企业现有的防火墙安全策略中，并且能够避免 DNS 缓存带来的问题。

• 同可用区内分发流量

客户端的流量到达 NLB 在某个可用区提供的 IP 后，NLB 会向相同可用区内的后端实例分发流量，通过避免跨可用区的流量分发能够获得更好的延迟性能。

• 源地址保留

NLB 在转发流量的同时，并不会修改数据包的源 IP 地址，后端实例无需支持诸如 X-Forward-For，proxy 协议，就能够直接从数据包的包头获取客户端的 IP，从而很方便地分析客户端的地理位置等信息。

• 长连接支持

NLB 内置的容错机制能够保证长连接应用的稳定运行，从而更好的贴合诸如 IoT，游戏，消息应用等业务场景。

• 故障切换

利用 Route 53 的健康检查，NLB 支持在一个区域内及跨区域和本地站点实现故障切换。

下面我们来看一下如何在 AWS 控制台创建 NLB，可以看到，客户在创建负载均衡器页面中，目前可以有三种负载均衡器可选，我们选择 NLB。

NLB 和其他 AWS 提供的负载均衡器一样，支持创建面向 internet 及 internal 两种场景，除此之外，用户需要配置 NLB 监听的端口及所处的子网，如果创建面向 internet 的 NLB，需要注意将 NLB 放到公有子网中。

考虑 NLB 本身的冗余，建议至少选择 2 个可用区，同时用户可以根据需要为 NLB 在每个可用区绑定弹性 IP。

后续的配置与 ALB 的配置十分类似，用户需要配置目标组，目标组监听的协议、端口以及健康检查等相关配置，目前无论 ALB 还是 NLB 都支持将 EC2 实例及某个 IP 作为目标，前者实现 VPC 内部的负载均衡，后者通过 IP 可以为本地站点的实例提供负载均衡。

这里选择实例类型的目标类型，之后需要选择注册的实例。

需要注意的是，为了能够接受外部客户端的访问以及健康检查流量，建议后端实例的安全组做如下设置，如果用户觉得健康检查源地址设置 VPC CIDR 过于宽泛的话，建议可以设置为 NLB 的私有 IP，NLB 的私有 IP 可以在 ENI 界面通过 NLB 名字搜索到相关 NLB 的 ENI 来获取。

除了安全组设置上的考虑，对于面向 internet 的 NLB 来说，后端实例收到的流量的源 IP 地址是处于公网的客户端 IP，对于接收 internet 流量的这部分后端实例，建议放到公有子网中，即默认路由指向 IGW，如果用户不希望后端实例能够被外界直接访问，可以在将后端实例放入公有子网的同时，选择不分配公网 IP，从而保证外界只能通过 NLB 来访问到后端实例。

选择完后端实例后，就可以完成 NLB 的创建。

NLB 对外提供的是一个域名，客户端通过访问该域名将流量发给 NLB，用户可以通过设置 DNS CNAME 记录来方便客户端通过自定义的域名来访问用户的后端系统。

以上介绍了面向 internet 的 NLB 的配置方法，对于面向 internal 的 NLB，用户可以做类似的配置，这里不做过多的介绍，只是如果 NLB 后端对接的是容器业务，并且网络模式是 bridge 模式，需要做额外的考虑。

这里先给出结论再解释相关的原理，对于两个需要通过 NLB 互访的内部容器应用，建议将这两个应用的容器调度到不同的 EC2 节点上，对于 AWS ECS，用户可以通过为两个应用创建不同的 ECS Cluster 或者在一个 ECS Cluster 内通过亲和性调度算法实现。

为什么需要做上述的设置呢？下面解释下如果将这两个应用调度到相同的 ECS Cluster 上会出现什么问题。

在上面这个场景中，App1 和 App2 使用容器部署在 EC2 中，App1 需要通过 NLB 来访问 App2，如果网络模式使用 bridge，App1 的流量在发出所在 EC2 实例的时候，源 IP 地址会从 App1 的容器 IP 转换成 EC2 的 IP，如果 NLB 通过负载分发算法将流量发往处于相同 EC2 上的 App2 容器，NLB 会将目的 IP 转换成相同的 EC2 的 IP 地址，流量到达 EC2 后，EC2 会将目的 IP 转换成 App2 的容器 IP，问题在于 App2 回包的时候，当流量到达 EC2 OS 层，OS 通过查询路由表发现目的地址是自己，会在 OS 层面直接处理流量，而不会将流量返回给 NLB，导致 App1 访问 App2 失败。

这个问题是由于 NLB 的工作原理导致的，NLB 在接收到流量后，保持源 IP 地址不变，通过负载均衡算法选择后端实例，并将目的 IP 转换成后端实例的 IP 地址进行流量分发，我们需要在设计上避免上述问题，将 App1 和 App2 的容器调度到不同的 EC2 实例上，从而在根本上避免 App1 访问 App2 的流量的发起和终止在同一台 EC2 实例上。

以上我们的介绍了 NLB 的主要特点，配置方法及常见的配置注意事项，读者如果感兴趣的话，可以通过下面的链接来进一步学习 NLB 的相关内容：

https://aws.amazon.com/documentation/elastic-load-balancing/

https://aws.amazon.com/elasticloadbalancing/faqs/

作者介绍

余骏，AWS 解决方案架构师，负责基于 AWS 的云计算方案架构的咨询和设计，同时致力于 AWS 云服务在国内的应用和推广。在加入 AWS 之前，在思科中国担任系统工程师，负责方案咨询和架构设计，在企业私有云和基础网络方面有丰富经验。

本文转载自 AWS 技术博客。

原文链接：

https://amazonaws-china.com/cn/blogs/china/overview-of-nlb/