load-balancing - 服务发现工具和检查节点运行状况的负载均衡器在概念上有什么区别？

Question

最近有几种服务发现工具变得流行/“主流”，我想知道在哪些主要用例下应该使用它们而不是传统的负载均衡器。

使用 LB，您可以在平衡器后面聚集一堆节点，然后客户端向平衡器发出请求，然后平衡器(通常)将这些请求轮询到集群中的所有节点。

通过服务发现(Consul、ZK 等)，您可以让集中的“共识”服务确定特定服务的哪些节点是健康的，并且您的应用程序会连接到该服务认为是健康的节点。 因此，虽然服务发现和负载平衡是两个独立的概念，但服务发现为您提供了负载平衡作为一种方便的副作用。

但是，如果负载均衡器(例如 HAProxy 或 nginx )内置了监控和健康检查，那么您几乎可以将服务发现作为负载均衡的副作用!这意味着，如果我的 LB 知道不将请求转发到其集群中的不健康节点，那么这在功能上等同于共识服务器告诉我的应用程序不要连接到不健康的节点。

所以对我来说，服务发现工具感觉就像是负载均衡器的“六合一，六合一”。我在这里错过了什么吗？如果有人有一个完全基于负载平衡微服务的应用程序架构，那么切换到基于服务发现的模型有什么好处(或没有好处)？

Answer 1

负载平衡器通常需要它平衡流量负载的资源端点。随着微服务和基于容器的应用程序的增长，运行时创建的动态容器(docker 容器)是短暂的并且没有静态端点。这些容器端点是短暂的，它们会随着缩放或其他原因被驱逐和创建而改变。 Consul 等服务发现工具用于存储动态创建的容器(docker 容器)的端点信息。在容器主机上运行的 consul-registrator 等工具在 consul 等服务发现工具中注册容器端点。 Consul-template 之类的工具将在 consul 中监听容器端点的更改，并更新负载均衡器 (nginx) 以将流量发送到。因此，Consul 等服务发现工具和 Nginx 等负载平衡工具共存，分别提供运行时服务发现和负载平衡能力。

跟进:临时节点(来来去去、生死存亡)与传统 VM 等“永久”节点相比有什么好处？

[DDG]:我很快想到的事情:像 docker 容器这样的临时节点适用于 API 等无状态服务。(使用外部卷的持久性容器具有吸引力 - 卷驱动程序等)

速度:启动或销毁临时容器(镜像中的 docker 容器)只需不到 500 毫秒，而传统 VM 只需几分钟

弹性基础设施:在云时代，我们希望根据用户需求进行扩展和扩展，这意味着本质上会有短暂的容器(无法保留 IP 等)。考虑一个为期一周的营销事件，我们预计流量 TPS 会增加 200%，使用容器快速扩展，然后发布事件，销毁它。

资源利用:数据中心或云现在是一台大型计算机(计算集群)，容器打包计算集群以最大限度地利用资源，并在需求疲软时破坏基础设施以降低费用/资源使用。

这在很大程度上是可能的，因为失去了与临时容器的耦合以及使用像 consul 这样的服务发现工具的运行时发现。传统的虚拟机和 IP 的紧密绑定(bind)会扼杀这种能力。