提高性能，使 ASP.NET 能够被许多用户访问

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

我将响应分为两个部分：体系结构和过程。

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

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

下一个架构解决方案是缓存 - 这本身就是一个巨大的话题。添加 CDN 是一个很好的第一步;许多 CDN 提供商还提供"应用程序接收器"选项，这些选项有效地添加为反向缓存代理(很像@Aviatrix建议(。添加您自己的反向缓存代理通常是解决您自己环境中某些奇怪问题的解决方案，或者用于卸载从 ASP.Net 服务器提供的静态文件。

当然，ASP.Net 在框架内提供了许多缓存选项 - 确保您阅读并理解它们;它们带来了巨大的收益。此外，请确保通过 YSlow 等工具运行解决方案，以确保设置适当的 HTTP 缓存标头。

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

对于非常高的可扩展性，许多网站使用NoSQL进行持久性 - 这是另一个巨大的话题，并且有许多复杂的权衡。

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

您需要能够对您的解决方案进行负载测试 - 但是在流量的生产级别进行负载测试通常在商业上是不现实的，因此您需要找到替代解决方案 - 我经常将 JMeter 与代表性的基础设施一起使用。您还需要能够在负载下找到瓶颈 - 这可能需要检测您的代码并使用分析器(RedGate 做得很好(。

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

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

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

1. 使用 NGINX 作为反向代理和缓存。很有可能您的用户会请求几乎可以缓存的相同数据，使用它。
2. 使用适当的缓存 HTTP 标头并在服务器和客户端上尽可能多地缓存，请注意，这可能会导致更新内容和用户看到它之间的延迟问题。
3. 拥有大量RAM和SSD的服务器，SSD确实有很大帮助！
4. 使用 NGINX 或其他东西作为负载均衡器，在服务器之间分散负载。