為什麼我們使用 Nginx 而不是 Apache

　　我們大多數的客戶在他們的伺服器上使用apache作為web伺服器，尤其是部署在一個基于php系統的前端并且使用mod-php。鑒于擴張性和性能方面的原因，我們通常會建議他們改用nginx和fpm。

https://dn-linuxcn.qbox.me/data/attachment/album/201303/24/160019nbnlkqb0n0ll0ekm.png

　　apache是非常強大的web伺服器，子產品化結構，也是web服務端的鼻祖。除了捆綁一些其他的工具外，apache已經成為了世上最廣泛部署的開源系統，直到最近，世界上大多數網站仍運作着apache系統。

但是，apache并不是完美的，并且不再适合大規模系統。為什麼？因為他的程序模式雖然簡單而靈活，但并不适合大規模尤其是當要處理像php這種需要占用大量記憶體應用程式代碼時。

　　一個典型的網絡應用伺服器由兩部分組成。用戶端連接配接部分負責使用者浏覽器與http連接配接，保持長時間的tcp/ip協定，通常是1到2分鐘。對于一個大型的系統，伺服器可能要同時承擔和處理數以萬計的并發連接配接。

　　這直接與apache隻有500條程序即500個http連接配接的處理能力上限相沖突。而現今的浏覽器讓這個問題更加嚴重, 因為現在的浏覽器平均每個主機會打開六個網站連結（幾年前是兩個網站連結）。是以當超過100個使用者同時通路時，apache就已經滿負荷了。

　　第二部分是應用程式處理部分，這部分承擔了代碼運算。在大多數系統中，這部分工作是最消耗ram和cpu資源的，是以程序數量必須被嚴格限制，通常 是大約每 1gb的記憶體10個程序，或者每個cpu核心兩個程序。是以一台4gb ram、16核心的伺服器最多隻能運作32個應用程式程序。

　　但是，問題的關鍵是，apache直接連接配接前端用戶端通訊元件與後端應用程式程序元件。如此一來，前端部分往往保持長時間的連接配接，常常達到幾分鐘， 這導緻後端部分将持續消耗記憶體和cpu資源。目前還沒有直接的方法能夠在大型系統中找到前後端服務的平衡，是以他們必須被分離開來。

　　目前有兩個主要的解決方法。第一個方法，也是現有系統上最容易的方法，就是在apache前端安裝負載均衡伺服器或者nginx來處理用戶端連接配接部 分。負載均衡伺服器，像 haproxy或者nginx能輕松處理成千上萬條并發的連接配接，并使apache能夠真正的僅作為後端應用程式工作，來處理32個或是更多的程序。

　　第二種方案，也是最通用的辦法就是用nginx替換apache，同時使用php-pfm作為應用伺服器。就像之前所提到的，這将分割前端用戶端通信部分和後端應用程式部分。nginx處理http通訊協定，同時fpm處理後端應用程式部分，和那32個程序進行互動。

　　然而這幾種方法仍然還存在一些問題，主要是如何加載伺服器的rpc調用，以及如何釋放已經完成的rpc調用。 這兩個問題都會在後繼的部落格中加以詳解。

　　另外，隻使用nginx的解決方法會給那些嚴重依賴于apache功能的應用程式帶來問題，尤其是特别依賴rewrite rules, .htaccess, 或者mod_security等一些可選元件的應用程式。在這種情況下，在apache前端增加安裝nginx是最好的方法。

　　通常來說，所有新的系統都應該使用nginx和php-fpm來部署。這能提供高性能增長特性，并且是平衡使用者和記憶體，cpu資源的最佳選擇。已存在的系統可以在前端使用nginx或者haproxy以達到同樣的效果，以便在當今現代網絡環境中為使用者提供更優質的服務。

<b> 原文釋出時間為：2013-03-25</b>

<b>本文來自雲栖社群合作夥伴“linux中國”</b>