Spring Cloud 与 Docker Swarm 和 Kubernetes 等编排工具的结合 [英] Combination of Spring Cloud and Orchestration Tools Like Docker Swarm and Kubernetes

问题描述

我有一个使用 Spring Cloud Netflix 实现的云原生应用程序.

I have a cloud-native application, which is implemented using Spring Cloud Netflix.

因此，在我的应用程序中，我使用 Eureka 服务发现来管理应用程序不同服务的所有实例.当每个服务实例想要与另一个服务实例通信时，它使用 Eureka 来获取有关目标服务的所需信息(例如 IP 和端口).

So, in my application, I'm using Eureka service discovery to manage all instances of different services of the application. When each service instance wants to talk to another one, it uses Eureka to fetch the required information about the target service (IP and port for example).

服务编排也可以使用Docker Swarm和Kubernetes之类的工具来实现，看起来Eureka做的事情有些重叠以及 Docker Swarm 和 Kubernetes 可以做什么.

The service orchestration can also be achieved using tools like Docker Swarm and Kubernetes, and it looks there are some overlaps between what Eureka does and what Docker Swarm and Kubernetes can do.

例如，假设我在 Docker Swarm 中创建了一个具有 5 个实例的服务.因此，swarm 确保这 5 个实例始终启动并运行.此外，应用程序的每个服务都会在内部定期向 Eureka 发送心跳，以表明它仍然存在.看起来我们这里有两层健康检查，一层用于 Docker，另一层用于 Spring Cloud 本身.

For example, Imagine I create a service in Docker Swarm with 5 instances. So, swarm insures that those 5 instances are always up and running. Additionally, each services of the application is sending a periodic heartbeat to the Eureka internally, to show that it's still alive. It seems we have two layers of health check here, one for Docker and another inside the Spring Cloud itself.

或者，例如，您可以为整个 swarm 中的服务公开一个端口，这消除了对服务发现的一些需求(端口总是显而易见的).另一个例子可能是由 docker 内部的 routing mesh 执行的负载平衡，以及由 Ribbon 组件或 Eureka 本身在内部发生的负载平衡.在这种情况下，拥有硬件负载平衡器，我们就可以实现 3 层负载平衡功能.

Or for example, you can expose a port for a service across the entire swarm, which eliminates some of the needs to have a service discovery (the ports are always apparent). Another example could be load balancing performed by the routing mesh inside the docker, and the load balancing happening internally by Ribbon component or Eureka itself. In this case, having a hardware load balancer, leads us to a 3-layered load balancing functionality.

那么，我想知道将这些工具一起使用是否合理?使用这些技术的组合似乎大大增加了应用程序的复杂性，并且可能是多余的.

So, I want to know is it rational to use these tools together? It seems using a combination of these technologies increases the complexity of the application very much and may be redundant.

感谢阅读！

推荐答案

如果您的应用程序已经在运行，那么移除 netflix 组件可能比保留它们需要更多的努力和风险.有一种说法是，如果您可以删除例如尤里卡那么你就不需要维护它了，升级也少了一件事情.但这可能不能证明这种努力是合理的，它还取决于您是否将它用于编排工具可能无法完成的任何事情.

If you already have the application working then there's presumably more effort and risk in removing the netflix components than keeping them. There's an argument that if you could remove e.g. eureka then you wouldn't need to maintain it and it would be one less thing to upgrade. But that might not justify the effort and it also depends on whether you are using it for anything that might not be fulfilled by the orchestration tool.

例如，如果您要连接到未设置为负载平衡的服务 ('headless services') 那么您可能需要在您的服务中使用功能区.(您可以使用 spring cloud kubernetes incubator 项目 中的工具执行此操作或者它的 fabric8 等价物.)另一种需要注意的情况是当你连接时到外部服务(即 kubernetes 集群之外的服务) - 那么您可能想要添加负载平衡或速率限制，并且ribbon/hystrix 将是一个选项.这将取决于您对负载平衡或速率限制的要求的细微差别.

For example, if you're connecting to services that are not set up as load-balanced ('headless services') then you might want ribbon within your services. (You could do this using tools in the spring cloud kubernetes incubator project or its fabric8 equivalent.) Another situation to be mindful of is when you're connecting to external services (i.e. services outside the kubernetes cluster) - then you might want to add load-balancing or rate limiting and ribbon/hystrix would be an option. It will depend on how nuanced your requirements for load-balancing or rate-limiting are.

您已经专门询问过 netflix，但值得明确指出的是，spring cloud 包括其他组件，而不仅仅是 netflix 的组件.还有其他重叠领域需要您做出选择.

You've asked specifically about netflix but it's worth stating clearly that spring cloud includes other components and not just netflix ones. And that there's other areas of overlap where you would need to make choices.

我专注于 Kubernetes 而不是 docker swarm 部分是因为这是我最了解的部分，部分是因为我认为这是 行业旅行 - 关于这一点，您应该注意kubernetes 在 docker EE 中可用.我想你已经阅读了很多比较文章，但是 https://hackernoon.com/a-kubernetes-guide-for-docker-swarm-users-c14c8aa266cc 可能对您特别感兴趣.

I've focused on Kubernetes rather than docker swarm partly because that's what I know best and partly because that's what I believe to be the current direction of travel for the industry - on this you should note that kubernetes is available within docker EE. I guess you've read many comparison articles but https://hackernoon.com/a-kubernetes-guide-for-docker-swarm-users-c14c8aa266cc might be particularly interesting to you.

这篇关于Spring Cloud 与 Docker Swarm 和 Kubernetes 等编排工具的结合的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！