服务发现工具和检查节点运行状况的负载均衡器之间在概念上有什么区别? [英] What is the conceptual difference between Service Discovery tools and Load Balancers that check node health?
问题描述
最近有几种服务发现工具已成为流行/主流"，我想知道在什么主要用例下应该使用它们而不是传统的负载均衡器.
Recently several service discovery tools have become popular/"mainstream", and I’m wondering under what primary use cases one should employ them instead of traditional load balancers.
使用LB，您将一堆节点群集在平衡器后面，然后客户端向平衡器发出请求，平衡器然后(通常)将这些请求轮流到群集中的所有节点.
With LBs, you cluster a bunch of nodes behind the balancer, and then clients make requests to the balancer, who then (typically) round robins those requests to all the nodes in the cluster.
使用服务发现功能(领事， ZK 等)，您可以让集中式的共识"服务确定特定服务的哪些节点运行状况良好，然后您的应用程序会连接到该服务视为运行状况良好的节点. 因此，尽管服务发现和负载平衡是两个独立的概念，但是服务发现为您带来负载平衡，这是一种方便的副作用.
With service discovery (Consul, ZK, etc.), you let a centralized "consensus" service determine what nodes for particular service are healthy, and your app connects to the nodes that the service deems as being healthy. So while service discovery and load balancing are two separate concepts, service discovery gives you load balancing as a convenient side effect.
但是，如果负载均衡器(例如 HAProxy 或
But, if the load balancer (say HAProxy or nginx) has monitoring and health checks built into it, then you pretty much get service discovery as a side effect of load balancing! Meaning, if my LB knows not to forward a request to an unhealthy node in its cluster, then that’s functionally equivalent to a consensus server telling my app not to connect to an unhealty node.
对我来说，服务发现工具就像负载平衡器一样，是六合一，六合一"的.我在这里想念什么吗?如果有人拥有完全基于负载平衡微服务的应用程序体系结构，那么切换到基于服务发现的模型有什么好处(或没有)?
So to me, service discovery tools feel like the "6-in-one,half-dozen-in-the-other" equivalent to load balancers. Am I missing something here? If someone had an application architecture entirely predicated on load balanced microservices, what is the benefit (or not) to switching over to a service discovery-based model?
推荐答案
负载平衡器通常需要平衡流量负载的资源的端点.随着微服务和基于容器的应用程序的增长，运行时创建的动态容器(docker容器)是临时的，并且没有静态端点.这些容器端点是短暂的，它们由于缩放或其他原因而被逐出和创建时会发生变化. Consul之类的服务发现工具用于存储动态创建的容器(docker容器)的端点信息.在容器主机上运行的诸如consul-registrator之类的工具会在服务发现工具(例如consul)中注册容器端点.像Consul-template这样的工具将侦听consul中对容器端点的更改，并更新负载均衡器(nginx)以将流量发送到该负载均衡器.因此，两种服务发现工具(如Consul)和负载平衡工具(如Nginx)并存，分别提供运行时服务发现和负载平衡功能.
Load balancers typically need the endpoints of the resources it balances the traffic load. With the growth of microservices and container based applications, runtime created dynamic containers (docker containers) are ephemeral and doesnt have static end points. These container endpoints are ephemeral and they change as they are evicted and created for scaling or other reasons. Service discovery tools like Consul are used to store the endpoints info of dynamically created containers (docker containers). Tools like consul-registrator running on container hosts registers container end points in service discovery tools like consul. Tools like Consul-template will listen for changes to containers end points in consul and update the load balancer (nginx) for sending the traffic to. Thus both Service Discovery Tools like Consul and Load Balancing tools like Nginx co-exist to provide runtime service discovery and load balancing capability respectively.
跟进:临时节点(来来去去，生死攸关)与传统VM等永久"节点相比有什么好处?
Follow up: what are the benefits of ephemeral nodes (ones that come and go, live and die) vs. "permanent" nodes like traditional VMs?
[DDG]:我很快想到的事情:docker容器之类的临时节点适用于API等无状态服务.(使用外部卷的持久性容器(例如卷驱动器等)很受追捧
[DDG]: Things that come quickly to my mind: Ephemeral nodes like docker containers are suited for stateless services like APIs etc. (There is traction for persistent containers using external volumes - volume drivers etc)
-
速度:旋转或销毁临时容器(图像中的docker容器)所需的时间不到500毫秒，而站立传统VM只需几分钟.
Speed: Spinning up or destroying ephemeral containers (docker containers from image) takes less than 500 milliseconds as opposed to minutes in standing up traditional VMs
弹性基础架构:在云时代，我们想要扩展并根据用户需求进行扩展，这意味着本质上将存在临时容器(无法保留IP等).考虑一个标记活动，为期一周，我们预计流量TPS将增加200％，快速使用容器扩展，然后发布活动，销毁它.
Elastic Infrastructure: In the age of cloud we want to scale out and in according to users demand which implies there will be be containers of ephemeral in nature (cant hold on to IPs etc). Think of a markerting campaign for a week for which we expect 200% increase in traffic TPS, quickly scale with containers and then post campaign, destroy it.
资源利用率:数据中心或云现在是一台大型计算机(计算集群)，并且容器打包了计算集群以实现最大的资源利用率，并且在需求疲软期间会破坏基础架构以降低账单/资源的利用率.
Resource Utilization: Data Center or Cloud is now one big computer (compute cluster) and containers pack the compute cluster for max resource utilization and during weak demand destroy the infrastructure for lower bill/resource usage.
由于与临时容器的耦合丧失以及使用服务发现工具(如领事)的运行时发现，这大部分是可能的.传统的VM和IP的紧密绑定可以扼杀此功能.
Much of this is possible because of lose coupling with ephemeral containers and runtime discovery using service discovery tool like consul. Traditional VMs and tight binding of IPs can stifle this capability.
这篇关于服务发现工具和检查节点运行状况的负载均衡器之间在概念上有什么区别?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
