如果ASP.NET网站被设计为同时被许多用户（即10,000个用户）访问，那么可以实现的技术，知识，方法，设计或实践是什么？
您能否分享一下设计/实践的名称？我只需要知道这些技术的名称，以便我可以继续在Google进行进一步的研究。
感谢。
答案 0 :(得分：3)
这是一个巨大的话题 - 正如评论所说，没有灵丹妙药。
我会将响应分为两部分：架构和流程。
从架构的角度来看，有许多实践。首先，存在水平扩展 - 即您添加更多服务器，通常由负载均衡器管理。这是一个相对便宜的硬件解决方案，但需要您知道瓶颈在哪里。最简单的横向可扩展性技巧是添加更多Web服务器;水平扩展数据库服务器通常需要使用诸如分片之类的技术来显着复杂化。水平缩放可以提高您的弹性和性能。
垂直可扩展性基本上意味着升级硬件 - 更多RAM，更多CPU，SSD磁盘等。这通常是最便宜的解决方案。它也可能意味着分离溶液的元素 - 例如将Web服务器与数据库服务器分开。
下一个架构解决方案是缓存 - 这本身就是一个很大的话题。添加CDN是很好的第一步;许多CDN提供商还提供“应用程序加速器”选项，有效地添加为反向缓存代理（非常类似于@Aviatrix推荐）。添加自己的反向缓存代理通常可以解决您自己环境中的某些奇怪现象，或者从ASP.Net服务器卸载静态文件服务。
当然，ASP.Net在框架内提供了许多缓存选项 - 确保您阅读并理解它们;他们给予巨大的回报。还要确保通过YSlow之类的工具运行解决方案，以确保设置适当的HTTP缓存标头。
另一种可能有帮助或可能没有帮助的架构解决方案是异步调用外部服务。如果您的解决方案依赖于外部Web服务，则同步调用该服务基本上会将您的站点限制为外部系统的容量和弹性。对于高流量的解决方案，这不是一个好主意。
对于非常高的可扩展性，许多网站使用NoSQL进行持久化 - 这是另一个巨大的主题，并且存在许多复杂的权衡。
从流程的角度来看，如果可扩展性是主要考虑因素，那么您需要将其融入开发流程中。这意味着在整个项目中进行定期的性能和可扩展性评估，并构建一个测量框架，以便您可以决定要采用哪种优化。
您需要能够加载测试解决方案 - 但是在生产流量级别进行负载测试通常在商业上是不现实的，因此您需要找到替代解决方案 - 我经常使用具有代表性基础架构的JMeter。您还需要能够在负载下找到瓶颈 - 这可能需要检测代码，并使用分析器（RedGate做得很好）。
最重要的是要有一个评估权衡的过程 - 几乎所有的性能/可扩展性改进都是以你关心的其他事情为代价的。负载平衡器需要花钱;反向缓存代理解决方案增加复杂性; NoSQL需要开发团队的新技能; “聪明的”编码实践通常会降低可维护性。我建议建立您所需的基线，构建一个测量框架，以根据该基线评估您的解决方案，并进行分析以确定瓶颈。每个提高可扩展性的解决方案都必须解决当前的瓶颈问题，我建议使用概念验证阶段来确保解决方案确实具有预期的影响。
最后，对于现代硬件上的大多数Web应用程序，10000个并发用户数量不是特别大。
答案 1 :(得分：2)
这是我的2c作为正在使用asp.net后端构建可扩展系统的人