所以我正在收聽最新的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企業庫（當然一起使用與上面的其他點）。