將 Web 應用程序和 Web 伺服器分開的實際好處是什麼？
我們開發和維護網路應用程序；在我們目前的設置中；我們正在使用數據庫伺服器、應用程序伺服器和 Web 伺服器的三層系統。
到現在為止還挺好。
我們面臨的問題是，雖然理論上這個設置旨在幫助我們平衡這些機器之間的負載，並在必要時插入新的分片；實際上，這給我們的後台網路帶來的壓力正在成為一個嚴重的瓶頸。
還有提供靜態文件的問題；由於我們目前的設置；這些必須由應用程序提供服務（佔用我們可用於處理傳入請求的 FastCGI 程序），或者首先使用 Web 伺服器作為執行應用程序的機器上的本地代理。
那麼問題就變成了：
只需將 Web 和應用程序伺服器合二為一；隨著它帶來的配置的簡化；和訪問的直接性（本地套接字而不是 TCP）；以及通過 Web 伺服器提供靜態文件的能力的增強可能會提高性能；還是有我錯過的成本因素？
一般來說，我喜歡分割架構：一個數據庫伺服器群、一個“公共 www”伺服器群（商業網站）和一個應用伺服器群——可能需要其他層的中間件。
這背後的邏輯是舊的——基本上公共 www 伺服器不需要訪問任何敏感數據，所以一些好奇的黑客在 www.mycompany.com 上四處尋找可能會破壞我們的行銷網站，但他們沒有得到還要別的嗎。
這裡有一些其他的一般想法……
回复：後台網路負載，如果我們談論的是聯繫您的 FastCGI 主機的流量負載，我會說在這些機器上放置一個 Web 伺服器並讓它們直接與外界對話可能是個好主意。
要記住的一件事是在發生安全隱患時保持數據庫的隔離/保護，這可能是將您的 FastCGI 內容推送到 Web 伺服器並編寫更輕量級的內容來與您的數據庫對話的一個論據……
（如果我們在談論其他事情，請告訴我，我會嘗試一下 :-)
回复：靜態文件問題，有很多方法可以解決這個問題。
- 在每台需要發送靜態數據的伺服器上放置一份靜態數據。
讓我們稱之為“磁碟便宜”方法——它可以防止您將大量負載傾倒在託管靜態內容的單個盒子上，並消除單點故障。缺點是您必須以某種方式同步該內容（部署腳本、cron’d rsync、cvs/git/svn 等）
- 在你的前端伺服器上安裝一個記憶體基礎設施
這是一個類似於上面“磁碟很便宜”的解決方案，只有你有一個帶有靜態內容的後端伺服器，目前端伺服器需要它時，它們會記憶體一個副本以備不時之需。$LIFETIME，從而消除了對同步腳本的需要（記憶體基礎設施為您完成）。
- 將您的靜態內容放在內容傳遞網路上
這只有在您不使用 SSL 的情況下才有效——商業 CDN 解決了負載問題並為使用者提供了地理分佈點，他們可以從中獲取您的內容。不利的一面是，如果您使用具有 SSL 的站點執行此操作，大多數瀏覽器都會很合適，除非您的 CDN 也受到保護（即使如此偏執的瀏覽器應該正確地抱怨）。