微服务：没有使用 Spring API 网关的服务发现答案

【问题标题】：Microservices : Without Service Discovery With Spring API Gateway微服务：没有使用 Spring API 网关的服务发现
【发布时间】：2019-12-29 04:13:25
【问题描述】：

我在这个问题上遇到了非常艰难的时期。我们希望将旧版应用程序迁移到微服务应用程序（Spring-boot，Java 8）。

根据 Architect，我们不需要服务发现，API 网关足以进行服务发现和路由。

请注意，目前，部署是本地服务器，我们将拥有固定数量的节点，F5/负载均衡器将能够将请求路由到 API 网关，然后再路由到微服务。

我们可以在 Spring Cloud API Gateway 和没有服务发现的情况下生存吗？

【问题讨论】：

好吧，你没有提到任何需要服务发现来解决的问题，所以你的架构师可能是对的。为什么你认为你可能需要它？但是，一个好的架构将确保您可以改变主意而不会产生严重后果，因此该决定不应该很重要。在软件架构方面，做出正确的决定不如让决定变得不重要。
@MattTimmermans ，我们希望在微服务之间进行内部通信。因此，如果我们没有服务发现，我们将不得不通过 API 网关调用，这非常耗时。

【解决方案1】：

Kubernetes 是一个很好的平台，如果您可以选择的话。

它可以处理从服务发现到部署的各个部分。

您只需要制作一个云就绪 docker 映像（最好）并将其部署到 kubernetes，Kubernetes 将根据您的配置将一个内部端点映射到此，并且您的服务将在其中注册（如果我谈到spring-cloud 和 eureka 服务器）。

【讨论】：

到目前为止，我们正在进行单体应用扼杀。刚开始使用非常基本的项目，目前还没有 Kubernetes 的计划。但我们肯定会寻找那个选项。如果您发现问题相关，请点赞！

【解决方案2】：

一个简短的回答是的，你可以使用 Spring Cloud API Gateway 并且没有服务发现。

但这真的取决于您的应用程序的大小和流量量它将处理。

您可以开始迁移到微服务无需服务发现。对于内部服务到服务的通信，只需使用真正的硬编码 IP 地址和端口。

关于API Gateway 做服务发现。我可能是错的，但是您将无法通过 Api Gateway 进行通信，因为它也不知道目标的位置（服务位置也必须是硬编码的）。

一旦您开始觉得需要向外扩展，您就不会回避使用服务注册工具。如果您开始考虑选择哪一个，我建议您使用HashiCorp Consul。

无论如何，您很可能最终不得不将服务发现机制注入您的基础架构。如果新架构对您有益，您可以从一开始就做，也可以在以后处理它，并且会有进一步扩展它的计划。

如果您有迁移到云端的计划，那么您可以提前为您的基础架构考虑 Kubernetes。它为您提供开箱即用的服务发现机制。

【讨论】：

@Stephan Tsybulki 感谢您提供详细的答案，以避免对我们需要开始考虑 Consul 的 URL 进行编码。如果您认为该问题相关，您能否投票赞成...

【解决方案3】：

如果没有 Service-Registry-backed 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

我认为这种结构没有任何问题。

【讨论】：