Spring Cloud 与 Docker Swarm 和 Kubernetes 等编排工具的结合

Question

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

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

服务编排也可以使用Docker Swarm 和Kubernetes 之类的工具来实现，看起来Eureka 的功能与Docker Swarm 和Kubernetes 的功能之间存在一些重叠。

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

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

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

感谢您的阅读！

Answer 1

是的，你是对的。我们在 Oracle 云平台和Predix Cloud Foundry 上部署了类似的Spring Cloud Netflix 应用程序。如果您使用多个 Kubernetes 集群，那么您必须使用 Ribbon 负载均衡，因为您有多个服务实例。

我无法告诉你Kubernetes 或Docker Swarm 哪个更好。我们使用Kubernetes 进行服务编排，因为它提供了更大的灵活性。

Answer 2

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

例如，如果您要连接的服务未设置为负载平衡 ('headless services')，那么您可能需要在您的服务中使用功能区。 （您可以使用spring cloud kubernetes incubator project 或其fabric8 equivalent 中的工具来执行此操作。）另一种需要注意的情况是当您连接到外部服务（即kubernetes 集群之外的服务）时——那么您可能想要添加负载- 平衡或速率限制和功能区/hystrix 将是一个选项。这将取决于您对负载平衡或速率限制的要求有多细微。

您已经专门询问了 netflix，但值得明确说明的是，spring cloud 包括其他组件，而不仅仅是 netflix 组件。 And that there's other areas of overlap where you would need to make choices.

我专注于 Kubernetes 而不是 docker swarm 部分是因为这是我最了解的部分，部分是因为我认为这是 travel for the industry 的当前方向 - 在此您应该注意 kubernetes is available within docker EE。我猜你已经阅读了很多比较文章，但https://hackernoon.com/a-kubernetes-guide-for-docker-swarm-users-c14c8aa266cc 可能对你来说特别有趣。

Answer 3

你是对的，它看起来确实是多余的。从个人观察来看，我认为该架构的每一层都应该以自己特定的方式处理负载平衡。它最终为您提供了更多的灵活性，而不是更多的成本。如果您想利用客户端负载平衡和任何故障转移功能，那么拥有 Eureka 是有意义的。主要好处是，如果您不想利用所有功能，则不必这样做。

容器编排级别负载平衡为任何不符合驻留在应用程序级别 (Eureka) 的服务发现部分的应用程序或服务提供了位置。

硬件负载平衡器提供了另一个级别，允许在容器编排器之外进行负载平衡。

我遇到的特定用例是在 AWS 上使用 Traefik 和 Eureka 使用 Spring Cloud 的 Kubernetes 集群。