使用eureka 与kubernetes 进行服务发现的缺点
Disadvantages of using eureka for Service Discovery with kubernetes
上下文
我正在将一组使用 Docker 容器化的服务部署到 AWS 中。无论选择哪种部署方案（例如raw EC2/ECS/Elastic Beanstalk/Fargate）我们都会面临"service discovery".
的问题
仅举几个我考虑过的服务发现选项：
- AWS Route 53 服务注册表
- Kubernetes
- Hashicorp 领事
- Spring 云 Netflix 尤里卡
我的堆栈的细节
我正在开发 Java Spring 使用 Spring 云启动应用程序，目标部署环境是 AWS。
鉴于我的堆栈是基于 Spring 的，spring cloud eureka 在本地开发时对我来说很有意义。设置单个节点很容易，可以很好地与所选的堆栈和生态系统集成，并且只需要很少的设置。
在本地，我们使用 docker compose（不是 swarm）来部署服务 - 部署的容器之一是单节点 Eureka 服务发现服务器。
但是，当我们在本地开发之外进入暂存或生产环境时，我们正在考虑 Kubernetes 等选项。
我自己对 Pros/Cons
的评价
AWS Route 53 服务注册表
需要我们专门将代码耦合到 AWS 服务。本身不是问题，无论如何我们在堆栈的其他部分都被束缚了 (SNS/SQS)。
运行由于它依赖于 Route 53，所以在本地设置堆栈稍微困难一些，我想我们可以为本地开发打开一个特定的托管区域。
AWS 原生，无需管理服务注册表或额外的 "moving parts"。
Spring云尤里卡
缺点是需要我们部署和管理一个高可用的服务注册中心集群，需要更多的资源。另一个 "moving part" 需要管理。
优点是它很适合我们的堆栈（spring 生态系统，spring 引导，spring 云，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 会知道何时部署新服务——eureka 将不得不依赖 heartbeats/health 检查，并且取决于配置方式（例如频率），这可能会导致记录过时，而我认为 kube 可能不会在计划中受到影响服务 shutdown/restarts。我想它仍然适用于意外故障，例如主机故障或网络分区。
有没有人对此有任何建议，人们是否使用像 Kubernetes 这样的服务，但使用其他机制而不是 kube 提供的服务发现机制。有充分的理由做其中之一吗？
我预期的可能挑战
我们可以替换 eureka，但是依靠 Kube 执行发现意味着我们需要 运行 kube 在本地进行部署，而目前我们有一个简单的小型 docker-compose 文件。此外，我将不得不看看确保 ribbon、zuul 和 feign 与此完美配合的难易程度。
目前我们已经为 ribbon 配置了一个 eureka 客户端，这样服务 A 就可以服务器到服务 B，就像 "service-b" 例如，并且让 ribbon 通过 eureka 客户端解析一个健康的主机。我想我们可以将功能区配置为不使用 eureka 并使用外部 Kube 服务名称，该名称将在 运行 时间由 Kube DNS 解析...
最后的笔记
在此先感谢您的贡献或建议。我知道这可能会引起主要以意见为中心的回应。但我希望有人可以提供 objective 指导，说明何时一种解决方案可能优于另一种解决方案。
服务发现是您使用 Kubernetes 开箱即用的东西。因此，在您的平台中拥有另一个外部服务将是另一个需要维护、部署的应用程序，并且可能成为故障点。所以我会坚持使用 Kubernetes 提供的服务发现。
上下文
我正在将一组使用 Docker 容器化的服务部署到 AWS 中。无论选择哪种部署方案（例如raw EC2/ECS/Elastic Beanstalk/Fargate）我们都会面临"service discovery".
的问题仅举几个我考虑过的服务发现选项：
- AWS Route 53 服务注册表
- Kubernetes
- Hashicorp 领事
- Spring 云 Netflix 尤里卡
我的堆栈的细节
我正在开发 Java Spring 使用 Spring 云启动应用程序，目标部署环境是 AWS。
鉴于我的堆栈是基于 Spring 的，spring cloud eureka 在本地开发时对我来说很有意义。设置单个节点很容易，可以很好地与所选的堆栈和生态系统集成，并且只需要很少的设置。
在本地，我们使用 docker compose（不是 swarm）来部署服务 - 部署的容器之一是单节点 Eureka 服务发现服务器。
但是，当我们在本地开发之外进入暂存或生产环境时，我们正在考虑 Kubernetes 等选项。
我自己对 Pros/Cons
的评价AWS Route 53 服务注册表
需要我们专门将代码耦合到 AWS 服务。本身不是问题，无论如何我们在堆栈的其他部分都被束缚了 (SNS/SQS)。
运行由于它依赖于 Route 53，所以在本地设置堆栈稍微困难一些，我想我们可以为本地开发打开一个特定的托管区域。
AWS 原生，无需管理服务注册表或额外的 "moving parts"。
Spring云尤里卡
缺点是需要我们部署和管理一个高可用的服务注册中心集群，需要更多的资源。另一个 "moving part" 需要管理。
优点是它很适合我们的堆栈（spring 生态系统，spring 引导，spring 云，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 会知道何时部署新服务——eureka 将不得不依赖 heartbeats/health 检查，并且取决于配置方式（例如频率），这可能会导致记录过时，而我认为 kube 可能不会在计划中受到影响服务 shutdown/restarts。我想它仍然适用于意外故障，例如主机故障或网络分区。
有没有人对此有任何建议，人们是否使用像 Kubernetes 这样的服务，但使用其他机制而不是 kube 提供的服务发现机制。有充分的理由做其中之一吗？
我预期的可能挑战
我们可以替换 eureka，但是依靠 Kube 执行发现意味着我们需要 运行 kube 在本地进行部署，而目前我们有一个简单的小型 docker-compose 文件。此外，我将不得不看看确保 ribbon、zuul 和 feign 与此完美配合的难易程度。
目前我们已经为 ribbon 配置了一个 eureka 客户端，这样服务 A 就可以服务器到服务 B，就像 "service-b" 例如，并且让 ribbon 通过 eureka 客户端解析一个健康的主机。我想我们可以将功能区配置为不使用 eureka 并使用外部 Kube 服务名称，该名称将在 运行 时间由 Kube DNS 解析...
最后的笔记
在此先感谢您的贡献或建议。我知道这可能会引起主要以意见为中心的回应。但我希望有人可以提供 objective 指导，说明何时一种解决方案可能优于另一种解决方案。
服务发现是您使用 Kubernetes 开箱即用的东西。因此，在您的平台中拥有另一个外部服务将是另一个需要维护、部署的应用程序，并且可能成为故障点。所以我会坚持使用 Kubernetes 提供的服务发现。