1

如果一个 ASP.NET 网站被设计成可供多个用户（即 10,000 个用户）同时访问，那么可以实施哪些技术、知识、方法、设计或实践？

你能分享设计/实践的名称吗？我只需要知道这些技术的名称，这样我就可以继续在谷歌做进一步的研究。

谢谢。

4

2 回答 2

3

这是一个巨大的话题——正如评论所说，没有灵丹妙药。

我会将响应分为两部分：架构和流程。

从架构的角度来看，有许多实践。首先，存在水平扩展——即添加更多服务器，通常由负载均衡器管理。这是一个相对便宜的硬件解决方案，但需要您知道瓶颈在哪里。最简单的横向扩展技巧是添加更多的 Web 服务器；使用分片等技术水平扩展数据库服务器通常需要非常复杂的操作。水平扩展可以提高您的弹性和性能。

垂直可扩展性基本上意味着升级硬件 - 更多 RAM、更多 CPU、SSD 磁盘等。这通常是最便宜的解决方案。这也可能意味着分离解决方案的元素——例如，将 Web 服务器与数据库服务器分离。

下一个架构解决方案是缓存——这本身就是一个巨大的话题。添加 CDN 是很好的第一步；许多 CDN 提供商还提供“应用程序加速器”选项，可以有效地添加为反向缓存代理（很像 @Aviatrix 推荐的）。添加您自己的反向缓存代理通常是解决您自己环境中的一些怪异问题或从您的 ASP.Net 服务器卸载静态文件服务的解决方案。

当然，ASP.Net 在框架内提供了许多缓存选项——确保您阅读并理解它们；他们付出了巨大的代价。还要确保您通过 YSlow 之类的工具运行您的解决方案，以确保您设置了适当的 HTTP 缓存标头。

另一个可能有帮助也可能没有帮助的架构解决方案是异步调用外部服务。如果您的解决方案依赖于外部 Web 服务，那么同步调用该服务基本上会将您的站点限制为外部系统的容量和弹性。对于高流量的解决方案，这不是一个好主意。

为了非常高的可扩展性，许多网站使用 NoSQL 来实现持久性——这是另一个巨大的话题，并且有许多复杂的权衡取舍。

从流程的角度来看，如果可伸缩性是主要关注点，您需要将其纳入您的开发流程。这意味着在整个项目中定期进行性能和可扩展性评估，并构建一个测量框架，以便您可以决定要进行哪些优化。

您需要能够对您的解决方案进行负载测试 - 但在生产流量级别进行负载测试通常在商业上不切实际，因此您需要找到替代解决方案 - 我经常使用具有代表性基础架构的 JMeter。您还需要能够找到负载下的瓶颈——这可能需要检测您的代码并使用分析器（RedGate 做得很好）。

最重要的是有一个评估权衡的过程——几乎每一次性能/可扩展性的改进都是以牺牲你关心的其他一些事情为代价的。负载均衡器要花钱；反向缓存代理解决方案增加了复杂性；NoSQL 需要开发团队的新技能；“聪明”的编码实践通常会降低可维护性。我建议建立你所需的基线，建立一个测量框架来根据该基线评估你的解决方案，并进行分析以确定瓶颈。每个提高可扩展性的解决方案都必须解决当前的瓶颈，我建议进行概念验证阶段，以确保解决方案确实具有预期的影响。

最后，对于现代硬件上的大多数 Web 应用程序来说，10000 个并发用户并不是一个特别大的数字。

于 2013-10-01T09:21:23.410 回答
2

这是我的 2c 作为目前正在使用 asp.net 后端构建可扩展系统的人

  1. 使用 NGINX 作为反向代理和缓存。很可能您的用户将请求大部分可以缓存的相同数据，使用它。
  2. 在服务器和客户端上尽可能多地使用适当的缓存 http 标头和缓存，但要小心，这可能会导致更新某些内容和用户看到它之间的延迟问题。
  3. 有很多内存和固态硬盘的服务器，固态硬盘确实有很大帮助！
  4. 使用 NGINX 或其他东西作为负载均衡器来分散服务器之间的负载。
于 2013-10-01T08:09:14.833 回答