我正在部署一组使用Docker容器化到AWS中的服务。无论选择哪种部署解决方案（例如原始EC2 / ECS / Elastic Beanstalk / Fargate），我们都将面临“服务发现”问题。
仅举几个我考虑过的服务发现选项：
我正在使用Spring Cloud开发Java Spring Boot应用程序，目标部署环境是AWS。
鉴于我的堆栈是基于Spring的，Spring cloud eureka在本地开发时对我有意义。设置单个节点很容易，与堆栈和选择的生态系统很好地集成，只需要很少的设置。
在本地，我们使用docker compose（非swarm）来部署服务 - 部署的容器之一是单节点Eureka服务发现服务器。
然而，当我们在本地开发之外进入分期或生产环境时，我们正在考虑像Kubernetes这样的选择。
要求我们将代码专门与AWS服务相结合。这本身并不是问题，我们在堆栈的其他部分（SNS / SQS）上非常紧密。
因为它依赖于Route 53，所以在本地运行堆栈稍微困难一些，我想我们可以打开一个托管区域进行本地开发。
AWS原生，没有管理服务注册表或额外的“移动部件”。
下行是因此需要我们部署和管理高可用性服务注册中心群集并需要更多资源。另一个“活动部分”来管理。
优点是它适合我们的堆栈（春天生态系统，春季启动，春天云，假装和zuul与此良好协作）。也可以在当地琐碎地运行。
我认为我们需要配置网络和注册表区域，以确保客户端发布其主机地址而不是docker容器内部IP地址。例如如果服务A在主机A上并且想要与主机B上的服务B通信，则服务B需要通告其EC2地址而不是一些内部docker IP。
如果我们使用Kubernetes进行编排，那么使用Spring Cloud Eureka之类的东西比使用此处描述的内置服务发现选项https://kubernetes.io/docs/concepts/services-networking/service/#discovering-services
有任何不利之处鉴于Kube提供了这一点，然后使用kube部署的eureka执行发现似乎不是最理想的。我认为kube可以进行一些优化，这些优化会影响使用尤里卡可能无法实现的可用性和稳定性。例如，kube知道在部署新服务时 - 尤里卡将不得不依赖心跳/健康检查，并且取决于配置方式（例如频率），这可能导致陈旧记录，而我认为kube可能不会因计划服务关闭而受此影响/重新启动。我想它仍然适用于计划外故障，例如主机故障或网络分区。
有没有人对此有任何建议，人们是否使用像Kubernetes这样的服务，但使用其他机制进行服务发现而不是kube提供的服务。是否有充分的理由去做其中一个？
我们可以取代eureka，但是依靠Kube来执行发现将意味着我们需要在本地运行kube来部署，而目前我们有一个简单的小型docker-compose文件。此外，我将不得不考虑确保功能，zuul和feign与此完美配合是多么容易。
目前，我们使用eureka客户端配置了功能区，以便服务A可以服务器B为服务B提供服务，例如“service-b”，并通过eureka客户端使用功能区解析健康主机。我想我们可以将功能区配置为不使用eureka并使用外部Kube服务名称，该名称将在运行时由Kube DNS解析...
提前感谢您的任何贡献或建议。我知道这可能引发一个主要以意见为中心的反应。但我希望有人可以提供关于何时一种解决方案可能优于另一种解决方案的客观指导。
答案 0 :(得分：2)
服务发现是您与Kubernetes开箱即用的东西。因此，在您的平台中安装另一个外部服务将是另一个维护，部署并可能成为故障点的应用程序。所以我会坚持使用Kubernetes提供的服务发现。