Nginx的產(chǎn)生
沒有聽過Nginx?那么一定聽過它的"同行"Apache吧!Nginx同Apache一樣都是一種WEB服務器。基于REST架構風格，以統(tǒng)一資源描述符(Uniform Resources Identifier)URI或者統(tǒng)一資源定位符(Uniform Resources Locator)URL作為溝通依據(jù)，通過HTTP協(xié)議提供各種網(wǎng)絡服務。
然而，這些服務器在設計之初受到當時環(huán)境的局限，例如當時的用戶規(guī)模，網(wǎng)絡帶寬，產(chǎn)品特點等局限并且各自的定位和發(fā)展都不盡相同。這也使得各個WEB服務器有著各自鮮明的特點。
Apache的發(fā)展時期很長，而且是毫無爭議的世界第一大服務器。它有著很多優(yōu)點：穩(wěn)定、開源、跨平臺等等。它出現(xiàn)的時間太長了，它興起的年代，互聯(lián)網(wǎng)產(chǎn)業(yè)遠遠比不上現(xiàn)在。所以它被設計為一個重量級的。它不支持高并發(fā)的服務器。在Apache上運行數(shù)以萬計的并發(fā)訪問，會導致服務器消耗大量內(nèi)存。操作系統(tǒng)對其進行進程或線程間的切換也消耗了大量的CPU資源，導致HTTP請求的平均響應速度降低。
這些都決定了Apache不可能成為高性能WEB服務器，輕量級高并發(fā)服務器Nginx就應運而生了。
俄羅斯的工程師Igor Sysoev，他在為Rambler Media工作期間，使用C語言開發(fā)了Nginx。Nginx作為WEB服務器一直為Rambler Media提供出色而又穩(wěn)定的服務。
然后呢，Igor Sysoev將Nginx代碼開源，并且賦予自由軟件許可證。
由于：
Nginx使用基于事件驅(qū)動架構，使得其可以支持數(shù)以百萬級別的TCP連接
高度的模塊化和自由軟件許可證是的第三方模塊層出不窮(這是個開源的時代啊~)
Nginx是一個跨平臺服務器，可以運行在Linux,Windows,FreeBSD,Solaris, AIX,Mac OS等操作系統(tǒng)上
這些優(yōu)秀的設計帶來的極大的穩(wěn)定性
所以，Nginx火了!
Nginx的用武之地
Nginx是一款自由的、開源的、高性能的HTTP服務器和反向代理服務器;同時也是一個IMAP、POP3、SMTP代理服務器;Nginx可以作為一個HTTP服務器進行網(wǎng)站的發(fā)布處理，另外Nginx可以作為反向代理進行負載均衡的實現(xiàn)。
關于代理
說到代理，首先我們要明確一個概念，所謂代理就是一個代表、一個渠道;
此時就設計到兩個角色，一個是被代理角色，一個是目標角色，被代理角色通過這個代理訪問目標角色完成一些任務的過程稱為代理操作過程;如同生活中的專賣店~客人到adidas專賣店買了一雙鞋，這個專賣店就是代理，被代理角色就是adidas廠家，目標角色就是用戶。
正向代理
說反向代理之前，我們先看看正向代理，正向代理也是大家最常接觸的到的代理模式，我們會從兩個方面來說關于正向代理的處理模式，分別從軟件方面和生活方面來解釋一下什么叫正向代理。
在如今的網(wǎng)絡環(huán)境下，我們?nèi)绻捎诩夹g需要要去訪問國外的某些網(wǎng)站，此時你會發(fā)現(xiàn)位于國外的某網(wǎng)站我們通過瀏覽器是沒有辦法訪問的，此時大家可能都會用一個操作FQ進行訪問，F(xiàn)Q的方式主要是找到一個可以訪問國外網(wǎng)站的代理服務器，我們將請求發(fā)送給代理服務器，代理服務器去訪問國外的網(wǎng)站，然后將訪問到的數(shù)據(jù)傳遞給我們!
上述這樣的代理模式稱為正向代理，正向代理最大的特點是客戶端非常明確要訪問的服務器地址;服務器只清楚請求來自哪個代理服務器，而不清楚來自哪個具體的客戶端;正向代理模式屏蔽或者隱藏了真實客戶端信息。來看個示意圖(我把客戶端和正向代理框在一塊，同屬于一個環(huán)境，后面我有介紹)：
客戶端必須設置正向代理服務器，當然前提是要知道正向代理服務器的IP地址，還有代理程序的端口。如圖。
總結來說：正向代理，"它代理的是客戶端"，是一個位于客戶端和原始服務器(origin server)之間的服務器，為了從原始服務器取得內(nèi)容，客戶端向代理發(fā)送一個請求并指定目標(原始服務器)，然后代理向原始服務器轉交請求并將獲得的內(nèi)容返回給客戶端。客戶端必須要進行一些特別的設置才能使用正向代理。
正向代理的用途：
訪問原來無法訪問的資源，如Google
可以做緩存，加速訪問資源
對客戶端訪問授權，上網(wǎng)進行認證
代理可以記錄用戶訪問記錄(上網(wǎng)行為管理)，對外隱藏用戶信息
反向代理
明白了什么是正向代理，我們繼續(xù)看關于反向代理的處理方式，舉例如我大天朝的某寶網(wǎng)站，每天同時連接到網(wǎng)站的訪問人數(shù)已經(jīng)爆表，單個服務器遠遠不能滿足人民日益增長的購買欲望了，此時就出現(xiàn)了一個大家耳熟能詳?shù)拿~：分布式部署;
也就是通過部署多臺服務器來解決訪問人數(shù)限制的問題;某寶網(wǎng)站中大部分功能也是直接使用Nginx進行反向代理實現(xiàn)的，并且通過封裝Nginx和其他的組件之后起了個高大上的名字：Tengine。
有興趣的童鞋可以訪問Tengine的官網(wǎng)查看具體的信息：http://tengine.taobao.org/。那么反向代理具體是通過什么樣的方式實現(xiàn)的分布式的集群操作呢，我們先看一個示意圖(我把服務器和反向代理框在一塊，同屬于一個環(huán)境，后面我有介紹)：
通過上述的圖解大家就可以看清楚了，多個客戶端給服務器發(fā)送的請求，Nginx服務器接收到之后，按照一定的規(guī)則分發(fā)給了后端的業(yè)務處理服務器進行處理了。此時~請求的來源也就是客戶端是明確的，但是請求具體由哪臺服務器處理的并不明確了，Nginx扮演的就是一個反向代理角色。
客戶端是無感知代理的存在的，反向代理對外都是透明的，訪問者并不知道自己訪問的是一個代理。因為客戶端不需要任何配置就可以訪問。
反向代理，"它代理的是服務端"，主要用于服務器集群分布式部署的情況下，反向代理隱藏了服務器的信息。
反向代理的作用：
保證內(nèi)網(wǎng)的安全，通常將反向代理作為公網(wǎng)訪問地址，Web服務器是內(nèi)網(wǎng)
負載均衡，通過反向代理服務器來優(yōu)化網(wǎng)站的負載
項目場景
通常情況下，我們在實際項目操作時，正向代理和反向代理很有可能會存在在一個應用場景中，正向代理代理客戶端的請求去訪問目標服務器，目標服務器是一個反向單利服務器，反向代理了多臺真實的業(yè)務處理服務器。
具體的拓撲圖如下：
二者區(qū)別
截了一張圖來說明正向代理和反向代理二者之間的區(qū)別，如圖。
圖解：
在正向代理中，Proxy和Client同屬于一個LAN(圖中方框內(nèi))，隱藏了客戶端信息;
在反向代理中，Proxy和Server同屬于一個LAN(圖中方框內(nèi))，隱藏了服務端信息;
實際上，Proxy在兩種代理中做的事情都是替服務器代為收發(fā)請求和響應，不過從結構上看正好左右互換了一下，所以把后出現(xiàn)的那種代理方式稱為反向代理了。
負載均衡
我們已經(jīng)明確了所謂代理服務器的概念，那么接下來，Nginx扮演了反向代理服務器的角色，它是以依據(jù)什么樣的規(guī)則進行請求分發(fā)的呢?不用的項目應用場景，分發(fā)的規(guī)則是否可以控制呢?
這里提到的客戶端發(fā)送的、Nginx反向代理服務器接收到的請求數(shù)量，就是我們說的負載量。請求數(shù)量按照一定的規(guī)則進行分發(fā)到不同的服務器處理的規(guī)則，就是一種均衡規(guī)則。
所以~將服務器接收到的請求按照規(guī)則分發(fā)的過程，稱為負載均衡。
負載均衡在實際項目操作過程中，有硬件負載均衡和軟件負載均衡兩種，硬件負載均衡也稱為硬負載，如F5負載均衡，相對造價昂貴成本較高，但是數(shù)據(jù)的穩(wěn)定性安全性等等有非常好的保障，如中國移動中國聯(lián)通這樣的公司才會選擇硬負載進行操作;更多的公司考慮到成本原因，會選擇使用軟件負載均衡，軟件負載均衡是利用現(xiàn)有的技術結合主機硬件實現(xiàn)的一種消息隊列分發(fā)機制。
Nginx支持的負載均衡調(diào)度算法方式如下：
weight輪詢(默認)：接收到的請求按照順序逐一分配到不同的后端服務器，即使在使用過程中，某一臺后端服務器宕機，Nginx會自動將該服務器剔除出隊列，請求受理情況不會受到任何影響。 這種方式下，可以給不同的后端服務器設置一個權重值(weight)，用于調(diào)整不同的服務器上請求的分配率;權重數(shù)據(jù)越大，被分配到請求的幾率越大;該權重值，主要是針對實際工作環(huán)境中不同的后端服務器硬件配置進行調(diào)整的。
ip_hash：每個請求按照發(fā)起客戶端的ip的hash結果進行匹配，這樣的算法下一個固定ip地址的客戶端總會訪問到同一個后端服務器，這也在一定程度上解決了集群部署環(huán)境下session共享的問題。
fair：智能調(diào)整調(diào)度算法，動態(tài)的根據(jù)后端服務器的請求處理到響應的時間進行均衡分配，響應時間短處理效率高的服務器分配到請求的概率高，響應時間長處理效率低的服務器分配到的請求少;結合了前兩者的優(yōu)點的一種調(diào)度算法。但是需要注意的是Nginx默認不支持fair算法，如果要使用這種調(diào)度算法，請安裝upstream_fair模塊。
url_hash：按照訪問的url的hash結果分配請求，每個請求的url會指向后端固定的某個服務器，可以在Nginx作為靜態(tài)服務器的情況下提高緩存效率。同樣要注意Nginx默認不支持這種調(diào)度算法，要使用的話需要安裝Nginx的hash軟件包。
幾種常用web服務器對比
