Nginx現在是網際網路上應用廣泛的伺服器軟體，從市場使用量上僅次於Apache。它的主要特點就是效能極高，能充分發掘一臺伺服器的效能。相比較而言，Apache就顯得太笨太重了。所以主流的網際網路（指使用者量比較大的網際網路公司）都使用Nginx伺服器作為反向代理。

Nginx作為反向代理為什麼能夠提供網站效能，因為它不僅僅提供反向代理的功能，還有負載均衡的功能，如下圖所示。每個請求過來之後，Nginx作為負載均衡，都會將請求轉發給後端的任意伺服器。（方法有很多，比如輪流，session一致等原則）

所以與其說Nginx能提高網站效能，我覺得是不準確的。應該說，可以隨著業務的房展，可以動態的擴充套件伺服器，這個我認為是非常重要的，能夠穩定的保證線上業務的發展。

咋一看，反向代理增加了中間過程，理論上說只會降低網站效能，怎麼會提高效能呢？最主要的原因是這種方式會降低後端應用伺服器的網路連線時間，進而提升效率。如果網際網路使用者的直接請求應用伺服器，網路連線時間會大大增加，會導致資源不能及時釋放，進而降低效能。在反向代理模式下，應用伺服器透過內網與nginx連線，網路效能和穩定性極高，可以及時釋放資源進行後續處理，效能自然提高，而網路連線交給更擅長處理這個問題的nginx。

反向代理的方式主要是為了緩解繁忙伺服器的負擔，將Cache部署在伺服器前面，將自己的內容與伺服器保持同步，當收到使用者的請求時，直接用Cache中的內容進行回覆，從而減輕網路伺服器的負擔。

反向代理裝置提高了前端Web伺服器處理客戶連線的能力，為電子商務、後臺生成的HTML新聞公佈、軟體下載等提供了快速的服務。這種部署方式經常用於靜態Web內容佔很大比例的環境中。大型ISP 為了加速網路的響應都會架設大量的前置高速緩衝伺服器（forward proxy cache server），但是，對於無法識別內容的快取叢集來說，所有的快取伺服器節點都必須儲存整個被訪網路的全部內容（理論上，所有的網路中的站點都被快取過）。

顯然，快取伺服器的儲存能力無法滿足這一點要求，勢必導致大量的頁面無法被及時快取而進行快取更新，使用者訪問網路的速度反而變慢。為了解決這一問題，必須利用到面向URL內容的叢集排程技術，可以設定每一臺叢集節點負責部分URL的緩衝請求的任務，由於每個節點所快取的內容完全不同，叢集整體構成一個大的內容超集，提高了總體儲存能力。在Cache叢集緩衝命中率的提高的前提下，也大大降低了使用者請求的頁面出現缺失的情況，改善了叢集的吞吐能力和效能。

反向代理負載均衡能以軟體方式來實現，如Apache mod_proxy、ISA proxy等，也可以在快取記憶體器、負載均衡器等硬體裝置上實現，例如硬體解決方案：基於軟體技術的反向代理負載均衡可以將最佳化的負載均衡策略和代理伺服器的快取記憶體技術結合在一起，提升靜態網頁的訪問速度，提供有益的效能。

由於網路外部使用者不能直接訪問真實的伺服器，同時也就具備額外的安全性。其缺點主要表現為反向代理是工作在OSI參考模型第七層（應用層），所以就必須為每一種應用服務專門開發一個反向代理伺服器。以硬體技術為主的解決方案多數將各種應用平臺整合到一臺或多臺裝置中，在功能強大的同時價格也相對較高。以思科提供的Cisco快取方案為例，WCCP（Web快取通訊協議）是構成快取方案的核心，WCCP 2被承載與Cisco Cache Engine 500系列之上。

大哥，這個問題問錯了吧？？？

反向代理只是一種中介模式，區別於nginx之前的以內網連結網路這樣的正向代理，可以讓內部區域網透過http訪問網路資源的中介模式！

反向代理是透過nginx作為中介，為別的網路訪問內網提供一道隔離層和中間層，這樣的模式稱為反向代理！

OK，既然只是做箇中間層，如果在業務應用只有一臺的情況下，肯定不會提高網站效能，相反因為多走一層，所以效能下降，訪問時間變長！

但如果是業務應用伺服器一臺明顯滿足不了業務量訪問的暴增，透過nginx連線多臺業務伺服器，實現一個負載均衡的業務叢集，再透過一定的均衡方式則能避免單臺應用伺服器的過載，換句話說，提高整個業務系統的對外效能！

那麼題目可以改成，為什麼負載均衡能提升網站效能？我們舉例來看:

比如單臺應用伺服器的記憶體為8g，每次請求的請求資料為1m，因為每次需要調動系統資源，系統執行緒等，分配給jvm可能只有6g，jvm本身也有排程執行緒，系統程序等，業務的處理記憶體只有5g，也就是說單機的最大處理能力為5000m/1，也就是5000個請求，一旦請求量變大或者請求數增多，可能導致業務伺服器的崩潰，整個業務系統處於零處理狀態！

這個時候如果使用nginx作為負載均衡連線4-6臺伺服器，可以顯著的提高併發能力為20000-30000，效能極具提升，同時穩定性增強！

那麼nginx工作原理又是什麼呢？

nginx透過一個master程序排程多個worker，根據配置的不同均衡策略，非同步非阻塞得將請求放到不同的業務系統進行處理！

負載均衡方式大概會有幾種:

1，輪詢模式:每個業務伺服器收到的請求數一樣，除非宕機了！

2，權重模式:按照配置權重，分配不同的請求數！

3，最小響應時間:根據不同的應用伺服器返回響應的時間進行分發，比如三臺業務伺服器中，某臺記憶體更高，cpu各種更多，處理能力更強！

4，隨機分發:隨機的將請求分發到不同的伺服器上！

5，按照hash值:根據不同的hash值，進行分發！

如何實現最簡單的nginx均衡？

1，使用upsream server配置nginx和應用伺服器之間的聯絡！

2，使用server模組對外採用同樣的域名！

除了負載均衡，nginx還提供了靜態頁面快取等功能提升伺服器的效能！nginx作為穩定，安全的反向代理伺服器，擁有著最高50000的併發能力，是大多數公司實現均衡的不二之選！

從能夠提高網站效能這點來說，當然是由於Nginx反向代理與負載均衡的超強優勢啦。

反向代理可以用於實現分散式，即對外雖然是一個完整的服務，但是其實這個服務對內是由部署在多臺Tomcat的子服務共同組成的。

舉個例子，一個購物網站，分為查詢商品，下單，結算三個模組（極簡舉例），如果這三個子服務都寫在同一個Tomcat上，那麼所有的請求就都會發給這一臺Tomcat。

這樣的部署有一個隱患：假設雙十一之前，這個網站的壓測沒有做好，導致雙十一當天0點的時候，結算的人太多，qps超過Tomcat可承受的上限，服務崩潰了，那麼這時候，不僅是結算的人無法開啟網頁，連那些想查詢商品，把商品放入購物車的使用者也會發現打不開網頁了。即此時這個網站的服務由於單個子服務的原因，全線崩潰了。

如果使用反向代理功能，就能從兩個方面來緩解這個隱患：

1 Nginx會將查詢，下單與結算的請求分別傳送給三個伺服器，那麼對於單獨的伺服器來說，瞬時間的請求量就會少很多，減少了掛掉的風險

2 就算掛掉了，由於Tomcat是分開的，掛掉其中一個，另外兩個依然可以執行，不影響使用者其他操作。

因此，我們說，反向代理也是一種提升網站效能的方式。

只不過，這裡的網站指的其實是使用者側感知到的整體的服務，而不是具體的Tomcat server。

題主這個問題的想法應該是覺得加上反向代理後請求路徑會加上，因此請求的處理時間會增加，效能會有下降。

如果從單個請求來說，的確如此，但僅僅有幾毫秒的影響，對於普通的人來說幾乎無法感知到。從另外一方面說，一個網站不能僅僅考慮單個請求的處理情況，而應該從整體上進行考慮。

Nginx做反向代理最為重要的一點是負載均衡。也就是將客戶端的請求負載均衡到後端的若干臺伺服器上。如下圖所示，一個Web網站實際業務伺服器的數量可能是3臺，或者更多，讓後透過一個反向代理作為出口。

為什麼要做負載均衡，我們從如下幾方面分析一下：

1. 負載型別，我們知道對於一個網站，負載包括CPU負載、磁碟負載和網路負載等內容，以CPU負載為例，網站的動態指令碼需要進行執行解析，生成最後的頁面。一臺伺服器計算能力有限，因此，必然需要多臺伺服器形成叢集，提高整體的計算能力。

2. 系統高可用，伺服器故障在所難免，即使在一臺伺服器能夠勝任工作，但有可能存在任何故障，比如極端的宕機，或者網絡卡故障和硬碟故障等。如果伺服器由於某些故障導致反應極慢，這樣網站就會變得很慢。但如果有反向代理，並且有故障診斷，這樣就可以讓正常的伺服器處理請求，對使用者來說，就是效能提升。

因此，即使在不做快取和靜態檔案的情況下，雖然請求路徑加長了，單個請求的耗時可能會增加，但從整體上來說，還是會很大的提升網站的效能。

NGINX當反向代理，只是能把請求先收下來，再排隊到後端業務，但如果後端業務的處理能力低於使用者請求量，那其實沒啥用。

就像後端處理的的水管太小，你不管換多好的閥門，都不能加快的，只能算是有個保護，不至於把後端水管壓爆了。

其實這個問題是不嚴謹的，首先我們需要明確兩點：

1）很多Web伺服器或容器都可以實現反向代理；

2）反向代理和網站效能的提升沒有必然關係！

為什麼現在很多人認為用Nginx這類Web伺服器做個反向代理就能提高網站效能了呢？其實，反向代理和網站效能並沒有必然關係，有時候用反向代理的確可以提高網站效能；但如果反向代理使用不當，反而會降低網站效能。

之所以很多人誤認為反向代理能提升網站效能，究其原因是因為現在很多大型網際網路平臺架構都會採用反向代理這種模式，而且很多技術類書籍文章也會提到反向代理，所以造成了大家的這種誤解。

反向代理是相對於正相代理而言的，它是作用於伺服器商的。

在沒有使用代理之前，客戶端向服務端請求時，簡單而言就是：客戶端 => 服務端。

反向代理最終解決的問題是：隱藏了真實的服務端！而正向代理則是為了隱藏真實的客戶端。

對於中大型網站架構，反向代理都是配合負載均衡來使用的，這樣才能提升網站效能。多個後端服務叢集統一由反向代理伺服器進行請求分發，這樣就避免了單臺伺服器的效能瓶頸影響整個平臺的穩定。