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