devops-exercises 实战：AWS Application Load Balancer 多目标组与 /test 路径路由-平芜编程栈

文档
教程
DevOps
运维

【免费下载链接】devops-exercises

Linux, Jenkins, AWS, SRE, Prometheus, Docker, Python, Ansible, Git, Kubernetes, Terraform, OpenStack, SQL, NoSQL, Azure, GCP, DNS, Elastic, Network, Virtualization. DevOps Interview Questions

项目地址：https://gitcode.com/GitHub_Trending/de/devops-exercises

点击查看免费下载

本指南基于 devops-exercises 仓库中的 ALB 多目标组练习，完整讲解如何在 AWS 上创建一台 Application Load Balancer（ALB），将流量按路径规则分发给两个不同的目标组（Target Group），并配置健康检查阈值。读完本文，你将掌握 ALB 监听器规则（Listener Rules）的编辑方法、目标组与健康检查参数的配置要点，以及如何在浏览器中验证基于/test路径的路由是否生效。

一、练习背景：先看这个练习要解决什么问题

在 alb_multiple_target_groups/exercise.md 中，仓库给出了一个非常贴近真实微服务拆分的场景：同一台负载均衡器需要同时服务两种不同类型的后端。

需求（Requirements）

两台 EC2 实例，运行一个简单 Web 应用，页面显示字符串Hey, it's a me, <HOSTNAME>!（<HOSTNAME>为实例自身主机名，用来区分流量被路由到了哪台实例）；
一台 EC2 实例，运行一个简单 Web 应用，在/test端点下显示字符串Hey, it's only a test...。

目标（Objectives）

为前两台实例创建一个应用负载均衡器，属性要求：
- healthy threshold（健康阈值）：3
- unhealthy threshold（不健康阈值）：3
- interval（健康检查间隔）：10 秒
为第三台实例再创建一个目标组：
- 流量应基于/test路径转发到该目标组。

也就是说，最终效果是：访问 ALB 的 DNS 地址根路径/时，流量被分发给前两台实例（轮询，刷新页面可看到不同 HOSTNAME）；访问ALB_DNS/test时，流量被转发给第三台实例，页面显示Hey, it's only a test...。

这个练习与仓库中的基础版 Application Load Balancer 练习（仅一台 ALB + 一个目标组、验证轮询）构成递进关系：多目标组练习的核心增量是监听器规则（Listener Rule）——同一个监听器上存在默认规则与路径条件规则，ALB 据此将不同路径的请求分发到不同目标组。

二、前置概念：ALB、目标组、监听器与健康检查

在动手之前，先用仓库 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）、Gateway Load Balancer（GWLB，面向第 3 层 IP 协议操作）。本题使用 ALB，因为它需要做HTTP 路径级路由。
目标组（Target Group）：ALB 转发流量的后端集合。仓库 README 明确列出 ALB 的可行目标组类型包括：EC2 实例、ECS 任务（EC2 tasks / ECS instances）、Lambda 函数、私有 IP 地址。本题选择Instances类型，直接绑定 EC2 实例。
监听器（Listener）：负载均衡器上绑定端口与协议、接收客户端请求的入口。创建 ALB 时会同时创建默认监听器（通常是 HTTP 80）。
健康检查（Health Check）：README 中解释为 ELB 用来检查 EC2 实例是否正常工作的机制；健康检查是在一个端口加一个路由上执行的（例如端口2017+ 端点/health）。若健康检查失败，ELB 就不会把流量转发到该实例。这正是题目中healthy threshold / unhealthy threshold / interval三个参数存在的意义：
- healthy threshold = 3：连续 3 次健康检查成功，实例才被标记为健康；
- unhealthy threshold = 3：连续 3 次健康检查失败，实例被标记为不健康并从路由中摘除；
- interval = 10：每 10 秒执行一次健康检查。

仓库问答区还有一个与本题强相关的判断题："ALB 只能路由到单个目标组"——答案是False，ALB 可以路由到多个目标组；并且ALB 支持基于查询字符串（query string）和/或请求头（headers）的路由，路径（path）路由自然也在其列。这些能力正是本练习"一个 ALB 服务两组后端"的理论基础。

三、目标拆解：一张"路由表"看透整个架构

动手配置前，先把最终要实现的转发关系画成一张路由表：

访问路径	转发目标组	目标组内实例	预期返回内容
`/`（默认规则）	目标组 A	实例 1、实例 2	`Hey, it's a me, <HOSTNAME>!`（轮询，HOSTNAME 交替变化）
`/test`（路径规则）	目标组 B	实例 3	`Hey, it's only a test...`

两个目标组的健康检查参数完全一致（threshold 3 / threshold 3 / interval 10s），区别仅在于成员实例不同、且分别被默认规则与路径规则引用。仓库 solution.md 给出的控制台操作顺序，本质上是"先建目标组 → 建 ALB 引用目标组 A → 再建目标组 B → 最后编辑监听器规则补上 /test 转发"。

四、控制台实操：从零创建 ALB 多目标组

以下步骤完整继承仓库 solution.md 的控制台操作，并补充每一步的配置意图说明。

第 1～7 步：进入 EC2 服务并创建 ALB 骨架

进入 EC2 服务（EC2 service）。
点击左侧菜单 "Load balancing" 下的Load balancers。
点击Create load balancer。
选择Application Load Balancer（对应本练习的 HTTP 路径路由需求）。
为负载均衡器输入一个名称。
选择 ALB 要运行的可用区（AZ）。
选择一个安全组（Security Group）。注意：安全组需放行 80 端口入站流量，否则后续浏览器无法访问 ALB；这是仓库 security_groups 练习中反复强调的要点。

第 8～10 步：在"监听器和路由"中创建第一个目标组并完成 ALB 创建

在Listeners and routing区域点击Create target group，目标类型选择Instances：
- 为目标组命名（目标组 A）；
- healthy threshold 设为 3；
- unhealthy threshold 设为 3；
- interval 设为 10 秒；
- 点击Next，从三台已创建实例中勾选前两台；
- 点击Create target group。
返回创建负载均衡器的页面，刷新目标组列表，选中刚创建的目标组 A，作为默认转发的目标。
点击Create load balancer，等待 ALB 完成 provisioning（状态变为 active，一般需要几分钟）。

第 11～13 步：为第三台实例创建第二个目标组

在左侧菜单 "Load Balancing" 下点击Target Groups。
点击Create target group，为第二个目标组（目标组 B）设置与目标组 A完全相同的健康检查属性（healthy threshold 3 / unhealthy threshold 3 / interval 10 秒）。
在注册实例时，添加第三台（上一目标组未包含的）实例。

注册实例这一步的提示：AWS 控制台在创建目标组后需要单独进入该目标组的Registered targets页签完成实例注册；两处目标组的健康检查参数保持一致，是为了保证两组实例的可用性判定口径一致，避免因阈值不同导致路由体验不一致。

第 14 步：编辑监听器规则，加入 /test 路径转发

回到 ALB，在Listeners下点击当前监听器对应的Edit rules（编辑规则）：
- 添加一条规则（Add rule）：if path is/test，then forward to 目标组 B（转发到第二个目标组）；
- 点击Save保存。

至此路由表完整生效：默认规则仍指向目标组 A（根路径流量），新增的路径规则把/test流量导向目标组 B。

第 15 步：浏览器验证

复制 ALB 的 DNS 地址，粘贴到浏览器：
- 直接访问根地址，应看到Hey, it's a me, <HOSTNAME>!，多次刷新后 HOSTNAME 会在两台实例间交替——这正是基础版 app_load_balancer 练习的验证手法；
- 在地址后追加/test（即ALB_DNS/test），应看到Hey, it's only a test...，且无论刷新多少次都来自第三台实例，因为该路径已被固定路由到目标组 B。

五、原理纵深：仓库源码级佐证与参数解读

5.1 为什么健康检查要"3 次成功/失败 + 10 秒间隔"？

从 README 问答区可确认两点事实：

健康检查在端口 + 路由上执行，本练习的健康检查默认指向注册实例的 80 端口（也可在目标组配置中改为/health等自定义路径）；
健康检查失败后 ELB 会停止向该实例转发流量，直到实例恢复健康。

threshold = 3的作用是去抖动：单次探测失败可能只是瞬时网络抖动，连续 3 次失败才摘除实例，避免误伤；interval = 10决定探测频率，数值越小对实例负载与流量感知越敏感。若后续实例频繁崩溃，仓库 README 场景问答给出的方案正是"用健康检查确保实例在转发前已就绪"。

5.2 为什么 ALB 能同时服务两组后端？

仓库 README 已给出直接证据：

ALB 可以路由到多个目标组（对应判断题 "ALB can route only to a single route group"，答案为 False）；
ALB 除路径外，还支持基于query string 和 headers的路由，同一监听器可叠加多条规则；
ALB 的目标组类型覆盖 EC2 实例、ECS 任务、Lambda 函数、私有 IP，意味着本练习的"实例型目标组"只是其中一种形态——将来把某组后端迁到 Lambda 或 ECS 时，只需新增对应类型的目标组并调整规则转发。

5.3 对比：NLB 与 ALB 的取舍

本练习选择 ALB 而非 NLB 的理由在仓库问答中有明确依据：NLB 面向 TCP/TLS/UDP 四层流量，不具备路径级路由能力；仓库还提到 ALB 延迟约 400ms、NLB 约 100ms——若业务只需四层转发、不关心路径分流，可参考仓库的 Network Load Balancer 练习（NLB 同样使用 healthy threshold 3 / unhealthy threshold 3 / interval 10 秒，监听器用 TCP 80）。一句话总结：需要按路径/主机头/查询串分流就选 ALB，只需要高性能四层转发就选 NLB。

5.4 会话保持（Sticky Sessions）与多目标组的关系

当两组后端中某一组是有状态应用时，可为目标组开启粘性会话（sticky sessions），确保同一用户始终被路由到同一台实例（README 场景问答中的解决方式）。本练习的验证目标是"不同路径到不同组"，默认轮询即可；若生产环境涉及登录态，则需要为目标组开启粘性会话，这是多目标组架构落地时容易遗漏的细节。

六、延伸建议：用 IaC 复现与常见问题排查

6.1 用 Terraform / Pulumi 复现

仓库 AWS README 明确建议：给出的解决方案基于 AWS 控制台，但推荐使用 IaC（如 Terraform、Pulumi）完成练习。可参考仓库中同类的 IaC 实现方式（如 new_vpc 的 terraform/main.tf 与 pulumi/main.py）来组织资源：aws_lb（ALB）→aws_lb_target_group× 2（健康检查参数对应healthy_threshold = 3、unhealthy_threshold = 3、interval = 10）→aws_lb_listener_rule（条件path_pattern = ["/test"]，动作forward到目标组 B）→aws_lb_target_group_attachment（注册三台实例到对应目标组）。

6.2 常见问题排查

浏览器访问根路径 504 / 超时：优先检查 ALB 安全组是否放行 80 端口入站，以及实例安全组是否放行来自 ALB 的流量。
访问/test仍返回主页内容：说明监听器规则未保存生效，回到 "Edit rules" 确认路径条件精确为/test且动作是 forward 到目标组 B；注意路径是区分大小写的。
某个实例始终收不到流量：在目标组的Targets页签查看该实例健康状态；若显示 unhealthy，检查实例上 Web 服务是否监听在健康检查端口/路径上（与 5.1 节呼应）。
刷新根路径 HOSTNAME 不变化：浏览器可能有缓存或长连接，换隐私窗口/curl 重试。

七、小结

本练习用三台 EC2、两个目标组和一条监听器路径规则，完整演示了 ALB 的核心价值——在七层（HTTP）上按路径把流量精确分发给不同的后端集合。你既可以在 exercise.md 中直接挑战原题，也可以在 solution.md 对照控制台步骤，再结合仓库 AWS README 的 ELB 问答区吃透健康检查、监听器与目标组背后的设计意图。掌握"多目标组 + 路径规则"后，将同一套路扩展到基于 host-header、query string 的路由，即可支撑灰度发布、A/B 测试与多版本共存等真实生产场景。

文档
教程
DevOps
运维

【免费下载链接】devops-exercises

Linux, Jenkins, AWS, SRE, Prometheus, Docker, Python, Ansible, Git, Kubernetes, Terraform, OpenStack, SQL, NoSQL, Azure, GCP, DNS, Elastic, Network, Virtualization. DevOps Interview Questions

项目地址：https://gitcode.com/GitHub_Trending/de/devops-exercises

点击查看免费下载