通过 AWS Cloud Map 实现服务发现 - 微服务间的动态名称解析
通过 DNS 和 API 两种方式动态发现微服务端点。介绍与 ECS、EKS 集成实现服务自动注册和注销的方法。
Cloud Map 概述
Cloud Map 是一项为应用程序资源提供服务发现的服务。在微服务架构中，当服务 A 调用服务 B 时，无需硬编码服务 B 的端点，而是通过查询 Cloud Map 进行动态解析。它提供 DNS 和 API 两种发现方式，并与 ECS 和 EKS 集成实现服务的自动注册和注销。
DNS 与 API 发现
DNS 命名空间将服务注册为 DNS 记录，通过 service-b.my-namespace.local 这样的 DNS 名称进行解析。现有应用程序可以通过 DNS 查询发现服务，无需修改代码。HTTP 命名空间通过 DiscoverInstances API 获取服务实例，并可按自定义属性（version=v2、environment=prod）进行过滤。ECS 服务发现在任务启动时自动向 Cloud Map 注册实例，在任务停止时自动注销。通过 Route 53 健康检查检测异常实例并将其从发现结果中排除。
与 ECS 和 EKS 的集成
在 ECS 服务中启用 Cloud Map 后，服务实例会随着任务的启动和停止自动注册和注销。基于 DNS 的发现会在 Route 53 中创建 SRV 或 A 记录，客户端通过 DNS 名称解析服务。基于 API 的发现通过 DiscoverInstances API 获取已通过健康检查的实例列表，在客户端实现负载均衡。在 EKS 中，可以使用 AWS Cloud Map MCS Controller 将 Kubernetes Service 自动同步到 Cloud Map。健康检查可选择 Route 53 健康检查或自定义健康检查（应用程序调用 UpdateInstanceCustomHealthStatus API 的方式）。 如果想全面学习服务发现的配置模式，请参考技术书籍（Amazon）。
Cloud Map 的定价与运维
Cloud Map 的定价由资源注册数和 API 调用数决定。DNS 查询适用 Route 53 的标准费率，DiscoverInstances API 每 100 万次请求收费 1 美元。在实例注册和注销频繁发生的自动扩展环境中，API 调用数会增加，因此需要在客户端实现缓存以控制成本。在命名空间设计中，建议按环境（dev/staging/prod）分离命名空间，服务名称在各环境间保持统一，以消除应用程序代码的环境依赖。通过 CloudWatch 指标监控 DiscoverInstances 的调用次数和延迟，检测异常增长。
总结
引入 Cloud Map 最便捷的入口是与 ECS 服务发现的集成。只需在 ECS 服务中启用 Cloud Map，即可自动化与任务启动和停止联动的服务注册。如果现有应用程序通过 DNS 进行名称解析，选择 DNS 命名空间；如果需要按自定义属性过滤，选择 HTTP 命名空间。在命名空间设计中，建议按环境（dev/staging/prod）分离，服务名称在各环境间保持统一。