目前，我正在尝试弄清楚如何配置 ECS 服务之间的通信。我计划进行以下设置：
- 后端服务
- 前台服务
- 一个应用程序负载均衡器
我心里有以下选择：
- 为 ALB 配置 2 个目标组，并根据路径转发请求。例如，
alb.amazonaws.com/backend/将请求转发到 ，backend-target-group后者将请求提供给后端 ECS 任务。 - 在每个 ECS 任务中运行一个脚本，该脚本将使用 AWS cli 和服务发现检索正在运行的任务的 IP 地址。不确定这是否会起作用，而且测试起来相对困难。
这些方法似乎都不是正确的做法。由于财务限制，我不想为每项服务使用单独的 ALB。我考虑的是 ECS 服务的某种内部 DNS 名称。我检查了以下链接，但不知道如何将其应用于我的情况。
- https://docs.aws.amazon.com/cloud-map/latest/dg/what-is-cloud-map.html
- https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-discovery.html
- https://aws.amazon.com/blogs/aws/amazon-ecs-service-discovery/
- https://aws.amazon.com/blogs/compute/task-networking-in-aws-fargate/
相关问题： AWS ECS 容器通信
因此，理想情况下，我希望实现的是：为后端服务设置一个内部 DNS 名称，并将请求从前端服务发送到后端。
答案1
您几乎已经涵盖了正确的选项。
ECS 服务发现将是我的首选 - 所有容器将自动在服务发现域中注册，并可通过这种方式访问。简单、透明、便宜。
内部应用程序负载均衡器针对不同目标群体使用不同的路径将是我的第二选择。您不想在一个 ALB 上混合面向外部和内部的流量，但拥有两个（内部和外部）是一种非常有效的架构。可能值得每月多花 20 美元左右购买一个 ALB。
AWS App Mesh- 我个人没有用过这个，但看起来它很可能满足你的需要。标题说适用于所有服务的应用程序级网络
API 网关也是一个选项。你的后端可能需要进行一些细微的更改才能与之配合，但没有什么大不了的。
希望有帮助:)