使用eureka进行kubernetes服务发现的缺点

Question

我正在将一组使用Docker进行集装箱化的服务部署到AWS中。无论选择哪种部署解决方案（如原始EC2/ECS/Elastic Beanstalk/Fargate），我们都将面临“服务发现”的问题。

仅举几个我考虑过的服务发现选项：

• AWS Route 53服务注册表

我正在使用Spring Cloud开发JavaSpring Boot应用程序，目标部署环境是AWS。

考虑到我的堆栈是基于Spring的，Spring cloud eureka在本地开发时对我来说是有意义的。它很容易设置单个节点，可以很好地与堆栈和选择的生态系统集成，并且只需要很少的设置。

在本地，我们使用docker compose（而不是swarm）部署服务—部署的容器之一是单节点Eureka服务发现服务器。

然而，当我们脱离当地发展，进入分期或正式生产环境时，我们正在考虑像库伯内特斯这样的选择。

要求我们将代码专门耦合到AWS服务。这本身并不是一个问题，我们在堆栈的其他部分（SNS/SQS）上有很大的联系。

这使得在本地运行堆栈稍微困难一些，因为它依赖于路由53，我想我们可以为本地开发打开一个托管区域。

AWS本机，无管理服务注册表或额外的“移动部件”。

缺点是，这需要我们部署和管理高可用性服务注册中心集群，并且需要更多的资源。另一个需要管理的“移动部件”。

优点是它很适合我们的堆栈（spring生态系统、spring boot、html" target="_blank">spring cloud、feign和zuul都能很好地使用它）。也可以在本地运行。

我假设我们需要配置网络和注册表区域，以确保客户端发布他们的主机地址，而不是docker容器内部IP地址。例如，如果服务A在主机A上，并希望与主机B上的服务B交谈，服务B需要通告其EC2地址，而不是某个内部docker IP。

如果我们使用库伯内特斯进行编排，使用像Spring Cloud Eureka这样的东西比这里描述的内置服务发现选项有什么缺点https://kubernetes.io/docs/concepts/services-networking/service/#discovering-services

鉴于Kube提供了这一点，那么使用使用库贝部署的eureka来执行发现似乎是次优的。我认为库贝可以做一些优化来影响可用性和稳定性，使用eureka可能是不可能的。例如，库贝在部署新服务时会知道——eureka将不得不依赖心跳/健康检查，这取决于如何配置（例如频率）这可能会导致陈旧的记录，而我认为库贝可能不会因为计划的服务关闭/重启而受到影响。我想它仍然适用于计划外的故障，如主机故障或网络分区。

有人对此有什么建议吗？人们是否使用Kubernetes之类的服务，但使用其他机制进行服务发现，而不是使用kube提供的机制。是否有充分的理由这样做或那样做？

我们可以替换eureka，但依赖Kube执行发现将意味着我们需要在本地运行Kube来部署，而目前我们有一个简单的小型docker compose文件。另外，我还要看看确保ribbon、zuul和Faign能够很好地处理这个问题有多容易。

目前，我们已使用eureka客户端配置ribbon，以便服务a可以像“服务B”一样将服务器连接到服务B，并让ribbon通过eureka客户端解析健康主机。我想我们可以将ribbon配置为不使用eureka，并使用外部Kube服务名称，该名称将在运行时由Kube DNS解析。。。

提前感谢任何贡献或建议。我知道这可能会引起主要以意见为中心的回应。但我希望有人能就何时一种解决方案可能比另一种解决方案更可取提供客观的指导。

Answer 1

服务发现是Kubernetes提供的现成服务。因此，在您的平台中拥有另一个外部服务将是另一个需要维护、部署的应用程序，并且可能会出现故障。所以我会坚持Kubernetes提供的服务发现。