Nginx 的産生
Nginx 同 Apache 一樣都是一種 Web 伺服器。基于 REST 架構風格，以統一資源描述符（Uniform Resources Identifier）URI 或者統一資源定位符（Uniform Resources Locator）URL 作為溝通依據，通過 HTTP 協定提供各種網絡服務。
然而，這些伺服器在設計之初受到當時環境的局限，例如當時的使用者規模，網絡帶寬，産品特點等局限并且各自的定位和發展都不盡相同。這也使得各個 Web 伺服器有着各自鮮明的特點。
Apache 的發展時期很長，而且是毫無争議的世界第一大伺服器。它有着很多優點：穩定、開源、跨平台等等。
它出現的時間太長了，它興起的年代，網際網路産業遠遠比不上現在。是以它被設計為一個重量級的。
它不支援高并發的伺服器。在 Apache 上運作數以萬計的并發通路，會導緻伺服器消耗大量記憶體。
作業系統對其進行程序或線程間的切換也消耗了大量的 CPU 資源，導緻 HTTP 請求的平均響應速度降低。
這些都決定了 Apache 不可能成為高性能 Web 伺服器，輕量級高并發伺服器 Nginx 就應運而生了。
俄羅斯的工程師 Igor Sysoev，他在為 Rambler Media 工作期間，使用 C 語言開發了 Nginx。
Nginx 作為 Web 伺服器一直為 Rambler Media 提供出色而又穩定的服務。然後呢，Igor Sysoev 将 Nginx 代碼開源，并且賦予自由軟體許可證。
由于以下這幾點，是以，Nginx 火了：
Nginx 使用基于事件驅動架構，使得其可以支援數以百萬級别的 TCP 連接配接。高度的子產品化和自由軟體許可證使得第三方子產品層出不窮（這是個開源的時代啊）。Nginx 是一個跨平台伺服器，可以運作在 Linux、Windows、FreeBSD、Solaris、AIX、Mac OS 等作業系統上。這些優秀的設計帶來的極大的穩定性。
Nginx 的用武之地
Nginx 是一款自由的、開源的、高性能的 HTTP 伺服器和反向代理伺服器；同時也是一個 IMAP、POP3、SMTP 代理伺服器。
Nginx 可以作為一個 HTTP 伺服器進行網站的釋出處理，另外 Nginx 可以作為反向代理進行負載均衡的實作。
關于代理
說到代理，首先我們要明确一個概念，所謂代理就是一個代表、一個管道；此時就涉及到兩個角色，一個是被代理角色，一個是目标角色。
被代理角色通過這個代理通路目标角色完成一些任務的過程稱為代理操作過程；如同生活中的專賣店，客人到 adidas 專賣店買了一雙鞋，這個專賣店就是代理，被代理角色就是 adidas 廠家，目标角色就是使用者。
正向代理
說反向代理之前，我們先看看正向代理，正向代理也是大家最常接觸到的代理模式，我們會從兩個方面來說關于正向代理的處理模式，分别從軟體方面和生活方面來解釋一下什麼叫正向代理。
在如今的網絡環境下，我們如果由于技術需要要去通路國外的某些網站，此時你會發現位于國外的某網站我們通過浏覽器是沒有辦法通路的。
此時大家可能都會用一個操作 FQ 進行通路，FQ 的方式主要是找到一個可以通路國外網站的代理伺服器，我們将請求發送給代理伺服器，代理伺服器去通路國外的網站，然後将通路到的資料傳遞給我們！
上述這樣的代理模式稱為正向代理，正向代理最大的特點是用戶端非常明确要通路的伺服器位址；伺服器隻清楚請求來自哪個代理伺服器，而不清楚來自哪個具體的用戶端；正向代理模式屏蔽或者隐藏了真實用戶端資訊。來看個示意圖：
用戶端必須設定正向代理伺服器，當然前提是要知道正向代理伺服器的 IP 位址，還有代理程式的端口。
如下圖：
總結來說：正向代理，"它代理的是用戶端"，是一個位于用戶端和原始伺服器（Origin Server）之間的伺服器，為了從原始伺服器取得内容，用戶端向代理發送一個請求并指定目标（原始伺服器）。
然後代理向原始伺服器轉交請求并将獲得的内容傳回給用戶端。用戶端必須要進行一些特别的設定才能使用正向代理。
正向代理的用途：
通路原來無法通路的資源，如 Google。可以做緩存，加速通路資源。對用戶端通路授權，上網進行認證。代理可以記錄使用者通路記錄（上網行為管理），對外隐藏使用者資訊。
反向代理
明白了什麼是正向代理，我們繼續看關于反向代理的處理方式，舉例如某個網站，每天同時連接配接到網站的通路人數已經爆表，單個伺服器遠遠不能滿足人民日益增長的通路。
此時就出現了一個大家耳熟能詳的名詞：分布式部署；也就是通過部署多台伺服器來解決通路人數限制的問題。
網站中大部分功能也是直接使用 Nginx 進行反向代理實作的，并且通過封裝 Nginx 和其他的元件之後起了個高大上的名字：Tengine。
那麼反向代理具體是通過什麼樣的方式實作的分布式的叢集操作呢，我們先看一個示意圖：
通過上述的圖解大家就可以看清楚了，多個用戶端給伺服器發送的請求，Nginx 伺服器接收到之後，按照一定的規則分發給了後端的業務處理伺服器進行處理了。
此時請求的來源也就是用戶端是明确的，但是請求具體由哪台伺服器處理的并不明确了，Nginx 扮演的就是一個反向代理角色。
用戶端是無感覺代理的存在的，反向代理對外都是透明的，通路者并不知道自己通路的是一個代理。因為用戶端不需要任何配置就可以通路。
反向代理，"它代理的是服務端"，主要用于伺服器叢集分布式部署的情況下，反向代理隐藏了伺服器的資訊
反向代理的作用：
保證内網的安全，通常将反向代理作為公網通路位址，Web 伺服器是内網。負載均衡，通過反向代理伺服器來優化網站的負載。
項目場景
通常情況下，我們在實際項目操作時，正向代理和反向代理很有可能會存在同一個應用場景中，正向代理代理用戶端的請求去通路目标伺服器，目标伺服器是一個反向單利伺服器，反向代理了多台真實的業務處理伺服器。
具體的拓撲圖如下：
截了一張圖來說明正向代理和反向代理二者之間的差別，如下圖：
圖解：
在正向代理中，Proxy 和 Client 同屬于一個 LAN（圖中方框内），隐藏了用戶端資訊。在反向代理中，Proxy 和 Server 同屬于一個 LAN（圖中方框内），隐藏了服務端資訊。
實際上，Proxy 在兩種代理中做的事情都是替伺服器代為收發請求和響應，不過從結構上看正好左右互換了一下，是以把後出現的那種代理方式稱為反向代理了。
負載均衡
我們已經明确了所謂代理伺服器的概念，那麼接下來，Nginx 扮演了反向代理伺服器的角色，它是依據什麼樣的規則進行請求分發的呢？不用的項目應用場景，分發的規則是否可以控制呢？
這裡提到的用戶端發送的、Nginx 反向代理伺服器接收到的請求數量，就是我們說的負載量。請求數量按照一定的規則進行分發，到不同的伺服器處理的規則，就是一種均衡規則。
是以将伺服器接收到的請求按照規則分發的過程，稱為負載均衡。
負載均衡在實際項目操作過程中，有硬體負載均衡和軟體負載均衡兩種，硬體負載均衡也稱為硬負載，如 F5 負載均衡，相對造價昂貴成本較高。
但是資料的穩定性安全性等等有非常好的保障，如中國移動中國聯通這樣的公司才會選擇硬負載進行操作。
更多的公司考慮到成本原因，會選擇使用軟體負載均衡，軟體負載均衡是利用現有的技術結合主機硬體實作的一種消息隊列分發機制。
Nginx 支援的負載均衡排程算法方式如下：
①weight 輪詢（預設）：接收到的請求按照順序逐一配置設定到不同的後端伺服器，即使在使用過程中，某一台後端伺服器當機，Nginx 會自動将該伺服器剔除出隊列，請求受理情況不會受到任何影響。
這種方式下，可以給不同的後端伺服器設定一個權重值（weight），用于調整不同的伺服器上請求的配置設定率。
權重資料越大，被配置設定到請求的幾率越大；該權重值，主要是針對實際工作環境中不同的後端伺服器硬體配置進行調整的。
②ip_hash：每個請求按照發起用戶端的 ip 的 hash 結果進行比對，這樣的算法下一個固定 ip 位址的用戶端總會通路到同一個後端伺服器，這也在一定程度上解決了叢集部署環境下 Session 共享的問題。
③fair：智能調整排程算法，動态的根據後端伺服器的請求處理到響應的時間進行均衡配置設定。
響應時間短處理效率高的伺服器配置設定到請求的機率高，響應時間長處理效率低的伺服器配置設定到的請求少，它是結合了前兩者的優點的一種排程算法。
但是需要注意的是 Nginx 預設不支援 fair 算法，如果要使用這種排程算法，請安裝 upstream_fair 子產品。
④url_hash：按照通路的 URL 的 hash 結果配置設定請求，每個請求的 URL 會指向後端固定的某個伺服器，可以在 Nginx 作為靜态伺服器的情況下提高緩存效率。
同樣要注意 Nginx 預設不支援這種排程算法，要使用的話需要安裝 Nginx 的 hash 軟體包。