问题描述
我正在将一组使用Docker容器化的服务部署到AWS中.无论选择哪种部署解决方案(例如原始EC2/ECS/Elastic Beanstalk/Fargate)，我们都将面临服务发现"的问题.
I am deploying a set of services that are containerised using Docker into AWS. No matter which deployment solution is chosen (e.g. raw EC2/ECS/Elastic Beanstalk/Fargate) we will face the issue of "service discovery".
仅列举我考虑过的一些服务发现选项:
To name just a few of the options for service discovery that I've considered:
- AWS Route 53服务注册表
- Kubernetes
- Hashicorp领事
- Spring Cloud Netflix Eureka
我正在使用Spring Cloud开发Java Spring Boot应用程序，目标部署环境是AWS.
I am developing Java Spring Boot applications using Spring Cloud with the target deployment environment being AWS.
鉴于我的堆栈是基于Spring的，因此在本地开发时，春季云eureka对我来说很有意义.设置单个节点很容易，可以很好地与所选的堆栈和生态系统集成，并且只需很少的设置.
Given that my stack is Spring based, spring cloud eureka made sense to me while developing locally. It was easy to set up a single node, integrates well with the stack and ecosystem of choice and required very little set up.
在本地，我们使用docker compose(而不是swarm)来部署服务-部署的容器之一是单节点Eureka服务发现服务器.
Locally, we are using docker compose (not swarm) to deploy services - one of the containers deployed is a single node Eureka service discovery server.
但是，当我们超出本地开发范围而进入阶段或生产环境时，我们正在考虑使用Kubernetes之类的选择.
However, when we progress outside of local development and into staging or production environment we are considering options like Kubernetes.
要求我们将代码专门耦合到AWS服务.本质上这不是问题，但无论如何，我们在协议栈的其他部分(SNS/SQS)都束手无策.
Requires us to couple code specifically to AWS services. Not a problem per se, we are quite tied in anyway on other parts of the stack (SNS/SQS).
由于依赖于Route 53，使得在本地运行堆栈稍微困难些，我想我们可以为本地开发开放某个托管区域.
Makes running the stack locally slightly more difficult as it relies on Route 53, I suppose we could open up a certain hosted zone for local development.
AWS本机，没有管理服务注册表或额外的活动部件".
AWS native, no managing service registries or extra "moving parts".
不利的一面是，这需要我们部署和管理高可用性服务注册表集群，并且需要更多资源.另一个动向"要管理.
Downside is that thus requires us to deploy and manage a high availability service registry cluster and requires more resources. Another "moving part" to manage.
优点是它非常适合我们的堆栈(spring生态系统，spring boot，spring cloud，feign和zuul可以很好地与此配合使用).也可以在本地轻松运行.
Advantages are that it fits into our stack well (spring ecosystem, spring boot, spring cloud, feign and zuul work well with this). Also can be run locally trivially.
我认为我们需要配置网络和注册表区域，以确保客户端发布其主机地址，而不是docker容器内部IP地址.例如如果服务A在主机A上并且想与主机B上的服务B进行通信，则服务B需要公布其EC2地址，而不是某些内部docker IP.
I presume we need to configure the networks and registry zone to ensure that that clients publish their host address rather and docker container internal IP address. e.g. if service A is on host A and wants to talk to service B on host B, service B needs to advertise its EC2 address rather than some internal docker IP.
如果我们使用Kubernetes进行编排，则使用Spring Cloud Eureka之类的东西取代此处所述的内置服务发现选项会有任何不利之处 https://kubernetes.io/docs/concepts/services-networking/service/#discovering-services
If we use Kubernetes for orchestration, are there any disadvantages to using something like Spring Cloud Eureka over the built in service discovery options described here https://kubernetes.io/docs/concepts/services-networking/service/#discovering-services
鉴于Kube提供了这一点，因此似乎不理想，然后使用通过kube部署的eureka进行发现.我认为kube可以进行一些优化，以影响使用尤里卡(eureka)可能实现的可用性和稳定性.例如，kube会知道何时部署新服务-尤里卡将不得不依靠心跳/运行状况检查，并取决于配置方式(例如频率)，这可能会导致过时的记录，而我认为kube对于计划中的服务关闭可能不会因此而受苦/重新启动.我猜它仍然可以解决计划外的故障，例如主机故障或网络分区.
Given Kube provides this, it seems suboptimal to then use eureka deployed using kube to perform discovery. I presume kube can make some optimisations that impact avaialbility and stability that might nit be possible using eureka. e.g kube would know when deploying a new service - eureka will have to rely on heartbeats/health checks and depending on how that is configured (e.g. frequency) this could result in stale records whereas i presume kube might not suffer from this for planned service shutdown/restarts. I guess it still does for unplanned failures such as a host failure or network partition.
有人对此有任何建议吗?人们使用Kubernetes之类的服务，但使用其他机制进行服务发现，而不是kube提供的那些机制.有充分的理由做一个或另一个吗?
Does anyone have any advice on this, do people use services like Kubernetes but use other mechanisms for service discovery rather than those provided by kube. Is there a good reason to do one or the other?
我们可以替换eureka，但是依靠Kube执行发现将意味着我们需要在本地运行kube进行部署，而当前我们只有一个简单的小型docker-compose文件.另外，我必须看看确保缎带，zuul和假装与之完美搭配会变得多么容易.
We could replace eureka, but relying on Kube to perform discovery will mean that we need to run kube locally to deploy whereas currently we have a simple tiny docker-compose file. Also, I'll have to look at how easy it'll be to ensure that ribbon, zuul and feign play nicely with this.
当前，我们为功能区配置了eureka客户端，以便服务A可以像"service-b"一样为服务B提供服务器，并让功能区通过eureka客户端解析健康的主机.我想我们可以将功能区配置为不使用eureka并使用外部Kube服务名称，该名称将在运行时由Kube DNS解析...
Currently we have ribbon configured with a eureka client so that service A can server to service B just as "service-b" for example and have ribbon resolve a healthy host via a eureka client. I guess we can configure ribbon to not use eureka and use an external Kube service name which will be resolved by Kube DNS at runtime...
在此先感谢您的贡献或建议.我知道这可能会引起人们对意见的关注.但是，我希望有人可以提供客观的指导，以指导何时可以采用一种解决方案.
Thanks in advance for any contribution or advice. I know this might elicit a primarily opinion focused response. But I am hoping someone can provide objective guidance on when one solution might be preferable to another.
推荐答案
使用Kubernetes可以立即使用服务发现.因此，在平台中拥有另一个外部服务将是另一个要维护，部署和出现故障的应用程序.因此，我会坚持使用Kubernetes提供的服务发现.
Service discovery is something you get out-of-the-box with Kubernetes. So having another external service in your platform will be another application to maintain, deploy and can be a point of failure. So I would stick with the the service discovery provided by Kubernetes.
这篇关于使用Eureka进行Kubernetes服务发现的缺点的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！