为此，我特指在Windows上运行网站，但不是特定于IIS。 我们有时也运行Tomcat。 现在显然有很多硬件和软件可供select，在Windows世界中有很多要考虑的问题，例如粘性会话和状态，这在Web应用程序中有时是固有的。
所以我在寻找的是有效的负载平衡策略，不pipe是基于硬件还是基于软件的任何良好体验，以及certificate与此相关的商业成本的理由。
谢谢
更新：
为了回应Paul提出的一些更深层次的问题，我个人会寻求最小的负载平衡，并确保会话失败。 现在这种事情也可以通过像Memcached或类似的东西来处理。 SSLterminal非常依赖于你是去硬件还是软件路线，但是我不如回答我自己的问题。
卷可以是任何东西，从计划启动，希望成倍增长，而不会向用户提供臭名昭着的失败鲸…
这个问题特别提出了什么样的负载平衡策略在过去对于在Windows上运行网站是有效的。 如果您提出的策略是硬件负载平衡，例如在负载均衡器处发生SSL终止，并且您详细说明了为什么这对您来说是一个好策略，那么这将有助于回答我的问题。 现在，我只是没有足够的经验，不同的方法和select，因此我的问题。
我是Windows负载平衡服务（WLBS）的忠实粉丝。 我意识到，有人可能会说这不是处理大型网站的任务，但不知何故微软能够使它为Microsoft.com工作，所以我倾向于不同意这些声明。
像scevans提到负载平衡当然可以用Windows NLB完成。 我猜想大多数Windowsnetworking商店都是以这种方式开始的。 有些则继续无限期地使用它。
NLBperformance糟糕，这是一个普遍的误解，从performance的angular度来看，这真的不是一个糟糕的performance。 NLB对于一些相对稳定且不在积极开发中的应用程序来说非常有用。 NLB开始让你失望的是状态检查，NLB对应用层基本上完全没有意义，因此在某个时候，当你的JVM或IIS工作进程中的一个爆炸时，NLB将继续看到服务器被破坏，并继续愉快地将请求发送到您的服务器上的closures应用程序，这显然是不好的。
这就是构buildWeb负载均衡器的目的所在。 几乎所有的人都支持各种各样的平衡方法，从循环，最less的连接和加权版本。
能够为每个服务器上的每个应用程序指定一个运行状况检查页面，带来了更高的可信度，并允许负载平衡器做出更好的决策。 根据您的申请，健康检查页面通常应该是专门build立的。 我喜欢健康检查页面来快速轮询数据库服务器，以确保数据库连接function。 这个电话应该是超级便宜，我们的数据库精灵提供这个我认为它是一个'select1'，但我可能是错的。 如果调用成功，testing页面将显示一个服务器标识符（我们也使用这个页面来查看在sticky enabled Farms上我们遇到的服务器）。 无论如何，负载均衡器会每分钟多次触发一次，然后parsing响应文件，只要它不失败，就停留在循环中。 如果该页面因任何原因失败，则服务器将从旋转中移除。 对于pipe理Web服务器的人员不具备对负载平衡器的专业知识/访问权限的情况，这也很方便。 通过简单地重命名运行状况检查文件，他们可以轻松地将服务器拉出轮换以进行部署或故障排除。 大多数负载均衡器也可以configuration一个抱歉的服务器。 如果运行状况检查在服务器场中的所有节点上都失败，则会将用户发送到包含（静态）维护页面的其他服务器。
负载平衡器上的SSLterminal也可以得心应手。 有些负载平衡器不会说健康检查的HTTPS，所以在某些情况下，卸载SSL是唯一能够利用上面列出的与健康状况检查相关的所有function的方法。 卸载你的SSL也明显地释放了Web服务器的CPU周期来服务网站，而不是encryption/解密，但对我来说更大的好处是围绕故障排除和SSLpipe理。 根据您的平台和工具，在大型服务器场中pipe理SSL证书不是很容易（msdeploy在最新版本之前不支持）。 在2个负载平衡器上安装证书通常比10+个服务器更快/更容易。 这对于故障排除也是非常有帮助的，每当你遇到需要挖掘到数据包级别并监听发送到Web服务器的信息时，你都会得到这个超级奇怪的问题。 通过卸载SSL，所有这些stream量都是纯文本的，并且更容易分析。 注意：这也意味着您的负载均衡器和您的服务器之间的网段需要安全。
关于故障转移，我认为应用程序应该被devise为不需要粘性会话，除非有非常令人信服的理由。 在.NET世界中，这通常就像configuration应用程序以将其会话状态发送到所有节点上的sql server一样简单，并确保所有会话对象都是可序列化的（第一次转向时会出现一个很大的错误如果他们不是）。 当你运行这个configuration时，你可以在不影响用户的情况下在Web服务器上工作，只需要从服务器上移除服务器，进行修改，然后重新进行轮换。 由于会话数据全部集中存储在SQL中，因此哪个节点应答请求并不重要。
关于软件与硬件和合理的成本，这是一个小窍门。 如果你有预算的硬件平衡器是好的。 在硬件上做东西显然更快，更重要的是，从硬件供应商那里得到的支持通常要好很多。 现在，软件平衡器function越来越完备。
我的大部分经验都在F5-BigIP，Cisco Arrowpoint / CSS和Cisco ACS线路上。 我最近已经开始关注IIS7应用程序请求路由（ARR），为我的咨询客户预算。 如果你有硬件和windows的许可证，它不会花费任何东西，而且看起来function完整。 我有兴趣看看它是如何叠加起来的。 你可以在这里find更多关于ARR的信息 。
让我知道你是否想要更具体的信息
我想，你将不得不再次定义“有效的”。
你想做什么样的负载平衡？ 循环，最小负载，goegraphical负载平衡？
你想在包检查（第2/3层或第7层深度包检查）中走多深？
你需要会话故障切换吗？
你在谈什么types的书？
你想在哪里做你的SSL终止？
您的select从简单的Windows NLB转移到具有SSL加速器的全球分布式硬件负载均衡冗余arrays。 没有最好的答案是“最有效的”
我们更喜欢使用冗余硬件的硬件负载平衡器解决scheme。 我们也使用我们的负载均衡器作为SSL端点。 它不处理会话故障转移。 它依靠Web服务器来做到这一点。 例如，我们使用configurationWeblogic服务器来处理会话故障转移。
HAProxy 。 超级可靠，安全并运行大量的大系统。 该网页通常包含大量有关负载平衡的信息，还有一些公司会为您提供交钥匙系统，例如Loadbalancer.org
如果你很便宜，而且任务很小，那么有一个称为分发器的小型高效Java负载均衡器（Sourceforce – distributor.shourceforce.com）。我是pipe理员和开发人员 – 安装和运行起来非常简单，后台服务器监控还可以在服务器恢复后恢复故障转移。
试试吧，告诉我你的想法！
当然，这不是一个硬件负载平衡，如果你有一个小时的数百万次点击，这不适合你！
保罗