通常这时会出现两个问题：负载均衡 ADC 如何决定将连接发送到哪个主机？以及如果选定的主机不工作会怎样？

我们先讨论第二个问题。如果选定的主机不工作会怎样？简单的答案是，它会不响应客户端的请求，导致连接尝试最终超时失败。这种状况显然不可取，因为它不能确保高可用性。这就是为什么大多数负载均衡技术都包括一定级别的健康监控，以确定主机是否真正可用，然后再尝试向其发送连接。

健康监控设有多个级别，每个级别的健康监控的粒度和重点都在不断提升。基本监控器只是简单地对主机本身进行 ping。如果主机对 ping 没有响应，那么就可以推定主机上定义的任何服务都可能已经宕机，应该将其从可用服务集群中删除。然而问题在于，即使主机响应 ping，也不一定意味着服务本身工作正常。因此，大多数设备都可以进行某种形式的“服务 ping”，从简单的 TCP 连接一直到通过脚本或智能交互与应用进行交互。这些更高级别的健康监控器不仅可以为实际服务（相对于主机而言）的可用性提供更多的可靠性，而且还可以让负载平衡器区分单个主机上的多个服务。负载均衡器可以判断出，虽然一个服务可能不可用，但同一主机上的其他服务可能工作正常，因此仍应该将其视为用户流量的有效目的地。

这就回到了第一个问题。ADC 如何决定向哪个主机发送连接请求？每台虚拟服务器都有一个特定的专用服务集群（列出提供该服务的主机），构成可用性列表。此外，健康监控会修改该列表，使其成为提供指定服务的“当前可用”主机的列表。ADC 正是从这个修改后的列表中选择将接收新连接的主机。主机的精准选择取决于与该特定集群相关联的负载均衡算法。其中一些算法包括最小连接数、动态比率和简单轮询。轮询时，负载均衡器只需从列表顶部开始向下，将每个新连接分配给下一个主机；当到达列表底部时，只需从顶部重新开始即可。虽然该过程简单，可预测性也很好，但有时它会推定所有连接在后端主机上的负载和持续时间都是相似的，而事实却并非总是如此。更先进的算法会使用诸如当前连接数、主机利用率，甚至是主机现有流量的真实响应时间，以便从可用的集群服务中挑选出最合适的主机。

足够先进的应用交付系统还能够将健康监控信息与负载均衡算法进行结合，从而拥有对服务依赖性的解读能力。当一个主机有多个服务，并且这些服务对于完成用户请求而言缺一不可时，该功能的作用将尤其明显。在这种情况下，您并不想看到用户访问的主机上一个服务可用，而其他服务却停止运行。换句话说，如果主机上的一个服务发生故障，您所希望的是主机能够从集群的可用服务列表中提供另一个服务。随着服务与 HTML 和脚本的差异化越来越大，这个功能将变得越来越重要。