据我所知@LoadBalanced,Rest模板应基于使用Ribbon的客户端负载平衡,并检查Eureka服务器是否将服务名称解析为主机/端口.
有什么用@RibbonClient？是否支持没有Eureka的原生Ribbon Client LB,并在配置时支持Eureka Discover DiscoveryEnabledNIWSServerList？
我正在将使用Docker容器化的一组服务部署到AWS中。无论选择哪种部署解决方案（例如原始EC2 / ECS / Elastic Beanstalk / Fargate），我们都将面临“服务发现”的问题。
仅列举我考虑过的一些服务发现选项：
我正在使用Spring Cloud开发Java Spring Boot应用程序，目标部署环境是AWS。
鉴于我的堆栈是基于Spring的，因此在本地开发时，春季云eureka对我来说很有意义。设置单个节点很容易，可以与所选的堆栈和生态系统很好地集成，并且只需要很少的设置。
在本地，我们使用docker compose（而不是swarm）来部署服务-部署的容器之一是单节点Eureka服务发现服务器。
但是，当我们在本地开发之外进入阶段或生产环境时，我们会考虑使用Kubernetes之类的选项。
要求我们将代码专门耦合到AWS服务。本身就不成问题，无论如何，我们在协议栈的其他部分（SNS / SQS）上都束手无策。
由于它依赖于Route 53，这使得在本地运行堆栈稍微困难一些，我想我们可以为本地开发开放某个托管区域。
AWS本机，无管理服务注册表或其他“活动部件”。
缺点是需要我们部署和管理高可用性服务注册表集群，并且需要更多资源。另一个“运动部分”要管理。
优点是它非常适合我们的堆栈（spring生态系统，spring boot，spring cloud，feign和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可以进行一些优化，以影响使用尤里卡（eureka）可能实现的可用性和稳定性。例如，kube会知道何时部署新服务-尤里卡将不得不依靠心跳/健康检查，并取决于配置方式（例如频率），这可能会导致过时的记录，而我认为kube对于计划中的服务关闭可能不会因此受到影响/重新启动。我猜想它仍然可以解决计划外的故障，例如主机故障或网络分区。
是否有人对此有任何建议？人们使用Kubernetes之类的服务，但使用其他机制进行服务发现，而不是kube提供的那些机制。是否有充分的理由做一个或另一个？
我们可以替换eureka，但是依靠Kube执行发现将意味着我们需要在本地运行kube进行部署，而当前我们只有一个简单的小型docker-compose文件。另外，我将不得不考虑确保丝带，zuul和假装与之完美搭配的难易程度。
当前，我们为功能区配置了eureka客户端，以便服务A可以像“ service-b”一样为服务B提供服务器，并通过eureka客户端使功能区解析健康的主机。我猜我们可以将功能区配置为不使用eureka并使用外部Kube服务名称，该名称将在运行时由Kube DNS解析...
在此先感谢您的任何贡献或建议。我知道这可能会引起人们对意见的关注。但是，我希望有人可以就何时提供一种解决方案优于另一种解决方案提供客观的指导。