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