Nginx反向代理與負載均衡

叢集簡介

簡單地說，叢集就是指一組（若干個）相互獨立的計算機，利用高速通訊網路組成的一個較大的計算機服務系統，每個叢集節點（即叢集中的每臺計算機）都是執行各自服務的獨立伺服器。這些伺服器之間可以彼此通訊，協同向用戶提供應用程式，系統資源和資料，並以單一系統的模式加以管理。當用戶客戶機請求集群系統時，叢集給使用者的感覺就是一個單一獨立的伺服器，而實際上使用者請求的是一組叢集伺服器。

開啟谷歌，百度的頁面，看起來好簡單，也許你覺得用幾分鐘就可以製作出相似的網頁，而實際上，這個頁面的背後是由成千上萬臺伺服器叢集協同工作的結果。而這麼多的伺服器維護和管理，以及相互協調工作也許就是同學們未來的工作職責了。

若要用一句話描述叢集，即一堆伺服器合作做同一件事，這些機器可能需要整個技術團隊架構，設計和統一協調管理，這些機器可以分佈在一個機房，也可以分佈在全國全球各個地區的多個機房。

為什麼要使用叢集

（1）高效能

一些國家重要的計算密集型應用（如天氣預報，核試驗模擬等），需要計算機有很強的運算處理能力。以全世界現有的技術，即使是大型機，其計算能力也是有限的，很難單獨完成此任務。因為計算時間可能會相當長，也許幾天，甚至幾年或更久。因此，對於這類複雜的計算業務，便使用了計算機叢集技術，集中幾十上百臺，甚至成千上萬臺計算機進行計算。

假如你配一個LNMP環境，每次只需要服務10個併發請求，那麼單臺伺服器一定會比多個伺服器叢集要快。只有當併發或總請求數量超過單臺伺服器的承受能力時，伺服器叢集才會體現出優勢。

叢集高效能。.png-273.6kB

（2）價格有效性

通常一套系統叢集架構，只需要幾臺或數十臺伺服器主機即可。與動輒價值上百萬元的專用超級計算機相比便宜了很多。在達到同樣效能需求的條件下，採用計算機叢集架構比採用同等運算能力的大型計算機具有更高的價效比。

早期的淘寶，支付寶的資料庫等核心系統就是使用上百萬元的小型機伺服器。後因使用維護成本太高以及擴充套件裝置費用成幾何級數翻倍，甚至成為擴充套件瓶頸，人員維護也十分困難，最終使用PC伺服器叢集替換之，比如，把資料庫系統從小機結合Oracle資料庫遷移到MySQL開源資料庫結合PC伺服器上來。不但成本下降了，擴充套件和維護也更容易了。

（3）可伸縮性

當服務負載，壓力增長時，針對集群系統進行較簡單的擴充套件即可滿足需求，且不會降低服務質量。

通常情況下，硬體裝置若想擴充套件效能，不得不增加新的CPU和儲存器裝置，如果加不上去了，就不得不夠買更高效能的伺服器，就拿我們現在的伺服器來講，可以增加的裝置總是有限的。如果採用叢集技術，則只需要將新的單個伺服器加入現有叢集架構中即可，從訪問的客戶角度來看，系統服務無論是連續性還是效能上都幾乎沒有變化，系統在不知不覺中完成了升級，加大了訪問能力，輕鬆地實現了擴充套件。集群系統中的節點數目可以增長到幾千乃至上萬個，其伸縮性遠超過單臺超級計算機。

（4）高可用性

單一的計算機系統總會面臨裝置損毀的問題，如CPU，記憶體，主機板，電源，硬碟等，只要一個部件壞掉，這個計算機系統就可能會宕機，無法正常提供服務。在集群系統中，儘管部分硬體和軟體也還是會發生故障，但整個系統的服務可以是7*24小時可用的。

叢集架構技術可以使得系統在若干硬體裝置故障發生時仍可以繼續工作，這樣就將系統的停機時間減少到了最小。集群系統在提高系統可靠性的同時，也大大減小了系統故障帶來的業務損失，目前幾乎100%的網際網路網站都要求7*24小時提供服務。

（5）透明性

多個獨立計算機組成的鬆耦合集群系統構成一個虛擬伺服器。使用者或客戶端程式訪問集群系統時，就像訪問一臺高效能，高可用的伺服器一樣，叢集中一部分伺服器的上線，下線不會中斷整個系統服務，這對使用者也是透明的。

（6）可管理性

整個系統可能在物理上很大，但其實容易管理，就像管理一個單一映像系統一樣。在理想狀況下，軟硬體模組的插入能做到即插即用。

（7）可程式設計性

在集群系統上，容易開發及修改各類應用程式。

叢集的常見分類

負載均衡叢集，簡稱LBC或者LB

高可用性叢集，簡稱HAC --->預防單點也就是高可用

高效能運算叢集，簡稱HPC

網格計算叢集

負載均衡叢集和高可用性叢集是網際網路行業常用的叢集架構模式，也是我們要學習的重點。

負載均衡叢集的作用

分攤使用者訪問請求及資料流量（負載均衡）

保持業務連續性，即7*24小時服務（高可用性）

應用於Web業務及資料庫從庫等伺服器的業務

負載均衡叢集典型的開源軟體包括LVS，Nginx，Haproxy等，如下圖所示

負載均衡叢集。.png-200.1kB

負載均衡叢集介紹

負載均衡叢集為企業提供了更為實用，價效比更高的系統架構解決方案。負載均衡叢集可以把很多客戶集中的訪問請求負載壓力盡可能平均地分攤在計算機叢集中處理。客戶訪問請求負載通常包括應用程式處理負載和網路流量負載。這樣的系統非常適合使用同一組應用程式為大量使用者提供服務的模式，每個節點都可以承擔一定的訪問請求負載壓力，並且可以實現訪問請求在各節點之間動態分配，以實現負載均衡。

負載均衡叢集執行時，一般是通過一個或多個前端負載均衡器將客戶訪問請求分發到後端的一組伺服器上，從而達到整個系統的高效能和高可用性。一般高可用性叢集和負載均衡叢集會使用類似的技術，或同時具有高可用性與負載均衡的特點。

高可用性叢集的作用

當一臺機器宕機時，另外一臺機器接管宕機的機器的IP資源和服務資源，提供服務。

常用於不易實現負載均衡的應用，比如負載均衡器，主資料庫，主儲存對之間。

高可用性叢集常用的開源軟體包括Keepalived，Heartbeat等，其架構圖如下圖所示

高可用性叢集。.png-205.4kB

高可用性叢集介紹

一般是指在叢集中任意一個節點失效的情況下，該節點上的所有任務會自動轉移到其他正常的節點上。此過程並不影響整個叢集的執行。

當叢集中的一個節點系統發生故障時，執行著的叢集服務會迅速作出反應，將該系統的服務分配到叢集中其他正在工作的系統上執行。考慮到計算機硬體和軟體的容錯性，高可用性叢集的主要目的是使叢集的整體服務儘可能可用。如果高可用性叢集中的主節點發生了故障，那麼這段時間內將由備節點代替它。備節點通常是主節點的映象。當它代替主節點時，它可以完全接管主節點（包括IP地址及其他資源）提供服務，因此，使集群系統環境對於使用者來說是一致的，既不會影響使用者的訪問。

高可用性叢集使伺服器系統的執行速度和響應速度會盡可能的快。他們經常利用在多臺機器上執行的冗餘節點和服務來相互跟蹤。如果某個節點失敗，它的替補者將在幾秒鐘或更短時間內接管它的職責。因此，對於使用者而言，叢集裡的任意一臺機器宕機，業務都不會受影響（理論情況下）。

Nginx負載均衡叢集介紹

搭建負載均衡服務的需求

負載均衡叢集提供了一種廉價，有效，透明的方法，來擴充套件網路裝置和伺服器的負載，頻寬和吞吐量，同時加強了網路資料處理能力，提高了網路的靈活性和可用性。

搭建負載均衡服務的需求如下

（1）把單臺計算機無法承受的大規模併發訪問或資料流量分擔到多臺節點裝置上，分別進行處理，減少使用者等待響應的時間，提升使用者體驗。

（2）單個重負載的運算分擔到多臺節點裝置上做並行處理，每個節點裝置處理結束後，將結果彙總，返回給使用者，系統處理能力得到大幅度提高。

（3）7*24小時的服務保證，任意一個或多個有限後面節點裝置宕機，不能影響業務。

在負載均衡叢集中，同組叢集的所有計算機節點都應該提供相同的服務。叢集負載均衡器會截獲所有對該服務的入站請求。然後將這些請求儘可能地平均地分配在所有叢集節點上。

反向代理與負載均衡概念簡介

嚴格地說，Nginx僅僅是作為Nginx Proxy反向代理使用的，因為這個反向代理功能表現的效果是負載均衡叢集的效果，所以本文稱之為Nginx負載均衡。那麼，反向代理和負載均衡有什麼區別呢？

普通負載均衡軟體，例如大名鼎鼎的LVS，其實功能只是對請求資料包的轉發（也可能會改寫資料包），傳遞，其中DR模式明顯的特徵是從負載均衡下面的節點伺服器來看，接收到的請求還是來自訪問負載均衡器的客戶端的真實使用者，而反向代理就不一樣了，反向代理接收訪問使用者的請求後，會代理使用者重新發起請求代理下的節點伺服器，最後把資料返回給客戶端使用者，在節點伺服器看來，訪問的節點伺服器的客戶端使用者就是反向代理伺服器了，而非真實的網站訪問使用者。

一句話，LVS等的負載均衡是轉發使用者請求的資料包，而Nginx反向代理是接收使用者的請求然後重新發起請求去請求其後面的節點。

Nginx是七層結構的,通過nginx本身來轉發,可以有多種方式進行負載均衡,實現的功能多,nginx可以分業務

LVS是四層結構的,通過轉發資料包mac或ip頭部,不能對資料進行修改,來實現的負載均衡,實現的功能少但效率高,LVS的WEB內容都給是一樣的

實現Nginx負載均衡的元件主要有兩個，如下表

負債均衡元件。.png-45.9kB

反向代理與負載均衡搭建

硬體準備

準備3臺VM虛擬機器（有物理伺服器更佳）都需要安裝Nginx服務

Nginx反向代理

NginxWebA

NginxWebB

image_1crp57ne91mjek0c1q9v1js41iahs.png-6.8kB

安裝依賴軟體包

yum -y install openssl openssl-devel pcre pcre-devel

rpm -qa openssl openssl-devel pcre pcre-devel

三臺都需要安裝支援包

image_1crp58vobfo7pno7v71usl9pq19.png-20.2kB

軟體包準備

nginx-1.10.2.tar.gz

image_1crp5ad1rtscc221q9v1hm51j9v1m.png-10.5kB

安裝Nginx服務

useradd -M -s /sbin/nologin nginx

tar xf nginx-1.10.2.tar.gz -C /usr/src

cd /usr/src/nginx-1.10.2

./configure --user=nginx --group=nginx --prefix=/usr/local/nginx --with-http_stub_status_module --with-http_ssl_module && make && make install

ln -s /usr/local/nginx/sbin/* /usr/local/sbin/ --->軟連結可做可不做

egrep -v "#|^$" nginx.conf.default > nginx.conf --->把配置檔案多餘的東西過濾掉

這裡只編譯了一個截圖,三臺虛擬機器的步驟都是一樣的

image_1crp6k368e75d611ho2oud9mm9.png-51.9kB

簡單的Nginx反向代理配置檔案

worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
upstream www_server {
server 192.168.200.68:80 weight=1;
server 192.168.200.69:80 weight=1;
}
server {
listen 80;
server_name sl.yunjisuan.com;
location / {
proxy_pass http://www_server;
}
}
}

配置檔案詳解

#這裡定義Web伺服器池，包含了68，69兩個Web節點
upstream --->伺服器池
www_server --->是伺服器池的名字
server --->就是一個RS節點
weight --->權重,負載均衡是按照權重比分配的
#這裡定義代理的負載均衡域名虛擬主機
proxy_pass --->訪問sl.yunjisuan.com,請求傳送給www_server裡面的

WEBA配置檔案

worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
server_tokens off;
server {
listen 80;
server_name bbs.yunjisuan.com;
location / {
root html/bbs;
index index.html index.htm;
}
}
server {
listen 80;
server_name sl.yunjisuan.com;
location / {
root html/sl;
index index.html index.htm;
}
}
}

WEBB跟WEBA配置檔案是一樣的

填充測試檔案

mkdir /usr/local/nginx/html/{sl,bbs}
echo "`hostname -I ` sl" >> /usr/local/nginx/html/sl/index.html
echo "`hostname -I ` bbs" >> /usr/local/nginx/html/bbs/index.html

WEBB跟WEBA測試檔案是一樣的

新增WEB-A和B虛擬機器本地對映

vim /etc/hosts

cat /etc/hosts

image_1crrauh48kkq1ke212k313vu1ftc1p.png-19.5kB

image_1crrauu0c19j9mhh16q4q083h726.png-19.6kB

配置完兩臺WEB伺服器用curl測試一下

curl sl.yunjisuan.com

curl bbs.yunjisuan.com

image_1crrb5917g3d14li1hhk1k9065l2j.png-16.3kB

image_1crrb5n6nf1b1bh4jj1bqj22m3g.png-16.9kB

檢查兩臺WEB簡單的負載均衡測試結果

curl sl.yunjisuan.com

測試結果可以看出來。兩個Web節點按照1：1的比例被訪問

image_1crrbvs7i1lm79udopc1ti81p553t.png-32.8kB

Nginx upstream模組介紹

Nginx的負載均衡功能依賴於ngx_http_upsteam_module模組，所支援的代理方式包括proxy_pass,fastcgi_pass,memcached_pass等,新版Nginx軟體支援的方式有所增加。本文主要講解proxy_pass代理方式。

ngx_http_upstream_module模組允許Nginx定義一組或多組節點伺服器組，使用時可以通過proxy_pass代理方式把網站的請求傳送到事先定義好的對應Upstream組的名字上，具體寫法為“proxy_pass http:// www_server_pools”,其中www_server_pools就是一個Upstream節點伺服器組名字。ngx_http_upstream_module模組官方地址為：http://nginx.org/en/docs/http/ngx_http_upstream_module.html

基本的upstream配置案例

upstream www_server_pools {
# upstream是關鍵字必須有，後面的www_server_pools為一個Upstream叢集組的名字，可以自己起名，呼叫時就用這個名字
server 192.168.0.223:80 weight=5;
server 192.168.0.224:80 weight=10;
server 192.168.0.225:80 weight=15;
# server關鍵字是固定的，後面可以接域名（門戶會用）或IP。如果不指定埠，預設是80埠。weight代表權重，數值越大被分配的請求越多，結尾有分號，別忘了。
}

較完整的upstream配置案例

upstream blog_server_pool {
server 192.168.0.223; #這行標籤和下行是等價的
server 192.168.0.224:80 weight=1 max_fails=1 fail_timeout=10s; #這行標籤和上一行是等價的，此行多餘的部分就是預設配置，不寫也可以。
server 192.168.0.225:80 weight=1 max_fails=2 fail_timeout=20s backup;
# server最後面可以加很多引數，具體引數作用看下文的表格
}

使用域名及socket的upstream配置案例

upstream backend {
server backend1.example.com weight=5;
server backend2.example.com:8080; #域名加埠。轉發到後端的指定埠上
server unix:/tmp/backend3; #指定socket檔案
#提示：server後面如果接域名，需要內網有DNS伺服器或者在負載均衡器的hosts檔案做域名解析。
server 192.168.0.223;
server 192.168.0.224:8080;
server backup1.example.com:8080 backup;
#備份伺服器，等上面指定的伺服器都不可訪問的時候會啟動，backup的用法和Haproxy中用法一樣
server backup2.example.com:8080 backup;
}

權重比測試

worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
upstream www_server {
server 192.168.200.68:80 weight=5;
server 192.168.200.69:80 weight=1;
}
server {
listen 80;
server_name sl.yunjisuan.com;
location / {
proxy_pass http://www_server;
}
}
}

測試階段多少會有點延遲,所有顯示的會不太準確

image_1crrid56v1apt15b861qrg6dtc8k.png-64.5kB

backup備份測試

worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
upstream www_server {
server 192.168.200.68:80 weight=1 backup;
server 192.168.200.69:80 weight=1;
}
server {
listen 80;
server_name sl.yunjisuan.com;
location / {
proxy_pass http://www_server;
}
}
}

image_1crriptk41a25150i3lm834ba9h.png-40.7kB

image_1crriq7ua4ig1pped9rg7j1brs9u.png-14.5kB

特別提示

如果是兩臺Web伺服器做高可用，常規方案就需要keepalived配合，那麼這裡使用Nginx的backup引數通過負載均衡功能就可以實現Web伺服器叢集了，對於企業應用來說，能做叢集就不做高可用。

upstream模組相關說明

upstream模組的內容應放於nginx.conf配置的http{}標籤內，其預設排程節點演算法是wrr(weighted round-robin，即權重輪詢)。下圖為upstream模組內部server標籤部分引數說明

image_1crrd4dae1loa19ok1h1el1815cm4a.png-433.8kB

提示：
以上引數與專業的Haproxy引數很類似，但不如Haproxy的引數易懂。

示例，如下

upstream backend {
server backend1.example.com weight=5; #如果就是單個Server，沒必要設定權重
server 127.0.0.1:8080 max_fail=5 fail_timeout=10s;
#當檢測次數等於5的時候，5次連續檢測失敗後，間隔10s再重新檢測。
server unix:/tmp/backend3;
server backup1.example.com:8080 backup; #熱備機器設定
}

hash演算法訪問

upstream backend {
ip_hash;
server backend1.example.com;
server backend2.example.com;
server backend3.example.com down;
server backend4.example.com;
}

需要特別說明的是，如果是Nginx代理Cache服務，可能需要使用hash演算法，此時若宕機，可通過設定down引數確保客戶端使用者按照當前的hash演算法訪問，這一點很重要

開啟對後端伺服器的健康檢測

#開啟對後端伺服器的健康檢測，通過GET /test/index.php來判斷後端伺服器的健康情況
server php_server_1 192.168.0.223:80 cookie 1 check inter 2000 rise 3 fall 3 weight 2
server php_server_2 192.168.0.224:80 cookie 2 check inter 2000 rise 3 fall 3 weight 1
server php_server_bak 192.168.0.225:80 cookie 3 check inter 1500 rise 3 fall 3 backup

健康檢測命令詳解

weight:調節伺服器的請求分配權重。
check：開啟對該伺服器健康檢查。
inter：設定連續兩次的健康檢查間隔時間，單位毫秒，預設值2000
rise：指定多少次連續成功的健康檢查後，即可認定該伺服器處於可用狀態。
fall:指定多少次不成功的健康檢查後，即認為伺服器為宕機狀態，預設值3.
maxconn：指定可被髮送到該伺服器的最大併發連線數。

upstream模組排程演算法

排程演算法一般分為兩類：
第一類為靜態排程演算法，即負載均衡器根據自身設定的規則進行分配，不需要考慮後端節點伺服器的情況，例如：rr,wrr,ip_hash等都屬於靜態排程演算法。
第二類為動態排程演算法，即負載均衡器會根據後端節點的當前狀態來決定是否分發請求，例如：連線數少的優先獲得請求，響應時間短的優先獲得請求。例如：least_conn,fair等都屬於動態排程演算法。

（1） rr輪詢（預設排程演算法，靜態排程演算法）

按客戶端請求順序把客戶端的請求逐一分配到不同的後端節點伺服器，這相當於LVS中的rr演算法，如果後端節點伺服器宕機（預設情況下Nginx只檢測80埠），宕機的伺服器會被自動從節點伺服器池中剔除，以使客戶端的使用者訪問不受影響。新的請求會分配給正常的伺服器。

（2）wrr（權重輪詢，靜態排程演算法）

在rr輪詢演算法的基礎上加上權重，即為權重輪詢演算法，當使用該演算法時，權重和使用者訪問成正比，權重值越大，被轉發的請求也就越多。可以根據伺服器的配置和效能指定權重值大小，有效解決新舊伺服器效能不均帶來的請求分配問題。

（3）ip_hash（靜態排程演算法）（會話保持）

每個請求按客戶端IP的hash結果分配，當新的請求到達時，先將其客戶端IP通過雜湊演算法雜湊出一個值，在隨後的客戶端請求中，客戶IP的雜湊值只要相同，就會被分配至同一臺伺服器，該排程演算法可以解決動態網頁的session共享問題，但有時會導致請求分配不均，即無法保證1：1的負載均衡，因為在國內大多數公司都是NAT上網模式，多個客戶端會對應一個外部IP，所以，這些客戶端都會被分配到同一節點伺服器，從而導致請求分配不均。LVS負載均衡的-p引數，Keepalived配置裡的persistence_timeout 50引數都類似這個Nginx裡的ip_hash引數，其功能都可以解決動態網頁的session共享問題。

當負載排程演算法為ip_hash時，後端伺服器在負載均衡排程中的狀態不能有weight和backup，即使有也不會生效。

upstream yunjisuan_lb{
ip_hash;
server 192.168.0.223:80;
server 192.168.0.224:8080;
}
upstream backend{
ip_hash;
server backend1.example.com;
server backend2.example.com;
server backend3.example.com down;
server backend4.example.com;
}

（4）fair（動態排程演算法）

此演算法會根據後端節點伺服器的響應時間來分配請求，響應時間短的優先分配。這是更加智慧的排程演算法。此種演算法可以根據頁面大小和載入時間長短智慧地進行負載均衡，也就是根據後端伺服器的響應時間來分配請求，響應時間短的優先分配。Nginx本身不支援fair排程演算法，如果需要使用這種排程演算法，必須下載Nginx相關模組upstream_fair。

upstream yunjisuan_lb{
server 192.168.0.223;
server 192.168.0.224;
fair;
}

（5）least_conn(最小連線)

least_conn演算法會根據後端節點的連線數來決定分配情況，哪個機器連線數少就分發。
除了上面介紹的這些演算法外，還有一些第三方排程演算法，例如：url_hash,一致性hash演算法等，介紹如下。

（6）url_hash演算法(web快取節點)

與ip_hash類似，這裡是根據訪問URL的hash結果來分配請求的，讓每個URL定向到同一個後端伺服器，後端伺服器為快取伺服器時效果顯著。在upstream中加入hash語句，server語句中不能寫入weight等其他的引數，hash_method使用的是hash演算法。

url_hash按訪問URL的hash結果來分配請求，使每個URL定向到同一個後端伺服器，可以進一步提高後端快取伺服器的效率命令率。Nginx本身是不支援url_hash的，如果需要使用這種排程演算法，必須安裝Nginx的hash模組軟體包。

upstream yunjisuan_lb {
server squid1:3128;
server squid2:3128;
hash $request_uri;
hash_method crc32;
}

（7）一致性hash演算法(Nginx沒有)

一致性hash演算法一般用於代理後端業務為快取服務（如Squid，Memcached）的場景，通過將使用者請求的URI或者指定字串進行計算，然後排程到後端的伺服器上，此後任何使用者查詢同一個URI或者指定字串都會被排程到這一臺伺服器上，因此後端的每個節點快取的內容都是不同的，一致性hash演算法可以解決後端某個或幾個節點宕機後，快取的資料動盪最小，一致性hash演算法知識比較複雜，詳細內容可以參考百度上的相關資料，這裡僅僅給出配置示例

http {
upstream test {
consistent_hash $request_uri;
server 127.0.0.1:9001 id=1001 weight=3;
server 127.0.0.1:9002 id=1002 weight=10;
server 127.0.0.1:9003 id=1003 weight=20;
}
}

雖然Nginx本身不支援一致性hash演算法，但Nginx得分支Tengine支援。詳細可參考http://tengine.taobao.org/document_cn/http_upstream_consistent_hash_cn.html

http_proxy_module模組

proxy_pass指令介紹

proxy_pass指令屬於ngx_http_proxy_module模組，此模組可以將請求轉發到另一臺伺服器，在實際的反向代理工作中，會通過location功能匹配指定的URI，然後把接收到的符合匹配URI的請求通過proxy_pass拋給定義好的upstream節點池。該指令官方地址1見：http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass

proxy_pass的使用案例

（1）將匹配URI為name的請求拋給http://127.0.0.1/remote/

location /name/ {
proxy_pass http://127.0.0.1/remote/;
}

（2）將匹配URI為some/path的請求拋給http://127.0.0.1

location /some/path/ {
proxy_pass http://127.0.0.1;
}

（3）將匹配URI為name的請求應用指定的rewrite規則，然後拋給

相關推薦

 Nginx反向代理與負載均衡。

Nginx反向代理與負載均衡叢集簡介簡單地說，叢集就是指一組（若干個）相互獨立的計算機，利用高速通訊網路組成的一個較大的計算機服務系統，每個叢集節點（即叢集中的每臺計算機）都是執行各自服務的獨立伺服器。這些伺服器之間可以彼此通訊，協同向用戶提供應用程式，系統資源和資料，並以

【Web】Nginx 反向代理與負載均衡

連接代理服務器 body 後端服務 style 執行 class redirect 配置文件反向代理　　反向代理（Reverse Proxy）方式是指以代理服務器來接受internet上的連接請求，然後將請求轉發給內部網絡上的服務器，並將從服務器上得到的結果返回給in

Nginx反向代理與負載均衡

宋體 static initial connect make man perf 為什麽腳本第1章 Nginx反向代理與負載均衡1.1 集群簡介若要用一句話描述集群，即一堆服務器合作做同一件事為什麽要使用集群1）高性能2）價格有效性3）可伸縮性（Scalability）

Nginx反向代理與負載均衡應用實踐

Nginx反向代理與負載均衡應用實踐課堂筆記一、原理 1.1 為什麼要使用叢集（1）高效能一些國家重要的計算密集型應用（如天氣預報，核試驗模擬等），需要計算機有很強的運算處理能力。以全世界現有的技術，即使是大型機，其計算能力也是有限的，很難單獨

Linux 下 nginx反向代理與負載均衡

前面幾篇記錄下nginx的基本運功，代理伺服器的訪問，這裡來試驗下nginx的反向代理。反向代理（Reverse Proxy）方式是指以代理伺服器來接受internet上的連線請求，然後將請求轉發給內部網路上的伺服器，並將從伺服器上得到的結果返回給internet上請求連線的客戶端，此時

nginx反向代理與負載均衡的配置

說到反向代理首先先大家普及下什麼是反向代理. 反向代理（Reverse Proxy）方式是指以代理伺服器來接受internet上的連線請求，然後將請求轉發給內部網路上的伺服器，並將從伺服器上得到的結果返回給internet上請求連線的客戶端，此時代理伺服器對外就表現為一個反向代理

Linux系統——Nginx反向代理與負載均衡

叢集叢集是指一組（若干個）相互獨立的計算機，利用高速通訊網路組成的一個較大的計算機服務系統，每個叢集節點（即叢集中的每臺計算機）都是運用各自服務的獨立伺服器。這些伺服器之間可以彼此通訊，協同向用戶提供應用程式，系統資源和資料，並以單一系統的模式加以管理。當用戶客戶機請求集群系統時，叢集給使用者的感覺就是一個單

分散式架構——Nginx 反向代理與負載均衡

訪問請移步至(David’s Wikipedia) https://www.qingdujun.com/ ，這裡有能“擊穿”平行宇宙的亂序並行位元組流… 原文地址：https://www.qingdujun.com/zh-CN/nginx-proxy-loadbalancing.h

Nginx反向代理與負載均衡：節點伺服器單/多虛擬機器配置+實驗環境搭建+原理解析

.說明常見的叢集架構及相關軟體，可以參考下面的導圖：網際網路企業常用的是負載均衡叢集和高可用性叢集，負載均衡叢集強調“分擔”，通過一定的排程演算法，可以實現用多個節點伺服器來分擔使用者的訪問請求和資料流量；高可用性叢集

一篇文章搞定 Nginx 反向代理與負載均衡

## 代理　　　　要想弄明白反向代理，首先要知道啥是正向代理，要搞懂正向代理只需要知道啥是代理即可。代理其實就是一箇中介，在不同事物或同一事物內部起到居間聯絡作用的環節。比如買票黃牛，房屋中介等等。　　在網際網路中代理更多指的是代理伺服器，代理伺服器位於客戶端和伺服器之間，它充當兩者之間的中介。這

Nginx 反向代理、負載均衡與動靜分離

nginx1、環境：前端Nginx服務器：主機名：server1 IP：172.25.80.1 編譯安裝nginx1..12 後端tomcat： Server2--ip：172.25.80.2 主機名：server2 Server3--ip：172.25.80.3 主機名:server32、Ng

實踐NGINX的反向代理與負載均衡

nginx源碼安裝實踐NGINX的反向代理與負載均衡安裝nginx過程 [root@lb01 opt]# yum install pcre-devel openssl-devel -y [root@lb01 opt]# wget -q http://nginx.org/download/nginx-1.1

nginx反向代理、負載均衡配置與linux環境下的安裝及通過ip和域名訪問nginx

本文主題：一、什麼是nginx 二、nginx的應用場景三、linux環境下nigix的安裝四、nginx配置虛擬機器（ip、域名）五、nginx實現反向代理六、nginx實現負載均衡一、什麼是nginx 1、http伺服器（通過nginx配置檔案配置

Nginx+Tomcat反向代理，負載均衡。

2. 與Apache伺服器對比。 Nginx相對於apache的優點：輕量級，同樣為web伺服器，比apache佔用更少的資源，抗併發，nginx處理請求是非同步非阻塞的，而apache是阻射型的，在高併發下nginx能保持低資源低消耗高效能，高

Nginx快速入門(二)反向代理與負載均衡

接下來我們將介紹Ngix 反向代理、負載均衡、HTTP伺服器（包含動靜分離）、正向代理等幾個方面,由於本人接觸使用也沒有多久,所以還會有很多不全以及錯誤的地方，還望大家指正共同進步。 1.反向代理反向代理（Reverse Proxy）方式是指以代理伺服器來接受intern

nginx的反向代理與負載均衡

1、概念：正向代理：客戶端明確被訪問伺服器反向代理：客戶端不清楚被訪問伺服器，只清楚代理伺服器負載均衡 2、nginx負載均衡的實現

(Nginx+Apache）實現反向代理與負載均衡

1、概念實現這個反向代理能力並不能算是一個特別複雜的任務，但是在負載均衡中要求特別高的效率，這樣實現起來就不是十分簡單的了。每針對一次代理，代理伺服器就必須開啟兩個連線，一個為對外的連線，一個為對內的連線，因此對於連線請求數量非常大的時候，代理伺服器的負載也就非常之大了，在最後反向代理伺服器會成為服務的瓶

Nginx------什麼是反向代理與負載均衡

什麼是反

Nginx+Tomcat實現反向代理與負載均衡入門

【1】反向代理反向代理（Reverse Proxy）方式是指以代理伺服器來接受internet上的連線請求，然後將請求轉發給內部網路上的伺服器，並將從伺服器上得到的結果返回給internet上請求連線的客戶端，此時代理伺服器對外就表現為一個伺服器，該伺服器就

Nginx反向代理和負載均衡部署指南

命令 eva http ddr cli 僅支持新版 ive app nginx不單能夠作為強大的webserver，也能夠作為一個反向代理server，並且nginx還能夠依照調度規則實現動態、靜態頁面的分離。能夠依照輪詢、ip哈希、URL哈希、權重等多種