【轉】Nginx搭建反向代理服務器過程詳解

閱讀目錄

• 1.1 反向代理初印象
• 1.2 反向代理的做用
• 2.1 Nginx是神馬？
• 2.2 Nginx的應用現狀
• 2.3 Nginx的核心特色
• 3.1 準備一個ASP.NET網站部署到IIS服務器集羣中
• 3.2 下載Nginx並部署到服務器中做爲自啓動的Windows服務
• 3.3 修改Nginx核心配置文件nginx.conf
• 3.4 添加Nginx對於靜態文件的緩存配置
• 3.5 簡單測試Nginx反向代理實現負載均衡效果

 

1、反向代理：Web服務器的「經紀人」

1.1 反向代理初印象

反向代理（Reverse Proxy）方式是指以代理服務器來接受internet上的鏈接請求，而後將請求轉發給內部網絡上的服務器，並將從服務器上獲得的結果返回給internet上請求鏈接的客戶端，此時代理服務器對外就表現爲一個服務器。

從上圖能夠看出：反向代理服務器位於網站機房，代理網站Web服務器接收Http請求，對請求進行轉發。

1.2 反向代理的做用

①保護網站安全：任何來自Internet的請求都必須先通過代理服務器；

②經過配置緩存功能加速Web請求：能夠緩存真實Web服務器上的某些靜態資源，減輕真實Web服務器的負載壓力；

③實現負載均衡：充當負載均衡服務器均衡地分發請求，平衡集羣中各個服務器的負載壓力；

2、初識Nginx：簡單卻不平凡

2.1 Nginx是神馬？

Nginx是一款輕量級的網頁服務器、反向代理器以及電子郵件代理服務器。其將源代碼以類BSD許可證的形式發佈，因它的穩定性、豐富的功能集、示例配置文件和低系統資源的消耗而聞名。

Source：Nginx（發音同engine x），它是由俄羅斯程序員Igor Sysoev所開發的。起初是供俄國大型的門戶網站及搜索引擎Rambler（俄語：Рамблер）使用。此軟件BSD-like協議下發行，能夠在UNIX、GNU/Linux、BSD、Mac OS X、Solaris，以及Microsoft Windows等操做系統中運行。

說到Web服務器，Apache服務器和IIS服務器是兩大巨頭；可是運行速度更快、更靈活的對手：Nginx 正在迎頭遇上。

2.2 Nginx的應用現狀

Nginx 已經在俄羅斯最大的門戶網站── Rambler Media（www.rambler.ru）上運行了3年時間，同時俄羅斯超過20%的虛擬主機平臺採用Nginx做爲反向代理服務器。

在國內，已經有 淘寶、新浪博客、新浪播客、網易新聞、六間房、56.com、Discuz!、水木社區、豆瓣、YUPOO、海內、迅雷在線 等多家網站使用 Nginx 做爲Web服務器或反向代理服務器。

2.3 Nginx的核心特色

（1）跨平臺：Nginx 能夠在大多數 Unix like OS編譯運行，並且也有Windows的移植版本；

（2）配置異常簡單：很是容易上手。配置風格跟程序開發同樣，神通常的配置；

（3）非阻塞、高併發鏈接：數據複製時，磁盤I/O的第一階段是非阻塞的。官方測試可以支撐5萬併發鏈接，在實際生產環境中跑到2～3萬併發鏈接數。（這得益於Nginx使用了最新的epoll模型）；

PS：對於一個Web服務器來講，首先看一個請求的基本過程：創建鏈接—接收數據—發送數據，在系統底層看來 ：上述過程（創建鏈接—接收數據—發送數據）在系統底層就是讀寫事件。

①若是採用阻塞調用的方式，當讀寫事件沒有準備好時，必然不可以進行讀寫事件，那麼久只好等待，等事件準備好了，才能進行讀寫事件，那麼請求就會被耽擱 。

②既然沒有準備好阻塞調用不行，那麼採用非阻塞調用方式。非阻塞就是：事件立刻返回，告訴你事件還沒準備好呢，你慌什麼，過會再來吧。好吧，你過一會，再來檢查一下事件，直到事件準備好了爲止，在這期間，你就能夠先去作其它事情，而後再來看看事件好了沒。雖然不阻塞了，但你得不時地過來檢查一下事件的狀態，你能夠作更多的事情了，但帶來的開銷也是不小的。

（4）事件驅動：通訊機制採用epoll模型，支持更大的併發鏈接。

①非阻塞經過不斷檢查事件的狀態來判斷是否進行讀寫操做，這樣帶來的開銷很大，所以就有了異步非阻塞的事件處理機制。這種機制讓你能夠同時監控多個事件，調用他們是阻塞的，但能夠設置超時時間，在超時時間以內，若是有事件準備好了，就返回。這種機制解決了上面阻塞調用與非阻塞調用的兩個問題。

②以epoll模型爲例：當事件沒有準備好時，就放入epoll(隊列)裏面。若是有事件準備好了，那麼就去處 理；若是事件返回的是EAGAIN，那麼繼續將其放入epoll裏面。從而，只要有事件準備好了，咱們就去處理它，只有當全部事件都沒有準備好時，纔在 epoll裏面等着。這樣，咱們就能夠併發處理大量的併發了，固然，這裏的併發請求，是指未處理完的請求，線程只有一個，因此同時能處理的請求固然只有一 個了，只是在請求間進行不斷地切換而已，切換也是由於異步事件未準備好，而主動讓出的。這裏的切換是沒有任何代價，你能夠理解爲循環處理多個準備好的事 件，事實上就是這樣的。

③與多線程方式相比，這種事件處理方式是有很大的優點的，不須要建立線程，每一個請求佔用的內存也不多，沒有上下文切換， 事件處理很是的輕量級，併發數再多也不會致使無謂的資源浪費（上下文切換）。對於IIS服務器，每一個請求會獨佔一個工做線程，當併發數上到幾千時，就同時 有幾千的線程在處理請求了。這對操做系統來講，是個不小的挑戰：由於線程帶來的內存佔用很是大，線程的上下文切換帶來的cpu開銷很大，天然性能就上不 去，從而致使在高併發場景下性能降低嚴重。

總結：經過異步非阻塞的事件處理機制，Nginx實現由進程循環處理多個準備好的事件，從而實現高併發和輕量級。

（5）Master/Worker結構：一個master進程，生成一個或多個worker進程。

PS：Master-Worker設計模式核心思想是將原來串行的邏輯並行化， 並將邏輯拆分紅不少獨立模塊並行執行。其中主要包含兩個主要組件Master和Worker，Master主要將邏輯進行拆分，拆分爲互相獨立的部分，同 時維護了Worker隊列，將每一個獨立部分下發到多個Worker並行執行，Worker主要進行實際邏輯計算，並將結果返回給Master。

問：nginx採用這種進程模型有什麼好處？

答：採用獨立的進程，可讓互相之間不會影響，一個進程退出後，其它進程還在工做，服務不會中斷，Master 進程則很快從新啓動新的Worker進程。固然，Worker進程的異常退出，確定是程序有bug了，異常退出，會致使當前Worker上的全部請求失 敗，不過不會影響到全部請求，因此下降了風險。

（6）內存消耗小：處理大併發的請求內存消耗很是小。在3萬併發鏈接下，開啓的10個Nginx 進程才消耗150M內存（15M*10=150M）。

（7）內置的健康檢查功能：若是 Nginx 代理的後端的某臺 Web 服務器宕機了，不會影響前端訪問。

（8）節省帶寬：支持 GZIP 壓縮，能夠添加瀏覽器本地緩存的 Header 頭。

（9）穩定性高：用於反向代理，宕機的機率微乎其微。

3、構建實戰：Nginx+IIS構築Web服務器集羣的負載均衡

這裏咱們主要在Windows環境下，經過將同一個Web網站部署到不一樣服務器的IIS上，再經過一個統一的Nginx反響代理服務器對外提供統一訪問接入，實現一個最簡化的反向代理和負載均衡服務。可是，受限於實驗條件， 咱們這裏主要在一臺計算機上進行反向代理、IIS集羣的模擬，具體的實驗環境以下圖所示：咱們將nginx服務和web網站都部署在一臺計算機 上，nginx監聽http80端口，而web網站分別以不一樣的端口號（這裏是8050及8060）部署在同一個IIS服務器上，用戶訪問 localhost時，nginx做爲反向代理將請求均衡地轉發給兩個IIS中不一樣端口的Web應用程序進行處理。雖然實驗環境很簡單並且有限，可是對於 一個簡單的負載均衡效果而言，本文是能夠達到而且展現的。

3.1 準備一個ASP.NET網站部署到IIS服務器集羣中

（1）在VS中新建一個ASP.NET Web應用程序，可是爲了在一臺計算機上展現效果，咱們將這個Web程序複製一份，並修改兩個Web程序的Default.aspx，讓其的首頁顯示不一樣 的一點信息。這裏Web1展現的是「The First Web：」，而Web2展現的則是「The Second Web」。

（2）調試運行，看看兩個網站的效果如何？

①Web1的展現效果：

②Web2的展現效果：

③部署到IIS中，分配不一樣的端口號：這裏我選擇了Web1:8050，Web2:8060

（3）總結：在真實環境中，構建Web應用服務器集羣的實現是將同一個Web應用程序部署到Web服務器集羣中的多個Web服務器上。

3.2 下載Nginx並部署到服務器中做爲自啓動的Windows服務

（1）到Nginx官網下載Nginx的Windows版本：http://nginx.org/en/download.html（這裏咱們使用nginx/Windows-1.4.7版本進行實驗，本文底部有下載地址）

（2）解壓到磁盤任意目錄，例如這裏我解壓到了：D:\Servers\nginx-1.4.7

（3）啓動、中止和從新加載服務：經過cmd以守護進程方式啓動nginx.exe：start nginx.exe，中止服務：nginx -s stop，從新加載配置：nginx -s  reload；

（4）每次以cmd方式啓動Nginx服務不符合實際要求，因而咱們想到將其註冊爲Windows服務，並設置爲自動啓動模式。這裏，咱們使用一個 不錯的小程序：「Windows Service Wrapper」，將nginx.exe註冊爲Windows服務，具體的步湊以下：

①下載最新版的 Windows Service Wrapper 程序，好比我下載的名稱是 「winsw-1.8-bin.exe」（本文底部有下載地址），而後把它命名成你想要的名字（好比: 「nginx-service.exe」，固然，你也能夠不更名）

②將重命名後的 nginx-service.exe 複製到 nginx 的安裝目錄（好比，我這裏是 「D:\Servers\nginx-1.4.7″）

③在同一個目錄下建立一個Windows Service Wrapper 的XML配置文件，名稱必須與第一步重命名時使用的名稱一致（好比我這裏是 「nginx-service.xml」,  若是，你沒有重命名，則應該是 「winsw-1.8-bin.xml」），這個XML的內容以下：

<?xml version="1.0" encoding="UTF-8" ?>
<service>
<id>nginx</id>
<name>Nginx Service</name>
<description>High Performance Nginx Service</description>
<executable>D:\Servers\nginx-1.4.7\nginx.exe</executable>
<logpath>D:\Servers\nginx-1.4.7\</logpath>
<logmode>roll</logmode>
<depend></depend>
<startargument>-p D:\Servers\nginx-1.4.7</startargument>
<stopargument>-p D:\Servers\nginx-1.4.7 -s stop</stopargument>
</service>

④在命令行下執行如下命令，以便將其註冊成Windows服務：nginx-service.exe install

⑤接下來就能夠在Windows服務列表看到Nginx服務了，這裏咱們能夠將其設置爲自動啓動了：

（5）總結：在Windows環境中，要對外提供的Windows服務通常都要將其啓動類型設置爲自動。

3.3 修改Nginx核心配置文件nginx.conf

（1）進程數與每一個進程的最大鏈接數：

                •nginx進程數，建議設置爲等於CPU總核心數

                •單個進程最大鏈接數，那麼該服務器的最大鏈接數=鏈接數*進程數

（2）Nginx的基本配置：

                •監聽端口通常都爲http端口：80;

                •域名能夠有多個，用空格隔開：例如 server_name www.ha97.com ha97.com;

（3）負載均衡列表基本配置：

•location / {}：對aspx後綴的進行負載均衡請求，假如咱們要對全部的aspx後綴的文件進行負載均衡時，能夠這樣寫：location ~ .*\.aspx$ {}

•proxy_pass：請求轉向自定義的服務器列表，這裏咱們將請求都轉向標識爲http://cuitccol.com的負載均衡服務器列表；

•在負載均衡服務器列表的配置中，weight是權重，能夠根據機器配置定義權重（若是某臺服務器的硬件配置十分好，能夠處理更多的請求，那麼能夠 爲其設置一個比較高的weight；而有一臺的服務器的硬件配置比較差，那麼能夠將前一臺的weight配置爲weight=2，後一臺差的配置爲 weight=1）。weigth參數表示權值，權值越高被分配到的概率越大；

（4）總結：最基本的Nginx配置差很少就是上面這些內容，固然僅僅是最基礎的配置。（詳細的配置內容請下載底部的nginx-1.4.7詳細查看）

3.4 添加Nginx對於靜態文件的緩存配置

爲了提升響應速度，減輕真實服務器的負載，對於靜態資源咱們能夠在反向代理服務器中進行緩存，這也是反向代理服務器的一個重要的做用。

（1）緩存靜態資源之圖片文件

root /nginx-1.4.7/staticresources/image：對於配置中提到的jpg/png等文件均定爲到/nginx-1.4.7/staticresources/image文件夾中進行尋找匹配並將文件返回；

expires 7d：過時時效爲7天，靜態文件不怎麼更新，過時時效能夠設大一點，若是頻繁更新，則能夠設置得小一點；

TIPS：下面的樣式、腳本緩存配置同這裏同樣，只是定位的文件夾不同而已，再也不贅述。

（2）緩存靜態資源之樣式文件

（3）緩存靜態資源之腳本文件

（4）在nginx服務文件夾中建立靜態資源文件夾，並要緩存的靜態文件拷貝進去：這裏我主要將Web程序中用到的image、css以及js文件拷貝了進去；

（5）總結：經過配置靜態文件的緩存設置，對於這些靜態文件的請求能夠直接從反向代理服務器中直接返回，而無需再將這些靜態資源請求轉發到具體的Web服務器進行處理了，能夠提升響應速度，減輕真實Web服務器的負載壓力。

3.5 簡單測試Nginx反向代理實現負載均衡效果

（1）第一次訪問http://localhost/Default.aspx時從127.0.0.1:8050處理響應返回結果

（2）第二次訪問http://localhost/Default.aspx時從127.0.0.1:8060處理響應返回結果

（3）屢次訪問http://localhost/Default.aspx時的截屏：

學習小結

在本文中，藉助了Nginx這個神器簡單地在Windows環境下搭建了一個反向代理服務，並模擬了一個IIS服務器集羣的負載均衡效果。從這個 DEMO中，咱們能夠簡單地感覺到反向代理爲咱們所作的事情，並體會負載均衡是怎麼一回事。可是，在目前大多數的應用中，都會將Nginx部署在 Linux服務器中，而且會作一些針對負載均衡的優化配置，這裏咱們所作的僅僅就是一個小小的使用而已（just修改一下配置文件）。不過，萬丈高樓平地 起，前期的小小體會，也會幫助咱們向後期的深刻學習奠基一點點的基礎。

忽然在QQ空間裏看到了朋友送的禮物，猛然發現今天竟然是個人陽曆生日，好吧，我祝我本身生日快樂，但願本身在將來的日子中可以作更多的實踐，分享更多的內容。固然，若是你以爲本文還能夠，那也麻煩點個贊，不要吝嗇你的鼠標左鍵喲。

 

from :http://www.open-open.com/lib/view/open1417488526633.html