目前我有一台运行ASP.net 网络应用程序（在 IIS 上），并且还运行SQL Server 数据库。
我的流量越来越多，很快我就需要增加我可以处理的流量，这样用户体验才不会受到影响。我说的不是谷歌或亚马逊类型的流量。
我的问题是，什么是真实的网络和服务器布局为我提供更好的表现和大我一个合理的冗余而不需要支付巨额的金钱。
我希望将停机时间控制在合理的最短时间内，但并不期望始终有 100% 可用的解决方案。
我正在考虑类似防火墙、负载均衡器、两台运行 IIS 的 Web 服务器和一台具有合理规格的 SQL 服务器（可能是具有 16GB 或更大内存的 Dell R710），以及可能还有一台可以集群到另一台 SQL 服务器。
我希望系统能够以这样的方式扩展：如果在一两年内我们的流量急剧增加，我们可以添加额外的服务器来满足增加的流量，而不必重建整个系统。
任何能给我指明正确方向的建议或链接都是很好的。
注意：我浏览过 highscalability.com，但大多数案例研究和文章都涉及大型网站，如 StackOverflow、Amazon 和其他流量巨大的超级网站。我还没有遇到这种情况。
答案1
这种架构遇到的经典问题是，Web 服务器很容易扩展，而数据库则更容易扩展。
您的建议是一个很好的开始。我也有过类似的经历，我现在的情况是：
- 2x IIS 7.5 网络服务器，具有共享 IIS 配置和 DFS-R 复制网络内容目录。
- MSCS 集群中的 2x SQL 2008 R2 数据库
- 2 个 AD / DNS 服务器来支持集群
- Web 服务器前面有 2 个 HaProxy 负载均衡器
显然，如果您不太关心可用性，那么可以不使用 AD 而使用单个 SQL 服务器。
当 SQL 成为瓶颈时，我将（在消除应用程序中的问题后）为 SQL 服务器购买更大的硬件。当 IIS 成为瓶颈时，我只需购买更多 IIS 盒并将它们投入使用即可。应用程序在后端有几个大型数据库盒，前端有大量 Web 服务器，这种情况并不罕见。
另一个主要问题是许可成本。在许多情况下，硬件成本变得无关紧要，因为运行它所需的软件许可证变得更大。要集群 SQL 服务器，我相信您需要 SQL Server Enterprise 和 Windows Enterprise Edition - 这些比标准版贵得多。
最终，你必须决定你更关心什么：低成本、性能还是可用性。根据我的经验，可用性是非常昂贵的。