检查节点运行状况的服务发现工具和负载均衡器之间的概念差异是什么？

Question

最近几种服务发现工具已经变得流行/"主流",我想知道在哪些主要用例中应该使用它们而不是传统的负载平衡器.

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

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

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

所以对我来说,服务发现工具感觉就像"6合1,其他半打"相当于负载均衡器.我在这里错过了什么吗？如果有人的应用程序架构完全基于负载平衡微服务,那么切换到基于服务发现的模型有什么好处？

Answer 1

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

跟进:短暂节点(来来往往,生存和死亡)与传统虚拟机等"永久"节点相比有什么好处？

[DDG]:我脑海中浮现的事情:像docker容器这样的短暂节点适用于API之类的无状态服务(使用外部卷的持久性容器有牵引力 - 卷驱动程序等)

1. 速度:旋转或破坏短暂的容器(图像中的泊坞容器)需要不到500毫秒,而传统虚拟机需要几分钟

2. 弹性基础设施:在云时代,我们希望根据用户需求进行扩展,这意味着将会出现短暂的容器(无法保留IP等).想想一个星期的营销活动,我们预计交通TPS会增加200%,快速扩展容器,然后发布活动,销毁它.

3. 资源利用率:数据中心或云现在是一台大型计算机(计算集群),容器打包计算集群以获得最大的资源利用率,并且在需求疲软时会破坏基础架构以降低资金使用率.

这很可能是因为与短暂的容器失去耦合以及使用像consul这样的服务发现工具进行运行时发现.传统的虚拟机和IP的紧密绑定可能会扼杀这种能力.