将Spring Cloud与Orchestration工具一起使用，如Docker Swarm和Kubernetes
我有一个云原生应用程序，它是使用Spring Cloud Netflix 。
所以在我的应用程序中，我正在使用Eureka服务发现来管理应用程序的不同服务的所有实例。 当每个服务实例想要与另一个服务实例通信时，它使用Eureka获取有关目标服务的所需信息（例如，ip和port）。
服务编排也可以使用Docker Swarm和Kubernetes等工具实现，看起来Eureka和Docker Swarm和Kubernetes之间存在一些重叠。
例如，想象一下，我在Docker Swarm创建了一个具有5个实例的服务，并且swarm确保这5个实例始终正常运行。 此外，该应用程序的每项服务都在内部向Eureka发送定期心跳，以表明它仍然存在。 看起来我们有两层健康检查，一个用于Docker ，另一个用于Spring Cloud本身。
或者，例如，您可以在整个swarm中公开服务的端口，这消除了一些服务发现的需求（端口始终是明显的）。 另一个例子可能是由docker中的routing mesh执行的负载平衡，以及由Ribbon组件或Eureka本身在内部发生的负载平衡。 在这种情况下，具有硬件负载平衡器，引导我们到3层负载平衡系统。
所以我想知道将这些工具一起使用是否合理？ 似乎使用这些技术的组合会极大地增加应用程序的复杂性并且可能是多余的。
谢谢你的阅读！
你是对的，因为它看起来多余。 从个人观察来看，我认为该架构的每一层都应该以自己特定的方式处理负载平衡。 它最终为您提供了更多的灵活性，而且成本更高。 如果您想利用客户端负载平衡和任何故障转移function，那么拥有Eureka是有意义的。 主要的好处是，如果您不想利用所有function，则不必。
容器编排级别负载平衡可以为任何不符合位于应用程序级别（Eureka）的服务发现部分的应用程序或服务提供场所。
硬件负载平衡器提供了另一个级别，允许在容器协调器外部进行负载平衡。
我遇到的具体用例是在AWS上使用Traefik和Eureka以及Spring Cloud的Kubernetes集群。
如果您已经有应用程序正在运行，那么删除netflix组件可能比保留它们更多的努力和风险。 有一种说法是，如果你可以移除例如尤里卡，那么你就不需要维护它，升级也就少了。 但这可能无法certificate这项工作的合理性，也取决于您是否将其用于编排工具可能无法实现的任何内容。
例如，如果您要连接到未设置为负载平衡的服务 （ “无头服务” ），那么您可能需要在服务中使用function区。 （你可以使用spring cloud kubernetes孵化器项目中的工具或者它的fabric8等效工具来做到这一点。）另外需要注意的是当你连接到外部服务（即kubernetes集群之外的服务）时 – 你可能想要添加负载均衡或速率限制和ribbon / hystrix是一种选择。 这取决于您对负载平衡或速率限制的要求的细微差别。
您已经具体询问了netflix，但值得一提的是，Spring云包含其他组件，而不仅仅是netflix组件。 而且还有其他需要做出选择的重叠区域。
我专注于Kubernetes而不是Docker swarm部分是因为这是我最了解的，部分是因为我认为这是行业当前的旅行方向 – 在此你应该注意到kubernetes在docker EE中可用 。 我想你已经阅读了很多比较文章，但https://hackernoon.com/a-kubernetes-guide-for-docker-swarm-users-c14c8aa266cc对你来说可能特别有趣。
是的，你是对的。 我们在Oracle云平台和Predix Cloud Foundry上部署了类似的Spring Cloud Netflix应用程序。 如果您使用多个Kubernetes群集，则必须使用function区负载平衡，因为您有多个服务实例。
我不能告诉你哪个更好的Kubernetes或Docker Swarm 。 我们使用Kubernetes进行服务编排，因为它提供了更大的灵活性。