最近几种服务发现工具已经变得流行/“主流”，我想知道应该使用哪些主要用例而不是传统的负载均衡器。
使用LB，您在平衡器后面聚集了一堆节点，然后客户端向平衡器发出请求，然后平衡器（通常）将这些请求循环到集群中的所有节点。
通过服务发现（Consul，ZK等），您可以让集中的“共识”服务确定特定服务的哪些节点是健康的，并且您的应用程序连接到该服务的节点认为是健康的。 因此，虽然服务发现和负载平衡是两个独立的概念，但服务发现可为您提供负载平衡作为方便的副作用。
但是，如果负载均衡器（比如HAProxy或nginx）内置了监控和运行状况检查，那么您几乎可以将服务发现作为负载均衡的副作用！这意味着，如果我的LB知道不将请求转发到其集群中的不健康节点，那么这在功能上等同于共识服务器，告诉我的应用程序不要连接到unhealty节点。
所以对我而言，服务发现工具感觉就像“6合1，其他半打”相当于负载均衡器。我在这里错过了什么吗？如果有人的应用程序架构完全基于负载平衡微服务，那么切换到基于服务发现的模型的好处是什么（或不是）？
答案 0 :(得分：8)
负载均衡器通常需要资源的端点来平衡流量负载。随着微服务和基于容器的应用程序的增长，运行时创建的动态容器（docker容器）是短暂的，并且没有静态端点。这些容器端点是短暂的，并且随着它们被驱逐并因缩放或其他原因而被创建时它们会发生变化。像Consul这样的服务发现工具用于存储动态创建的容器（docker容器）的端点信息。像容器主机上运行的consul-registrator这样的工具在服务发现工具（如consul）中注册容器端点。像Consul-template这样的工具将监听consul中容器端点的更改，并更新负载均衡器（nginx）以便将流量发送到。因此，像Consul这样的服务发现工具和Nginx等负载平衡工具共存，分别提供运行时服务发现和负载均衡功能。
跟进：短暂节点（来来往往，生存和死亡）与传统虚拟机等“永久”节点有什么好处？
[DDG]：我脑海中浮现的事情：像docker容器这样的短暂节点适用于API之类的无状态服务（使用外部卷的持久性容器有牵引力 - 卷驱动程序等）
速度：启动或销毁短暂的容器（图像中的码头工作容器）所需的时间不到500毫秒，而传统虚拟机需要几分钟
弹性基础设施：在云时代，我们希望根据用户需求进行扩展，这意味着将会出现短暂的容器（无法保留IP等）。想想一个星期的营销活动，我们预计交通TPS会增加200％，快速扩展容器，然后发布活动，销毁它。
资源利用率：数据中心或云现在是一台大型计算机（计算集群），容器打包计算集群以实现最大的资源利用率，并且在需求疲软时会破坏基础架构以降低资金使用率。
这很可能是因为使用像consul这样的服务发现工具失去了与短暂容器的耦合和运行时发现。传统虚拟机和IP的紧密绑定可能会扼杀这种能力。
答案 1 :(得分：2)
请注意，两者不一定互相排斥。例如，您可能仍然可以将客户端定向到负载均衡器（可能执行其他角色，例如限制），但让负载均衡器使用服务注册表来定位实例。
还值得指出的是，服务发现可以实现客户端负载平衡，即客户端可以直接调用服务，而无需通过负载均衡器进行额外跳转。我的理解是，这是Netflix开发Eureka的原因之一，以避免服务间呼叫不得不通过外部ELB返回并返回他们必须支付的费用。客户端负载平衡还为客户端提供了一种基于其自身业务可用性视角影响负载平衡决策的方法。
答案 2 :(得分：1)
如果从完全不同的角度（即ITSM / ITIL）查看工具，负载平衡就变得“只是那样”，而服务发现是保持CMDB最新状态的一部分，并且可以满足您的所有服务需求，以及它们的互连性，以便在出现停机时更好地查看影响，并在高可用性应用的情况下概述可能需要补充的区域。
此外，服务发现仅为您提供上次扫描时的图片，而不是近实时（当然取决于您设置的扫描间隔），而负载平衡将保持最新应用程序健康的图片。