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