这是一个非常广泛的问题，但希望我能得到有用的提示。目前我有一个在单个服务器上运行的 ASP.NET 应用程序。我现在需要向外扩展以适应不断增加的客户负载。所以我的计划是：
1) 将 ASP.NET 和 Web 组件扩展到五台服务器上。
2) 将数据库移动到场。
我不相信数据库会出现问题，因为就应用程序而言，它只是一个 IP 地址。但是，我现在担心 ASP.NET 和 Web 层。我已经担心的一些问题：
实现负载均衡器的最简单模型是否会以循环方式将请求分流到五台服务器中的每台服务器？
HTTPS 和 SSL 连接是否存在任何问题，因为每次发出请求时它们都可以在不同的物理服务器上终止？（例如，性能？）
是否有关于通过 cookie 进行会话维护（登录）的问题？我的猜测是否定的，但不能完全解释为什么...... ;-)
会话数据本身（存储的服务器端）是否有任何问题？显然，我需要在服务器之间复制会话状态，或者以某种方式强制请求只发送到单个服务器。无论哪种方式，我在这里看到一个问题......
正如大卫所指出的，这个问题的大部分实际上更像是一个管理问题，并且可能对 ServerFault 有用。他发布的链接有很好的信息可供研究。
对于您的Session问题：您将希望查看会话状态服务（IIS 作为单独的服务提供，用于维护多个服务器之间的共同状态）和/或将 asp.net 会话状态存储在 SQL 数据库中。我敢肯定，这两个选项都可以在 David Stratton 的链接中找到。
很大程度上来说，一旦你设置了你的进程外会话状态，它就是透明的。不过，它确实要求您将Serializable对象存储在 Session 中。
在这种情况下，循环 DNS 是最简单的负载平衡方法，是的。它没有考虑每台服务器上的实际负载，也没有任何关于何时一台服务器可能停机维护的规定；即使其他四台服务器可能正在运行，任何获得该特定 IP 的人都会将该站点视为“关闭”。
负载平衡和处理 SSL 连接都可能受益于反向代理类型的情况；代理处理所有进入的连接，但它所做的只是加密和平衡 Web 服务器的实际请求负载。（当然，这些问题更多是在行政方面，但是......）
如果所有网络服务器都将自己宣传为同一个网站（通过主机标头等），则 Cookie 不会成为问题。每个服务器都会很乐意接受任何其他使用相同域名的服务器设置的 cookie，而无需知道或关心是哪个服务器发送的；它基于 Web 浏览器在获取 cookie 值时连接到的服务器的主机名。
这是一个相当广泛的问题，很难在这样的论坛中完全回答。我什至不确定问题是否属于这里，或者是否应该在 serverfault.com 上。然而....
Microsoft 提供了大量有关该主题的指导。BING 的“缩放 asp.net 应用程序”的第一个结果就是这样。
我只想提出您应该关注数据库的领域。
首先，大多数仅考虑单个数据库服务器构建的数据模型需要进行大量更改才能支持多主机模式下的数据库场。
如果您对主键使用自动递增整数（大多数人都这样做），那么您基本上就被淘汰了。有几种方法可以暂时缓解这种情况，但即使是那些也需要大量猜测并且很有可能发生碰撞。一种缓解措施涉及将每台服务器上的种子值设置为足够高的数字以减少发生冲突的可能性......这通常会工作一段时间。
当然，您必须弄清楚如何跨服务器对用户进行分区...
我的观点是，这个领域不应该被轻描淡写，而且几乎总是比简单地通过将数据库服务器放在更大的硬件上来“扩大”数据库服务器更难完成。
如果您故意构建具有多主角色的数据模型，请忽略。;)
关于会话：不要相信“粘性”会话，粘性不是保证。坦率地说，我们的东西通常部署到服务器场，所以我们从一开始就完全禁用会话状态。一旦你搬到农场，几乎没有理由使用会话状态，因为数据必须在每次页面加载时从状态服务器中检索、反序列化、序列化并存储回状态服务器。
考虑到数据库和网络流量，他们的目的是减少数据库和网络流量，那么您将了解他们如何不再为您购买任何东西。
我看到了一些与循环 http/https 会话相关的问题。我们曾经在进程会话中使用并告诉负载均衡器使会话保持粘性。（我认为他们为此使用了 cookie）。
它让我们避免了 SQL 会话，但意味着当我们从 http 切换到 https 时，我们的 F5 框无法保持粘性。我们最终改为使用 SQL 会话。
您可以调查将加密推送到负载均衡器。我记得这是解决我们问题的一种可能解决方案，但可惜，我们没有调查过。
SQL 服务器上的会话数据库可以通过很少的代码和配置更改轻松扩展。您可以将 asp.net 会话粘贴到会话数据库中，并且无论场中的哪个 Web 服务器为请求提供服务，您的基于会话 ID 的 sql 状态服务器映射都可以完美运行。这可能是使用 SQL Server 扩展 ASP.NET 会话状态的最佳方法之一。有关更多信息，请阅读链接True Scaleout model for session state