Nginx的産生

沒(méi)有聽過(guò)Nginx？那麼(me)一定聽過(guò)它的"同行"Apache吧！Nginx同Apache一樣(yàng)都(dōu)是一種(zhǒng)WEB服務器。基于REST架構風格，以統一資源描述符(Uniform Resources Identifier)URI或者統一資源定位符(Uniform Resources Locator)URL作爲溝通依據，通過(guò)HTTP協議提供各種(zhǒng)網絡服務。

然而，這(zhè)些服務器在設計之初受到當時(shí)環境的局限，例如當時(shí)的用戶規模，網絡帶寬，産品特點等局限并且各自的定位和發(fā)展都(dōu)不盡相同。這(zhè)也使得各個WEB服務器有著(zhe)各自鮮明的特點。

Apache的發(fā)展時(shí)期很長(cháng)，而且是毫無争議的世界第一大服務器。它有著(zhe)很多優點：穩定、開(kāi)源、跨平台等等。它出現的時(shí)間太長(cháng)了，它興起(qǐ)的年代，互聯網産業遠遠比不上現在。所以它被(bèi)設計爲一個重量級的。它不支持高并發(fā)的服務器。在Apache上運行數以萬計的并發(fā)訪問，會(huì)導緻服務器消耗大量内存。操作系統對(duì)其進(jìn)行進(jìn)程或線程間的切換也消耗了大量的CPU資源，導緻HTTP請求的平均響應速度降低。

這(zhè)些都(dōu)決定了Apache不可能(néng)成(chéng)爲高性能(néng)WEB服務器，輕量級高并發(fā)服務器Nginx就(jiù)應運而生了。

俄羅斯的工程師Igor Sysoev，他在爲Rambler Media工作期間，使用C語言開(kāi)發(fā)了Nginx。Nginx作爲WEB服務器一直爲Rambler Media提供出色而又穩定的服務。

然後(hòu)呢，Igor Sysoev將(jiāng)Nginx代碼開(kāi)源，并且賦予自由軟件許可證。

由于：

• Nginx使用基于事(shì)件驅動架構，使得其可以支持數以百萬級别的TCP連接

• 高度的模塊化和自由軟件許可證使得第三方模塊層出不窮（這(zhè)是個開(kāi)源的時(shí)代啊~）

• Nginx是一個跨平台服務器，可以運行在Linux，Windows，FreeBSD，Solaris，AIX，Mac OS等操作系統上

• 這(zhè)些優秀的設計帶來的是極大的穩定性

所以，Nginx火了！

Nginx的用武之地

Nginx是一款自由的、開(kāi)源的、高性能(néng)的HTTP服務器和反向(xiàng)代理服務器；同時(shí)也是一個IMAP、POP3、SMTP代理服務器；Nginx可以作爲一個HTTP服務器進(jìn)行網站的發(fā)布處理，另外Nginx可以作爲反向(xiàng)代理進(jìn)行負載均衡的實現。

關于代理

說(shuō)到代理，首先我們要明确一個概念，所謂代理就(jiù)是一個代表、一個渠道(dào)；

此時(shí)就(jiù)涉及到兩(liǎng)個角色，一個是被(bèi)代理角色，一個是目标角色，被(bèi)代理角色通過(guò)這(zhè)個代理訪問目标角色完成(chéng)一些任務的過(guò)程稱爲代理操作過(guò)程；如同生活中的專賣店~客人到adidas專賣店買了一雙鞋，這(zhè)個專賣店就(jiù)是代理，被(bèi)代理角色就(jiù)是adidas廠家，目标角色就(jiù)是用戶。

正向(xiàng)代理

說(shuō)反向(xiàng)代理之前，我們先看看正向(xiàng)代理，正向(xiàng)代理也是大家最常接觸的到的代理模式，我們會(huì)從兩(liǎng)個方面(miàn)來說(shuō)關于正向(xiàng)代理的處理模式，分别從軟件方面(miàn)和生活方面(miàn)來解釋一下什麼(me)叫(jiào)正向(xiàng)代理。

在如今的網絡環境下，我們如果由于技術需要要去訪問國(guó)外的某些網站，此時(shí)你會(huì)發(fā)現位于國(guó)外的某網站我們通過(guò)浏覽器是沒(méi)有辦法訪問的，此時(shí)大家可能(néng)都(dōu)會(huì)用一個操作FQ進(jìn)行訪問，FQ的方式主要是找到一個可以訪問國(guó)外網站的代理服務器，我們將(jiāng)請求發(fā)送給代理服務器，代理服務器去訪問國(guó)外的網站，然後(hòu)將(jiāng)訪問到的數據傳遞給我們！

上述這(zhè)樣(yàng)的代理模式稱爲正向(xiàng)代理，正向(xiàng)代理最大的特點是客戶端非常明确要訪問的服務器地址；服務器隻清楚請求來自哪個代理服務器，而不清楚來自哪個具體的客戶端；正向(xiàng)代理模式屏蔽或者隐藏了真實客戶端信息。來看個示意圖（我把客戶端和正向(xiàng)代理框在一塊，同屬于一個環境，後(hòu)面(miàn)我有介紹）：

客戶端必須設置正向(xiàng)代理服務器，當然前提是要知道(dào)正向(xiàng)代理服務器的IP地址，還(hái)有代理程序的端口。如圖。

總結來說(shuō)：正向(xiàng)代理，"它代理的是客戶端，代客戶端發(fā)出請求"，是一個位于客戶端和原始服務器(origin server)之間的服務器，爲了從原始服務器取得内容，客戶端向(xiàng)代理發(fā)送一個請求并指定目标(原始服務器)，然後(hòu)代理向(xiàng)原始服務器轉交請求并將(jiāng)獲得的内容返回給客戶端。客戶端必須要進(jìn)行一些特别的設置才能(néng)使用正向(xiàng)代理。

正向(xiàng)代理的用途：
（1）訪問原來無法訪問的資源，如Google
（2） 可以做緩存，加速訪問資源
（3）對(duì)客戶端訪問授權，上網進(jìn)行認證
（4）代理可以記錄用戶訪問記錄（上網行爲管理），對(duì)外隐藏用戶信息

反向(xiàng)代理

明白了什麼(me)是正向(xiàng)代理，我們繼續看關于反向(xiàng)代理的處理方式，舉例如我大天朝的某寶網站，每天同時(shí)連接到網站的訪問人數已經(jīng)爆表，單個服務器遠遠不能(néng)滿足人民日益增長(cháng)的購買欲望了，此時(shí)就(jiù)出現了一個大家耳熟能(néng)詳的名詞：分布式部署；也就(jiù)是通過(guò)部署多台服務器來解決訪問人數限制的問題；某寶網站中大部分功能(néng)也是直接使用Nginx進(jìn)行反向(xiàng)代理實現的，并且通過(guò)封裝Nginx和其他的組件之後(hòu)起(qǐ)了個高大上的名字：Tengine，有興趣的童鞋可以訪問Tengine的官網查看具體的信息：http://tengine.taobao.org/。那麼(me)反向(xiàng)代理具體是通過(guò)什麼(me)樣(yàng)的方式實現的分布式的集群操作呢，我們先看一個示意圖（我把服務器和反向(xiàng)代理框在一塊，同屬于一個環境，後(hòu)面(miàn)我有介紹）：

通過(guò)上述的圖解大家就(jiù)可以看清楚了，多個客戶端給服務器發(fā)送的請求，Nginx服務器接收到之後(hòu)，按照一定的規則分發(fā)給了後(hòu)端的業務處理服務器進(jìn)行處理了。此時(shí)~請求的來源也就(jiù)是客戶端是明确的，但是請求具體由哪台服務器處理的并不明确了，Nginx扮演的就(jiù)是一個反向(xiàng)代理角色。

客戶端是無感知代理的存在的，反向(xiàng)代理對(duì)外都(dōu)是透明的，訪問者并不知道(dào)自己訪問的是一個代理。因爲客戶端不需要任何配置就(jiù)可以訪問。

反向(xiàng)代理，"它代理的是服務端，代服務端接收請求"，主要用于服務器集群分布式部署的情況下，反向(xiàng)代理隐藏了服務器的信息。

反向(xiàng)代理的作用：
（1）保證内網的安全，通常將(jiāng)反向(xiàng)代理作爲公網訪問地址，Web服務器是内網
（2）負載均衡，通過(guò)反向(xiàng)代理服務器來優化網站的負載

項目場景

通常情況下，我們在實際項目操作時(shí)，正向(xiàng)代理和反向(xiàng)代理很有可能(néng)會(huì)存在在一個應用場景中，正向(xiàng)代理代理客戶端的請求去訪問目标服務器，目标服務器是一個反向(xiàng)單利服務器，反向(xiàng)代理了多台真實的業務處理服務器。具體的拓撲圖如下：

二者區别

截了一張圖來說(shuō)明正向(xiàng)代理和反向(xiàng)代理二者之間的區别，如圖。

圖解：

在正向(xiàng)代理中，Proxy和Client同屬于一個LAN（圖中方框内），隐藏了客戶端信息；

在反向(xiàng)代理中，Proxy和Server同屬于一個LAN（圖中方框内），隐藏了服務端信息；

實際上，Proxy在兩(liǎng)種(zhǒng)代理中做的事(shì)情都(dōu)是替服務器代爲收發(fā)請求和響應，不過(guò)從結構上看正好(hǎo)左右互換了一下，所以把後(hòu)出現的那種(zhǒng)代理方式稱爲反向(xiàng)代理了。

負載均衡

我們已經(jīng)明确了所謂代理服務器的概念，那麼(me)接下來，Nginx扮演了反向(xiàng)代理服務器的角色，它是以依據什麼(me)樣(yàng)的規則進(jìn)行請求分發(fā)的呢？不用的項目應用場景，分發(fā)的規則是否可以控制呢？

這(zhè)裡(lǐ)提到的客戶端發(fā)送的、Nginx反向(xiàng)代理服務器接收到的請求數量，就(jiù)是我們說(shuō)的負載量。

請求數量按照一定的規則進(jìn)行分發(fā)到不同的服務器處理的規則，就(jiù)是一種(zhǒng)均衡規則。

所以，將(jiāng)服務器接收到的請求按照規則分發(fā)的過(guò)程，稱爲負載均衡。

負載均衡在實際項目操作過(guò)程中，有硬件負載均衡和軟件負載均衡兩(liǎng)種(zhǒng)，硬件負載均衡也稱爲硬負載，如F5負載均衡，相對(duì)造價昂貴成(chéng)本較高，但是數據的穩定性安全性等等有非常好(hǎo)的保障，如中國(guó)移動中國(guó)聯通這(zhè)樣(yàng)的公司才會(huì)選擇硬負載進(jìn)行操作；更多的公司考慮到成(chéng)本原因，會(huì)選擇使用軟件負載均衡，軟件負載均衡是利用現有的技術結合主機硬件實現的一種(zhǒng)消息隊列分發(fā)機制。

Nginx支持的負載均衡調度算法方式如下：

1. weight輪詢(默認，常用)：接收到的請求按照權重分配到不同的後(hòu)端服務器，即使在使用過(guò)程中，某一台後(hòu)端服務器宕機，Nginx會(huì)自動將(jiāng)該服務器剔除出隊列，請求受理情況不會(huì)受到任何影響。 這(zhè)種(zhǒng)方式下，可以給不同的後(hòu)端服務器設置一個權重值(weight)，用于調整不同的服務器上請求的分配率；權重數據越大，被(bèi)分配到請求的幾率越大；該權重值，主要是針對(duì)實際工作環境中不同的後(hòu)端服務器硬件配置進(jìn)行調整的。

2. ip_hash（常用）：每個請求按照發(fā)起(qǐ)客戶端的ip的hash結果進(jìn)行匹配，這(zhè)樣(yàng)的算法下一個固定ip地址的客戶端總會(huì)訪問到同一個後(hòu)端服務器，這(zhè)也在一定程度上解決了集群部署環境下session共享的問題。

3. fair：智能(néng)調整調度算法，動态的根據後(hòu)端服務器的請求處理到響應的時(shí)間進(jìn)行均衡分配，響應時(shí)間短處理效率高的服務器分配到請求的概率高，響應時(shí)間長(cháng)處理效率低的服務器分配到的請求少；結合了前兩(liǎng)者的優點的一種(zhǒng)調度算法。但是需要注意的是Nginx默認不支持fair算法，如果要使用這(zhè)種(zhǒng)調度算法，請安裝upstream_fair模塊。

4. url_hash：按照訪問的url的hash結果分配請求，每個請求的url會(huì)指向(xiàng)後(hòu)端固定的某個服務器，可以在Nginx作爲靜态服務器的情況下提高緩存效率。同樣(yàng)要注意Nginx默認不支持這(zhè)種(zhǒng)調度算法，要使用的話需要安裝Nginx的hash軟件包。

 幾種(zhǒng)常用web服務器對(duì)比