缩放 ASP.NET 应用程序

Posted 2023-02-23

【中文标题】缩放 ASP.NET 应用程序

【英文标题】：Scaling an ASP.NET application

【发布时间】：2011-05-31 19:03:17

【问题描述】：

这是一个非常广泛的问题，但希望我能得到有用的提示。目前我有一个在单个服务器上运行的 ASP.NET 应用程序。我现在需要向外扩展以适应不断增加的客户负载。所以我的计划是：

1) 将 ASP.NET 和 Web 组件扩展到五台服务器。

2) 将数据库移至场。

我认为数据库不会出现问题，因为就应用程序而言，它只是一个 IP 地址。但是，我现在担心 ASP.NET 和 Web 层。我已经担心的一些问题：

最简单的模型是仅实现一个负载均衡器，以循环方式将请求分流到五台服务器中的每台服务器吗？

HTTPS 和 SSL 连接是否存在任何问题，因为每次发出请求时它们都可以在不同的物理服务器上终止？ （例如，性能？）

是否有关于通过 cookie 进行会话维护（登录）的问题？我的猜测是否定的，但不能完全解释为什么... ;-)

会话数据本身（存储在服务器端）是否有任何问题？显然，我需要在服务器之间复制会话状态，或者以某种方式强制请求仅转到单个服务器。不管怎样，我在这里看到了一个问题......

【参考方案1】：

正如 David 所指出的，这个问题的大部分内容实际上更像是一个管理问题，并且可能对 ServerFault 有用。他发布的链接有很好的信息可供仔细研究。

对于您的Session 问题：您将希望查看会话状态服务（IIS 作为单独的服务提供，用于维护多个服务器之间的共同状态）和/或将 asp.net 会话状态存储在SQL 数据库。我敢肯定，这两个选项都可以在 David Stratton 的链接中找到。

总的来说，一旦您设置了进程外会话状态，它就会变得透明。不过，它确实要求您将 Serializable 对象存储在 Session 中。

---

Round-Robin DNS 是在这种情况下实现负载平衡的最简单方法，是的。它没有考虑每台服务器的实际负载，也没有任何关于何时一台服务器可能停机维护的规定；即使其他四台服务器可能正在运行，任何获得该特定 IP 的人都会将该站点视为“关闭”。

负载平衡和处理 SSL 连接可能都受益于反向代理类型的情况；代理处理所有进入的连接，但它所做的只是加密和平衡 Web 服务器的实际请求负载。 （当然，这些问题更多是在管理方面，但是......）

---

只要所有网络服务器都将自己宣传为同一个网站（通过主机标头等），Cookie 就不会成为问题。每个服务器都会很乐意接受任何其他使用相同域名的服务器设置的 cookie，而无需知道或关心是什么服务器发送的；它基于 Web 浏览器在获取 cookie 值时连接到的服务器的主机名。

【参考方案2】：

这是一个相当广泛的问题，很难在这样的论坛中完全回答。我什至不确定问题是否属于这里，或者是否应该在 serverfault.com 上。不过……

Microsoft 提供了大量有关该主题的指导。 BING 的“缩放 asp.net 应用程序”的第一个结果就是这样。

http://msdn.microsoft.com/en-us/magazine/cc500561.aspx

【讨论】：

+1 以获得良好的链接，并指出该主题的大部分内容确实超出了开发人员的范围。

【参考方案3】：

我只想提出您应该关注数据库的领域。

首先，大多数仅考虑单一数据库服务器的数据模型都需要进行大量更改才能支持多主机模式下的数据库场。

如果您对主键使用自动递增整数（大多数人都这样做），那么您基本上就完蛋了。有几种方法可以暂时缓解这种情况，但即使是那些也需要大量猜测并且很有可能发生碰撞。一种缓解措施涉及将每台服务器上的种子值设置为足够高的数字，以减少发生冲突的可能性……这通常会奏效一段时间。

当然你必须弄清楚如何在服务器之间划分用户......

我的观点是，这个领域不应该掉以轻心，而且几乎总是比简单地通过将数据库服务器“扩大”到更大的硬件上来更难完成。

如果您故意构建具有多主角色的数据模型，请忽略。 ;)

关于会话：不要相信“粘性”会话，粘性不是保证。坦率地说，我们的东西通常部署到服务器场，所以我们从一开始就完全禁用会话状态。一旦你搬到农场，几乎没有理由使用会话状态，因为数据必须在每次页面加载时从状态服务器中检索、反序列化、序列化并存储回状态服务器。

考虑到来自 just 的数据库和网络流量，他们的目的是减少数据库和网络流量，然后你就会明白他们如何不再给你买任何东西了。

【讨论】：

如果你不使用 Session 数据，我强烈推荐一个像 Varnish 这样的缓存服务器，它可以让你以安装额外真实网络服务器的一小部分价格进行大规模扩展。

【参考方案4】：

我看到了一些与循环 http/https 会话相关的问题。我们曾经在进程会话中使用并告诉负载均衡器使会话保持粘性。 （我认为他们为此使用了 cookie）。

它让我们避免了 SQL 会话，但意味着当我们从 http 切换到 https 时，我们的 F5 框无法保持粘性。我们最终改为使用 SQL 会话。

您可以调查将加密推送到负载平衡器。我记得这是解决我们问题的一种可能解决方案，但可惜，我们没有调查过。

【参考方案5】：

只需少量代码和配置更改，即可轻松扩展 SQL 服务器上的会话数据库。您可以将 asp.net 会话粘贴到会话数据库中，并且无论场中的哪个 Web 服务器为请求提供服务，您的基于会话 ID 的 sql 状态服务器映射都可以完美运行。这可能是使用 SQL Server 横向扩展 ASP.NET 会话状态的最佳方法之一。欲了解更多信息，请阅读链接True Scaleout model for session state