所以我在听最新的Stackoverflow播客（第19集），Jeff和Joel谈到了随着网站的发展而扩展服务器硬件的问题。根据Joel的说法，前几个步骤非常标准：
不过，他们并没有谈论接下来会发生什么。您是否添加了更多的Web服务器？另一个数据库服务器？将这三台机器的集群复制到不同的数据中心以实现冗余？在硬件部门，一家网络初创公司将何去何从？
支持“普通”web应用程序的合理设置可能会发展如下：
在这一点上，评估当前的事态将有助于确定更好的扩展路径。例如，如果读取负载很高，并且内容不会经常更改，那么最好强调缓存并引入专用的前端缓存，例如Squid以避免不需要的数据库读取，尽管您需要考虑如何维护缓存一致性，通常在应用程序中。
另一方面，如果内容经常发生变化，那么您可能更喜欢更分散的解决方案；引入更多的应用程序服务器和数据库从属服务器来帮助减轻影响，并使用对象缓存，如memcached以避免因不太稳定的内容而影响数据库。
对于大多数网站来说，这可能已经足够了，尽管如果你真的成为了一种全球现象，那么你可能会开始考虑在区域数据中心安装硬件，并使用地理负载平衡等技巧将访问者引导到最近的“集群”。到那时，你可能会雇佣到能够对事情进行微调的工程师。
我能想到的最有价值的扩展建议可能是避免过早地担心这一切；专注于开发人们想要使用的服务，并使应用程序合理地健壮。一些简单的早期优化是为了确保你的数据库设计相当可靠，并设置索引，这样你就不会做任何令人痛苦的疯狂事情；此外，请确保应用程序发出缓存控制头，指导浏览器如何缓存数据。在设计的早期做这类工作可以在以后产生好处，尤其是当您不必为了处理缓存一致性问题而返工时。
我想传达的第二条最有价值的建议是，你不应该认为对其他网站有效的东西会对你有效；检查日志，对流量进行一些分析，并对应用程序进行配置——查看瓶颈所在并解决它们。
Joel提到添加第二个数据中心，使用相同的设置，然后将用户随机分配给每个数据中心。对数据的更改会被记录下来，并从一个位置发送到另一个位置，这样两个位置都包含所有数据。
话题可扩展Web架构常见模式&；Cal Henderson（雅虎）在Web 2.0博览会上的做法非常有趣。我以为有视频，但找不到。但下面是幻灯片：
http://www.slideshare.net/techdude/scalable-web-architectures-common-patterns-and-approaches
下一步将是建立一个网络服务器集群（网络场）和一个数据库服务器集群系统（复制或Oracle RAC等）
如果您对缓存和使用.Net感兴趣，请查看企业库中的应用程序缓存块（当然，将其与上面的其他点一起使用）。
