我读过这篇文章：Web 2.0 应用程序的客户端负载平衡。使用客户端负载平衡是否可行？缺点是什么？
答案1
您阅读的文章描述了“循环”DNS负载平衡。其好处是您依赖现有的DNS基础设施来平衡请求的去向...这种方法也有缺点...
我猜想，在执行此客户端逻辑之前，必须先对您的 Web 服务器/应用程序发出第一个请求？这意味着您最好在此请求期间提供可用服务器的列表。（这是支持客户端方法的论点）
应用程序最智能的部分是应用程序本身，而不是支持它的软件/硬件基础架构。这当然是在应用程序层的任何位置实现负载平衡的好处之一。另一个好处是理论上可以获得一定程度的高可用性。以这种方式开发应用程序还意味着将应用程序分发到多个“站点”应该相当容易。
您将面临的挑战将是所有典型的负载平衡挑战/多节点挑战。如果您使用的是基于文件的数据库或会话机制，则需要弄清楚如何共享它们。如果您正在对其中一台服务器进行维护，则客户端应用程序需要足够智能，以识别其节点何时不再可用并尝试另一个节点。如果您使用 DNS 方法 - 您的负载平衡能力将与您愿意拥有的 IP 数量直接相关。这可能会使服务器端路由器、反向代理、服务器 IP 配置变得复杂。
总而言之，我认为客户端平衡对于大多数应用程序来说都是一种很好的方法。我们对桌面应用程序使用类似的方法来实现高可用性和负载平衡。
您也可以使用混合方法。我们使用混合方法进行服务器发现，部分/其次依赖 DHCP - 这是另一个故事。