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