最近，几个服务发现工具变得越来越受欢迎/"主流"。我想知道在什么情况下应该使用它们而不是传统的负载均衡器。
对于负载均衡器，您将一组节点集群在平衡器后面，然后客户端向平衡器发出请求，平衡器通常会将这些请求循环发送到集群中的所有节点。
使用服务发现（如Consul、ZK等），您可以让集中式的“共识”服务确定哪些特定服务的节点是健康的，然后您的应用程序会连接到被服务认为是健康的节点。因此，虽然服务发现和负载均衡是两个不同的概念，但服务发现会方便地为您提供负载均衡。
但是，如果负载均衡器（例如HAProxy或nginx）内置了监视和健康检查，则您基本上会获得以负载均衡为副作用的服务发现!这意味着，如果我的负载均衡器知道不要将请求转发到其集群中的不健康节点，那么在功能上相当于共识服务器告诉我的应用程序不要连接到不健康节点。
因此，在我看来，服务发现工具就像是负载均衡器的“半斤六两”等价物。我是否漏掉了什么？如果某人的应用程序架构完全依赖于负载平衡微服务，那么切换到基于服务发现的模型有何益处（或无益）？
负载均衡器通常需要资源的端点来平衡流量负载。随着微服务和基于容器的应用程序的增长，运行时创建的动态容器（Docker 容器）是短暂的，并且没有静态的端点。这些容器端点是短暂的，它们随着它们被逐出和创建以进行缩放或其他原因而改变。类似 Consul 的服务发现工具用于存储动态创建的容器（Docker 容器）的端点信息。类似 consul-registrator 运行在容器主机上，将容器端点注册到类似 Consul 的服务发现工具中。类似 Consul-template 的工具会监听 Consul 中容器端点的更改，并更新负载均衡器（Nginx），以便发送流量。因此，服务发现工具（如 Consul）和负载均衡工具（如 Nginx）共存，分别提供运行时服务发现和负载均衡功能。
后续问题：短暂节点（即出现和消失，生存和死亡的节点）与传统虚拟机等“永久”节点相比有哪些好处？
[DDG]: 我想到的东西包括：像 Docker 容器这样的短暂节点非常适合无状态的服务，例如 API 等。（使用外部卷 - 卷驱动程序等存在持久性容器的势头）
速度：启动或销毁短暂容器（从镜像中的 Docker 容器）需要少于 500 毫秒，而不是传统虚拟机需要数分钟。
弹性基础设施：在云时代，我们希望根据用户的需求进行扩展和收缩，这意味着会有短暂的容器（无法保留 IP 地址等）。想象一下一周的市场营销活动，我们预计 TPS 流量将增加 200％，使用容器快速扩展，然后在活动结束后将其销毁。
资源利用：数据中心或云现在是一个大型计算机（计算集群），而容器则对计算集群进行了打包，以实现最大化的资源利用率，并在需求低峰期间销毁基础设施以降低账单或资源使用率。
之所以能够实现这些，很大程度上要归功于与短暂容器的松耦合和使用像 Consul 这样的服务发现工具进行运行时发现。传统虚拟机和 IP 的紧密绑定可能会抑制这种能力。
