我在这方面过得很艰难。我们希望将旧版应用程序迁移到微服务应用程序（Spring-boot，Java 8）。
根据架构师，我们不需要Service Disvovery，并且API Gateway足以完成Service Discovery和Routing。
请注意，当前，部署是在内部服务器上进行的，我们将拥有固定数量的节点，F5 /负载均衡器将能够将请求路由到API网关，然后再路由到微服务。
我们能在没有服务发现的情况下使用Spring Cloud API Gateway生存吗？
答案 0 :(得分：1)
一个简短的答案是的，您可以使用Spring Cloud API Gateway生存下来，而无需进行服务发现。
但这实际上取决于应用程序的大小和要处理的流量。
您可以开始迁移到微服务而无需发现服务。 对于内部服务到服务的通信，只需使用真实的硬编码IP地址和端口即可。
关于 API网关进行服务发现。我可能是错的，但是您将无法通过Api Gateway进行通信，因为它也不了解目标位置（服务位置也必须进行硬编码）。
一旦开始感觉需要扩展，就不会避免使用服务注册表工具。如果您开始考虑选哪个，我建议您使用HashiCorp Consul。
无论如何，最有可能您最终将不得不向基础结构注入服务发现机制。如果新架构对您有利，并且有计划进一步扩展它，则可以从一开始就做，或者稍后再进行处理。
如果您有迁移到云的计划，则可以预先考虑为基础架构配置 Kubernetes 。它为您提供了开箱即用的服务发现机制。
答案 1 :(得分：1)
Kubernetes是一个不错的平台，如果您愿意的话。
它可以处理从服务发现到部署的各个部分。
您只需要制作一个可用于云的docker映像（最好）并将其部署到kubernetes，Kubernetes将根据您的配置将内部端点映射到该端点，并且您的服务将被注册到该端点（如果我谈论的是spring-cloud和eureka服务器）。
答案 2 :(得分：0)
如果没有服务注册支持的 DiscoveryClient，那么您可以配置 spring.cloud.discovery.client.simple.instances.userservice[0].uri=http://s11:8080
您可以在 kubernetes 集群上托管此用户服务。有关更多详细信息，请参阅此文档 https://cloud.spring.io/spring-cloud-commons/2.2.x/reference/html/
在服务之间进行通信一样明智，假设用户服务想要通过功能区轻松配置密码服务进行通信
passwordservice.ribbon.listOfServers:${PASSWORDSERIVCE}:http://localhost:8081
我认为这种结构没有任何问题。