我有一个使用Spring Cloud Netflix实现的云原生应用程序。
因此，在我的应用程序中，我正在使用Eureka服务发现来管理应用程序不同服务的所有实例。每个服务实例都想与另一个服务实例进行对话时，它使用Eureka来获取有关目标服务的必需信息（例如IP和端口）。
也可以使用Docker Swarm和Kubernetes之类的工具来实现服务编排，并且看起来Eureka和Docker Swarm和{{ 1}}可以。
例如，假设我在Kubernetes中创建了5个实例的服务。因此，群集确保这5个实例始终处于运行状态。此外，应用程序的每个服务都在内部向Docker Swarm发送定期心跳，以表明它仍然有效。看来我们这里有两层健康检查，一层对Eureka，另一层在Docker内部。
例如，您可以在整个集群中公开服务的端口，从而消除了进行服务发现的某些需求（端口始终是显而易见的）。另一个示例可能是由docker内部Spring Cloud执行的负载平衡，而负载平衡由routing mesh组件或Ribbon本身在内部进行。在这种情况下，拥有硬件负载平衡器可以使我们获得三层负载平衡功能。
因此，我想知道一起使用这些工具是否合理？结合使用这些技术似乎会大大增加应用程序的复杂性，并且可能是多余的。
感谢您的阅读！
答案 0 :(得分：0)
您是正确的，因为它看起来确实多余。从个人观察，我认为该体系结构的每一层都应以其自己的特定方式处理负载平衡。最终为您提供了更多的灵活性，而没有太多的成本。如果您想利用客户端负载平衡和任何故障转移功能，那么拥有Eureka是有意义的。主要优点是，如果您不想利用所有功能，则不必这样做。
容器业务流程级别的负载平衡在不符合驻留在应用程序级别（Eureka）的服务发现片的任何应用程序或服务中占有一席之地。
硬件负载平衡器提供了另一个级别，可用于在容器协调器之外进行负载平衡。
我遇到的特定用例是在AWS上使用Traefik和Eureka以及Spring Cloud在Kubernetes集群上。
答案 1 :(得分：0)
是的，您是正确的。我们在Oracle云平台和Spring Cloud Netflix上部署了类似的Predix Cloud Foundry应用程序。如果使用多个Kubernetes集群，则必须使用功能区负载平衡，因为您有多个服务实例。
我无法告诉您Kubernetes或Docker Swarm哪个更好。我们使用Kubernetes进行服务编排，因为它提供了更大的灵活性。
答案 2 :(得分：0)
如果您已经有应用程序在工作，那么删除netflix组件可能比保留它们要付出更多的努力和风险。有一种说法是，如果您可以删除例如eureka，那么您将不需要维护它，升级将少一件事情。但这可能并不能证明付出努力的合理性，还取决于您是否将其用于编排工具可能无法完成的任何事情。
例如，如果要连接到未设置为负载平衡（'headless services'）的服务，则可能需要在服务中使用功能区。 （您可以使用spring cloud kubernetes incubator project或其fabric8 equivalent中的工具来执行此操作。）要注意的另一种情况是，当您连接到外部服务（即kubernetes集群之外的服务）时，您可能会要添加负载平衡或速率限制，功能区/ hystrix将是一个选择。这将取决于您对负载平衡或速率限制的要求有多细微差别。
您已经具体询问过netflix，但是值得一提的是，春季云还包括其他组件，而不仅仅是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可能对您特别有趣。