本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
分布式系统组件
在微服务架构中，服务发现是指动态定位和识别分布式系统中各个微服务的网络位置（IP 地址和端口）的过程。
在选择方法时 AWS，请考虑以下因素：
-
代码修改：不修改代码就能获得好处吗？
-
跨VPC或跨账户流量：如果需要，您的系统是否需要高效管理不同 VPCs 或跨账户的通信？ AWS 账户
-
部署策略：您的系统是否使用或计划使用高级部署策略，例如蓝绿色或金丝雀部署？
-
性能注意事项：如果您的架构经常与外部服务通信，会对整体性能产生什么影响？
AWS 提供了几种在微服务架构中实现服务发现的方法：
-
Amazon ECS 服务发现：Amazon ECS 使用其基于 DNS 的方法或通过与集成 AWS Cloud Map （请参阅 ECS 服务发现）来支持服务发现。ECS Service Connect 进一步改进了连接管理，这对于具有多个交互服务的大型应用程序尤其有益。
-
Amazon Route 53：Route 53 与 ECS 和其他 AWS 服务（例如 EKS）集成，以促进服务发现。在 ECS 环境中，Route 53 可以使用 ECS 服务发现功能，该功能利用自动命名 API 自动注册和取消注册服务。
-
AWS Cloud Map：此选项提供基于 API 的动态服务发现，可在您的服务中传播更改。
为了满足更高级的通信需求，Amazon VPC Lattice 是一项应用程序联网服务，可持续连接、监控和保护服务之间的通信，有助于提高工作效率，使您的开发人员可以专注于构建对您的业务至关重要的功能。您可以为网络流量管理、访问和监控定义策略，以简化且一致的方式跨实例、容器和无服务器应用程序连接计算服务。
如果您已经在使用第三方软件（例如 HashiCorp Consul
这些选项之间的选择应符合您的特定需求。对于更简单的要求，基于 DNS 的解决方案（例如 Amazon ECS 或） AWS Cloud Map 可能就足够了。对于更复杂或更大的系统，像 Amazon VPC Lattice 这样的服务网格可能更合适。
总而言之，设计微服务架构 AWS 就是要选择合适的工具来满足您的特定需求。通过牢记所讨论的注意事项，您可以确保做出明智的决策，以优化系统的服务发现和服务间通信。
