企业官网建设流程全解析

• 文档
• 教程
• DevOps
• 运维

本文基于 devops-exercises 仓库中的 AWS ELB 系列练习，完整讲解在 AWS 管理控制台从零创建一个 Network Load Balancer（NLB）的实操流程：包括前置的 EC2 实例准备、负载均衡器与目标组的创建步骤、健康检查参数（healthy threshold、unhealthy threshold、interval）的配置含义，以及 NLB 在四层网络中的适用场景与常见故障排查方法。读完本文，你将具备独立完成"N 台 EC2 实例 + 一台 NLB"标准四层负载均衡架构的能力，并能对照仓库中的 exercise 原文 与 solution 原文 验证每一步操作。

练习背景与仓库定位

该练习收录于仓库 topics/aws/README.md 的ELB章节，与 Application Load Balancer（ALB）、Multiple Target Groups 共同构成完整的负载均衡练习矩阵：

该练习的定位是：用最少的资源（两台 EC2 + 一台 NLB）理解 AWS 网络负载均衡器最核心的"监听器—目标组—健康检查"三角关系。仓库 AWS 章节导读 同时提示：部分练习会产生真实账单费用，无法在免费额度内完成；且提供的解法基于 AWS 控制台，官方推荐使用 Terraform、Pulumi 等 IaC 技术来完成练习——这一点可以在掌握控制台流程后再进阶实践。

前置要求：准备两台正在运行的 EC2 实例

原练习明确要求：

Requirements：Two running EC2 instances

即练习开始前，你需要在目标区域（Region）内保证有两台处于running状态的 EC2 实例。仓库提供了配套的实例准备练习，可依次完成：

1. 启动 Web 实例：参考 Launch EC2 Web Instance 练习，使用 Amazon Linux 2 镜像，安装并启动 httpd，确保index.html可访问、HTTP（80 端口）入站流量放行——这是 NLB 健康检查能够通过的前提。
2. 确认安全组规则：参考 Security Groups 练习，验证实例的安全组确实允许 80 端口入站。若移除了 HTTP 规则，实例会从健康变为不健康，这正是后续排查章节的核心知识点。

两台实例建议分布在不同的可用区（AZ），这样后续在配置 NLB 时能够更真实地体会"跨可用区高可用"的设计意图。

练习目标：创建一个网络负载均衡器

原练习的目标如下（这是整篇文章的核心验收标准，请逐项核对）：

Objectives

1. Create a network load balancer
   1. healthy threshold: 3
   2. unhealthy threshold: 3
   3. interval: 10 seconds
   4. Listener should be using TCP protocol on port 80

归纳为两点要求：

• 监听器（Listener）：使用TCP 协议、端口 80；
• 目标组健康检查：健康阈值（healthy threshold）为 3、不健康阈值（unhealthy threshold）为 3、检查间隔（interval）为 10 秒。

这四个参数的语义需要先建立清晰认知，才能明白为什么练习这样设置（详见"健康检查参数详解"一节）。

为什么选 NLB：四层负载均衡的核心定位

在动手创建前，先明确 NLB 在整个 AWS 负载均衡家族中的位置。根据 topics/aws/README.md 中 ELB 章节的问答，AWS 共有四种负载均衡器，分工明确：

• Classic Load Balancer（CLB）：主要处理 TCP（四层）与 HTTP/HTTPS（七层）流量，成本较低，适合测试/开发环境；
• Application Load Balancer（ALB）：主要处理 HTTP、HTTPS 与 WebSocket（七层），支持基于路径、查询字符串、请求头的路由；
• Network Load Balancer（NLB）：主要处理TCP、TLS 与 UDP（四层），面向超高性能与静态 IP 场景；
• Gateway Load Balancer（GWLB）：主要处理三层 IP 协议流量，常用于透明网络网关、防火墙、入侵检测等场景。

NLB 与其他类型相比的关键特性（均有仓库问答依据）：

• 工作在第四层（README 问答），直接转发 TCP/UDP 流量，不做 HTTP 层内容解析，因而转发效率更高；
• 延迟更低：README 明确指出 NLB 延迟约 100ms，而 ALB 约 400ms，适合对延迟敏感的场景；
• 每个可用区一个静态 IP：NLB 在每个启用（enable）的可用区内分配一个弹性 IP/静态 IP，便于将 IP 加入白名单或与 DNS 结合使用；
• 支持的三种目标组类型：EC2 实例、IP 地址（含应用内部 IP）、以及 ALB——"NLB 作为固定入口、ALB 作为七层路由器"是常见组合；
• 跨可用区负载均衡默认关闭：README 指出 NLB 的 cross-zone load balancing 默认 disabled（且跨 AZ 数据会收费），需要时需手动开启；这与 ALB"始终开启、不可关闭"不同；
• 不支持粘性会话：README 问答明确，sticky session 仅 CLB 与 ALB 支持，NLB 不支持。

由此可以推断本练习"Listener 使用 TCP 协议 80 端口"的设计意图：NLB 的典型用武之地正是 TCP/UDP 流量转发，练习用最简单的 HTTP over TCP 让大家聚焦于四层负载均衡的核心机制，而不引入七层路由等干扰因素。

控制台创建步骤详解（继承原 Solution）

以下步骤完整继承仓库 solution.md 的控制台流程，并补充每一步的关键含义与注意事项。

第 1 步：进入 EC2 服务的负载均衡器页面

1. 登录 AWS 管理控制台，进入EC2服务；
2. 在左侧菜单Load balancing分组下点击Load balancers；
3. 点击Create load balancer（创建负载均衡器）。

第 2 步：选择 Network Load Balancer 类型

在负载均衡器类型选择页中，选择Network Load Balancer。此时页面会呈现四类可选类型（CLB/ALB/NLB/GWLB），注意不要误选 Application Load Balancer——两者配置界面与适用场景不同。

第 3 步：填写基本配置

• Load balancer name：为 NLB 命名，命名应能体现用途（例如devops-exercises-nlb）；
• Scheme：默认为 internet-facing（面向公网），如需纯内网可改为 internal；
• Listeners：确认监听器为TCP : 80（对应练习"Listener 应使用 TCP 协议、端口 80"的目标）；
• Availability Zones：勾选你希望 NLB 工作的可用区（对应原 Solution 第 6 步"Choose AZs where you want the LB to operate"）。建议至少选择两个 AZ，并尽量与目标 EC2 实例所在 AZ 重合——NLB 会为每个启用的 AZ 分配一个弹性 IP/静态 IP。

第 4 步：配置安全组

为 NLB 选择一个安全组（原 Solution 第 7 步）。这里需要特别注意：

• NLB 的安全组与实例安全组是两套规则；
• 如果未为 NLB 单独创建安全组，则实际生效的仍是挂载在 EC2 实例上的安全组——这是后续"NLB 不工作"的最常见根源之一（详见"常见故障排查"一节）。

第 5 步：在 Listeners and routing 中创建目标组

在Listeners and routing区域，点击Create target group，选择Instances作为目标类型，然后依次完成：

1. Target group name：为目标组命名（如devops-exercises-tg）；
2. Protocol & Port：协议设为TCP、端口设为80——这与健康检查与业务转发均使用 80 端口保持一致；
3. Healthy threshold：3——连续 3 次健康检查成功，实例才被标记为"健康"；
4. Unhealthy threshold：3——连续 3 次健康检查失败，实例才被标记为"不健康"；
5. Interval：10 seconds——每 10 秒对每个目标执行一次健康检查；
6. 点击Next，在目标实例列表中勾选你已有的两台 EC2 实例；
7. 点击Create target group完成目标组创建。

第 6 步：关联目标组并完成创建

1. 返回负载均衡器创建页，刷新（Refresh）目标组列表，选择刚刚创建的目标组；
2. 点击Create load balancer提交；
3. 等待 NLB 状态变为active（provisioned）。原 Solution 明确要求"wait for it to be provisioned"——NLB 从创建到可提供服务通常需要数分钟，期间状态为 provisioning。

至此，练习目标全部达成：一台使用 TCP/80 监听器的 NLB，连接着一个健康检查参数为 3/3/10 的目标组，组内注册了两台 EC2 实例。

健康检查参数详解：3 / 3 / 10 的含义与影响

健康检查（health check）是 ELB 判断后端实例是否可用的核心机制。根据 README 问答：ELB 使用健康检查确认 EC2 实例是否正常工作；当健康检查失败时，ELB 便不再向该实例转发流量。健康检查针对"端口 + 路径/协议"进行，例如 README 举的例子是端口 2017、端点/health。

本练习设置的三项参数语义如下：

从仓库问答中可以印证健康检查的价值场景：在 Scenarios 问答 中，当"负载均衡器后 5 台 Web 服务器中偶尔有实例崩溃"时，推荐的解法正是使用负载均衡器的健康检查，确保实例就绪后才向其转发流量。这说明 3/3/10 这类参数组合服务于一个目标：在"故障发现速度"与"误判容忍度"之间取得平衡。

验证负载均衡是否生效

创建完成后，可以通过以下方式验证 NLB 工作正常：

1. 在Target groups页面查看目标组内两台实例的健康状态，应全部为healthy；
2. 通过 NLB 的 DNS 名称（以及每个启用 AZ 的静态 IP）访问应用：curl http://<NLB-DNS-NAME>；
3. 在实例上观察访问日志或负载（例如多次请求观察两台实例是否轮流收到流量），确认流量被分发到两台实例；
4. 若实例上的应用响应内容不同（如显示各自 hostname），可以直观看到请求在实例间的轮转——这与 ALB 练习 中"verify load balancer is working (= you get reply from both instances at different times)"的验证思路一致。

需要说明的是，NLB 默认关闭跨可用区负载均衡（README 明确此点），因此当两台实例分布在不同 AZ 时，流量先按 AZ 分配、再在 AZ 内部实例间分发；若希望流量在所有实例间均匀分配，需要手动启用 cross-zone load balancing（注意 NLB 跨 AZ 数据会收取相应费用）。

常见故障排查：NLB 创建了却不工作怎么办

仓库在 Troubleshooting 问答 中专门收录了与本练习强相关的故障场景：

"You've created a network load balancer but it doesn't work (you can't reach your app on your EC2 instance). What might be a possible reason?"

官方解法直指两个高频根因：

1. 缺少安全组或安全组配置错误：若你未为 NLB 创建专属安全组，则实际生效的是 EC2 实例上挂载的安全组。此时控制台中会看到 NLB 下的实例处于unhealthy 状态；
2. 实例安全组未放行 NLB 要转发的流量：需要到实例所在安全组中，放行 NLB 对应的转发流量（本练习即TCP 80端口入站）。

排查路径总结：

• 看目标组健康状态 → 若unhealthy，优先检查实例安全组是否放行了 80 端口；
• 对照 Security Groups 练习 亲手验证：移除 HTTP 入站规则后实例变为不可达，加回规则后恢复——这正是理解"NLP 转发依赖实例安全组放行"的最佳实验；
• 若实例本身应用未启动（如 httpd 未运行），健康检查同样会失败，可结合 launch_ec2_web_instance 练习 的用户数据（user data）脚本确保应用随实例自启动。

延伸：从控制台走向 IaC 与更高阶实践

仓库 AWS 章节导读 明确建议：官方提供的解法基于 AWS 控制台，但推荐使用 IaC 技术（如 Terraform、Pulumi）完成练习。仓库中已给出可参照的 IaC 示例：

• new_vpc 练习 附带 Terraform main.tf 与 Pulumimain.py；
• subnets 练习 附带 Terraform main.tf 与 Pulumimain.py；
• S3 new_bucket 练习 同样提供 Terraform 与 Pulumi 双版本。

（从仓库结构可以推断）NLB 的 Terraform 声明思路与这些示例同构：用aws_lb（类型为 network）+aws_lb_target_group（health_check 中配置 healthy_threshold、unhealthy_threshold、interval）+aws_lb_listener（TCP:80）三个资源组合即可复现本练习的全部配置。掌握控制台流程后，将其翻译为 IaC 声明，是练习本系列的最佳进阶路径。

更高阶的关联练习还包括：

• Auto Scaling Groups Basics：让目标组背后的实例数量随负载自动伸缩；
• Health Checks（Route 53）：理解健康检查在 DNS 层面的另一种形态；
• ALB Multiple Target Groups：七层负载均衡下多目标组的路由实践。

小结

本练习用"两台 EC2 实例 + 一台 NLB"的最小组合，完整覆盖了 AWS 四层负载均衡的核心链路：监听器（TCP:80）→ 目标组（Instances 类型）→ 健康检查（healthy/unhealthy threshold = 3，interval = 10s）→ 流量转发。配合仓库中 exercise / solution 原文与 ELB 问答章节 的知识点，你可以继续追问"为什么 NLB 延迟更低""为什么 NLB 不支持粘性会话""跨可用区负载均衡何时开启"等面试高频问题，把一次实操练习沉淀为完整的 NLB 知识体系。

• 文档
• 教程
• DevOps
• 运维