Nginx反向代理負載均衡搭建
1.Nginx簡介
Nginx是一款高效能的http 伺服器/反向代理伺服器及電子郵件（IMAP/POP3）代理伺服器。由俄羅斯的程式設計師Igor Sysoev所開發，官方測試nginx能夠支支撐5萬併發連結，並且cpu、記憶體等資源消耗卻非常低，執行非常穩定。
2.Nginx應用場景
1、http伺服器。Nginx是一個http服務可以獨立提供http服務。可以做網頁靜態伺服器。
2、虛擬主機。可以實現在一臺伺服器虛擬出多個網站。例如個人網站使用的虛擬主機。
3、反向代理，負載均衡。當網站的訪問量達到一定程度後，單臺伺服器不能滿足使用者的請求時，需要用多臺伺服器叢集可以使用nginx做反向代理。並且多臺伺服器可以平均分擔負載，不會因為某臺伺服器負載高宕機而某臺伺服器閒置的情況。
3.概念解釋
3.1正向代理
所謂正向代理其實就和我們平時所做的翻牆一樣，例如:當我們想要訪問某些國外的**網站時，因為某些原因我們無法訪問到，這時候我們就可以找代理，代理有能力訪問到那個網站，而我們只需要訪問代理。就可以得到那個網站的內容了。且代理可以決定是否將使用者資訊告訴給網站。
總的來說正向代理是一個位於客戶端與原始伺服器之間的一個代理伺服器，為了從原始伺服器獲取內容，客戶端向代理髮送一個請求並指定目標伺服器(原始伺服器),然後代理伺服器向原始伺服器轉交請求並獲取內容交給目標伺服器，客戶端必須進行特殊的設定才能使用正向代理。
如下圖所示。
3.2反向代理
與正向代理相反，舉個例子：當用戶訪問某個伺服器下的內容時，其實該伺服器並無此內容，但是該伺服器通過反向代理從另一臺伺服器中獲取到了使用者想要的內容，並返回給了使用者。使用者以為是在此伺服器下獲取到的內容，其實並不是。
總的來說，反向代理使用者不需要進行特殊的設定，對使用者來說他以為訪問得到的內從是從原始伺服器中得到的。其實是客戶端向反向代理的名稱空間中傳送普通請求，接著反向代理將判斷向何處(原始伺服器)轉交請求，並將獲得的內容返回給客戶端，就像這些內容 原本就是它自己的一樣。 如圖所示
4.安裝Nginx
4.1 下載
進入http://nginx.org/en/download.html
下載nginx，本人使用的是nginx1.8.0版本。
4.2 安裝
4.2.1 安裝環境
安裝nginx需要如下環境
1.gcc
編譯依賴gcc環境，如果沒有gcc環境，需要安裝gcc
yum install gcc-c++
2.PCRE
PCRE(Perl Compatible Regular Expressions)是一個Perl庫，包括 perl 相容的正則表示式庫。nginx的http模組使用pcre來解析正則表示式，所以需要在linux上安裝pcre庫。
yum install -y pcre pcre-devel
3.zlib
lib庫提供了很多種壓縮和解壓縮的方式，nginx使用zlib對http包的內容進行gzip，所以需要在linux上安裝zlib庫。
yum install -y zlib zlib-devel
4.openssl
OpenSSL 是一個強大的安全套接字層密碼庫，囊括主要的密碼演算法、常用的金鑰和證書封裝管理功能及SSL協議，並提供豐富的應用程式供測試或其它目的使用。
nginx不僅支援http協議，還支援https（即在ssl協議上傳輸http），所以需要在linux安裝openssl庫。
yum install -y openssl openssl-devel
4.2.2 編譯安裝
將nginx-1.8.0.tar.gz拷貝至linux伺服器。
解壓：
tar -zxvf nginx-1.8.0.tar.gz
cd nginx-1.8.0
執行如下命令
-
./configure \
-
--prefix=
/usr/local
/nginx \
-
--pid-path=/var
/run/nginx
/nginx.pid \
-
--lock-path=/var
/lock/nginx.lock \
-
--error-log-path=
/var/log
/nginx/error.log \
-
--http-log-path=
/var/log
/nginx/access.log \
-
--with-http_gzip_static_module \
-
--http-client-body-temp-path=
/var/temp
/nginx/client \
-
--http-proxy-temp-path=
/var/temp
/nginx/proxy \
-
--http-fastcgi-temp-path=
/var/temp
/nginx/fastcgi \
-
--http-uwsgi-temp-path=
/var/temp
/nginx/uwsgi \
-
--with-http_stub_status_module \
-
--with-http_ssl_module \
-
--http-scgi-temp-path=
/var/temp
/nginx/scgi
注意：上邊將臨時檔案目錄指定為/var/temp/nginx，需要在/var下建立temp/nginx目錄
開始編譯和安裝
make
make install
安裝成功檢視安裝目錄 ：
4.3啟動Nginx
啟動
-
cd /usr/
local/nginx/sbin/
-
./nginx
檢視
ps -aux | grep nginx
其中6844為Nginx的主程序id，6845為Nginx的工作程序id
4.3退出Nginx
-
cd /usr/
local/nginx/sbin
-
./nginx -s quit
4.4 重啟Nginx
-
cd /usr/
local/nginx/sbin
-
./nginx -s reload
4.5 Nginx測試
訪問對應安裝Nginx的linux的ip，出現如下介面即安裝成功。
5.搭建負載均衡
5.1 什麼是負載均衡
負載均衡 建立在現有網路結構之上，它提供了一種廉價有效透明的方法擴充套件網路裝置和伺服器的頻寬、增加吞吐量、加強網路資料處理能力、提高網路的靈活性和可用性。
負載均衡，英文名稱為Load Balance，其意思就是分攤到多個操作單元上進行執行，例如Web伺服器、FTP伺服器、企業關鍵應用伺服器和其它關鍵任務伺服器等，從而共同完成工作任務。
5.2 負載均衡的優點
簡單的來說。可以減少伺服器的壓力，將原本一臺伺服器所要承受的訪問量分給了多臺，並提高了專案的可用性，當一臺伺服器掛掉的時候也不會導致整個專案癱瘓。
5.3 nginx實現負載均衡
nginx作為負載均衡伺服器，使用者請求先到達nginx，再由nginx根據負載配置將請求轉發至 tomcat伺服器。
nginx負載均衡伺服器：192.168.14.129
tomcat1伺服器：192.168.14.131
tomcat2伺服器：192.168.14.134
我們將兩個相同的專案分別放到了131與134伺服器中，當我們通過129負載訪問專案介面時，nginx會自動將請求輪流分配給131與134來執行。
5.4 配置
以vim模式開啟nginx.conf配置檔案
-
cd /usr/
local/nginx/conf/
-
vi nginx.conf
根據上邊的需求在nginx.conf檔案中配置負載均衡，如下：
-
#在server上新增此upstream節點
-
upstream mytomcat{
-
#分權 即訪問131與134的次數比例為1比1
-
server
192.168
.14
.131:
8080 weight=
1;
-
server
192.168
.14
.134:
8080 weight=
1;
-
}
-
-
server {
-
listen
80;
-
server_name localhost;
-
#即所有請求都到這裡去找分配
-
location / {
-
#使用mytomcat分配規則，即剛自定義新增的upstream節點
-
proxy_pass http:
//mytomcat;
-
}
-
}
配置完成，儲存並退出。
5.5 測試結果
多次訪問此介面。通過後臺日志我們發現兩個介面分別輪流被呼叫，這樣一個簡單的負載就搭建完成了。
補充，應當注意的幾個問題：
nginx還可以按照排程規則實現動態、靜態頁面的分離，可以按照輪詢、ip雜湊、URL雜湊、權重等多種方式對後端伺服器做負載均衡，同時還支援後端伺服器的健康檢查。
nginx 的 upstream目前支援 4 種方式的分配
1)、輪詢（預設）
每個請求按時間順序逐一分配到不同的後端伺服器，如果後端伺服器down掉，能自動剔除。
2)、weight
指定輪詢機率，weight和訪問比率成正比，用於後端伺服器效能不均的情況。
2)、ip_hash
每個請求按訪問ip的hash結果分配，這樣每個訪客固定訪問一個後端伺服器，可以解決session的問題。
3)、fair（第三方）
按後端伺服器的響應時間來分配請求，響應時間短的優先分配。
4)、url_hash（第三方）
多臺機器間session的共享問題
配置負載均衡比較簡單,但是最關鍵的一個問題是怎麼實現多臺伺服器之間session的共享
下面有幾種方法(以下內容來源於網路,第四種方法沒有實踐.)
1). 不使用session，換作cookie
能把session改成cookie，就能避開session的一些弊端，在集群系統中不能用session，如果系統不復雜，就優先考慮能否將session去掉，改動起來非常麻煩的話，再用下面的辦法。
2). 應用伺服器自行實現共享
php可以用資料庫或memcached來儲存session，從而在php本身建立了一個session叢集，用這樣的方式可以令 session保證穩定，即使某個節點有故障，session也不會丟失，適用於較為嚴格但請求量不高的場合。但是它的效率是不會很高的，不適用於對效率要求高的場合。
以上兩個辦法都跟nginx沒什麼關係，下面來說說用nginx該如何處理：
3). ip_hash
nginx中的ip_hash技術能夠將某個ip的請求定向到同一臺後端，這樣一來這個ip下的某個客戶端和某個後端就能建立起穩固的session，ip_hash是在upstream配置中定義的：
upstream backend {
server 127.0.0.1:8080 ;
server 127.0.0.1:9090 ;
ip_hash;
}
ip_hash是容易理解的，但是因為僅僅能用ip這個因子來分配後端，因此ip_hash是有缺陷的，不能在一些情況下使用：
nginx不是最前端的伺服器。ip_hash要求nginx一定是最前端的伺服器，否則nginx得不到正確ip，就不能根據ip作hash。譬如使用的是squid為最前端，那麼nginx取ip時只能得到squid的伺服器ip地址，用這個地址來作分流是肯定錯亂的。
nginx的後端還有其它方式的負載均衡。假如nginx後端又有其它負載均衡，將請求又通過另外的方式分流了，那麼某個客戶端的請求肯定不能定位到同一臺session應用伺服器上。這麼算起來，nginx後端只能直接指向應用伺服器，或者再搭一個squid，然後指向應用伺服器。最好的辦法是用location作一次分流，將需要session的部分請求通過ip_hash分流，剩下的走其它後端去。
4). upstream_hash
為了解決ip_hash的一些問題，可以使用upstream_hash這個第三方模組，這個模組多數情況下是用作url_hash的，但是並不妨礙將它用來做session共享。假如前端是squid，他會將ip加入x_forwarded_for這個http_header裡，用upstream_hash可以用這個頭做因子，將請求定向到指定的後端：可見這篇文件：http://www.sudone.com/nginx/nginx_url_hash.html
在文件中是使用$request_uri做因子，稍微改一下：
hash $http_x_forwarded_for;
這樣就改成了利用x_forwarded_for這個頭作因子，在nginx新版本中可支援讀取cookie值，所以也可以改成：
hash $cookie_jsessionid;
假如在php中配置的session為無cookie方式，配合nginx自己的一個userid_module模組就可以用nginx自發一個cookie，可參見userid模組的英文文件：http://wiki.nginx.org/NginxHttpUserIdModule
另可用姚偉斌編寫的模組upstream_jvm_route：http://code.google.com/p/nginx-upstream-jvm-route/
後端伺服器自動加上埠的問題
一個典型的 Nginx + Apache 應用方案可以是Nginx 佔用 80 埠，過濾靜態請求，然後動態請求即 Proxy 到 Apache 的 8080 埠。Proxy 反向代理的好處是訪問的時候，始終就是 80埠，來訪者不會覺察到有任何的區別。但有的應用確非常“聰明”，識別到 Apache 所位於的埠是 8080 ，就會把相關的超連結都一併加上 :8080 的後續。這麼就死定了，還能有正常訪問麼？！有個方法可以解決這事，就是把 apache 也執行在80埠上。同一臺伺服器，有Nginx 也有 Apache，2個httpd服務，都是80，不會衝突麼？
nginx.conf 的配置中
server {
listen 80;
server_name www.linuxidc.com;
….
}
修改為：
server {
listen 123.123.123.123:80; #指定Nginx只佔用某個公網IP的80埠。
#listen 123.123.123.124:80; #如果你伺服器中有多個IP，還可以指定多個。
server_name www.linuxidc.com;
….
}
把 apache 的配置檔案 httpd.conf 中的
Listen 80
改為
Listen 127.0.0.1:80
跟Nginx一樣，指定apache所佔用的IP及埠。
儲存退出，重啟apache即可生效。