Nginx反向代理

二級域名系統

顧名思義，我們有很多的這個不同的二級域名的用戶來訪問我們，比如說微博。它有一個主域名weibo.com。如果我叫一鳴,申請了一個微博，然后我就可以在微博這個主系統上申請一個二級域名來訪問我微博的主頁，具體實現需要在服務器上把域名的泛解析全部都解析到當前的一臺nginx服務器上，nginx可以通過反向代理，把所有的請求轉發到后端的另外一臺業務服務器，業務服務器拿到這個域名拆解字符串，把這個二級域名取出來，再從數據庫里去查詢它的信息并展示相應的內容，當然這個域名在數據庫里邊要存儲，并且它是唯一的。

短網址的實現

比如現在有短網址dwz.cn/dskn1267，當用戶訪問的時候，它會幫我們去跳轉到一個真實的網址。短網址系統里先得有一個數據庫。db會存儲用戶提交上來的短網址和真實地址的映射。最簡單來說，后綴可以用uuid。uuid返回作為key，真實的地址作為value。全部都存在數據庫里。當用戶訪問到我們的系統的時候，訪問到 nginx。nginx通過反向代理，把請求打到后端的應用服務器上。應用服務器獲取到用戶請求的完整的URL，取到之后我們拆分這串字符串，然后去數據庫里去去匹配，拿到真實的地址之后，redirect用戶訪問的這個地址就被轉向了

http DNS

http DNS一般來說不適合瀏覽器來使用，一般都是給手機的這個APP或者是基于CS架構的，比較適用于http dns，它可以在軟件里邊預埋幾個IP地址，這幾個IP地址就是我們的nginx服務器IP地址。在系統啟動之后。APP會向這個IP去發起請求，請求某一個域名的真實的IP地址是什么。那我們的系統接到這個請求之后，參數讀到域名返回這個IP地址。

Nginx隧道式模型 網關、代理與反向代理

反向代理

用戶在訪問我們的系統的時候，通過互聯網，然后打到機房的這個網關路由上。他會把這個請求轉發到具體的一臺服務器上，在這個過程當中，我們的網關肯定是能把網絡請求打到我們的 nginx 服務器上，它作為反向代理服務器的話，它需要把用戶所有的請求全部轉發到我們后端的應用服務器，相應的結果再反饋給 nginx在傳遞給用戶，這樣就叫反向代理。

正向代理
用戶主動的想要去上網。透過這個代理服務器才能訪問到我們的這個外網。那這個代理服務器就稱之為叫正向代理服務器。比如socket 代理服務器，HTTP 代理服務器啊，

正向代理和反向代理對比起來的區別只是我們所在的角度不一樣，

網關指的在我們去訪問互聯網的時候，假如說你拿手機連上了自己家里的路由器，那我就需要去把所有的數據包全部都發送給這個路由器。然后由路由器轉發，請求給我們的這個下一跳的這個網絡，那我們接觸到的第一個呃路由就是我們家里這個路由器，就是我們的網關。

網關就是訪問我們網絡的入口

特點就是它所有的請求都得轉發。都得經過網關.

應用場景

反向代理服務器在我們的系統架構當中的一些應用場景
這是傳統項目當中的這個系統架構圖，前面是用戶，然后經過自己的網絡，然后域名解析，經過互聯網，然后打到機房內部的這個網關。到這個網關的時候，會中轉請求在這里邊呢，還會有防火墻。

那 nginx在這就起到了反向代理的作用，用戶想要訪問內網的任何資源，都必須得通過我這個反向代理服務器。

backend server 就是這個我們的后端的服務器，那 gateway server是網關路由服務器，在里邊會有很多這種其他的業務服務器，比如說管理用戶注冊登錄，管理這個商品。價格，管理庫存，然后展示商品等等。有數據庫服務器測試用的服務器文件，存儲服務器，一些邏輯業務服務器，還有這個保證高可用的 ha server服務器，還有這個權限管理的服務器。這 gateway 服務器是把所有的這個業務服務器統一的管理起來，在中間起到了尋找的作用啊，
還有權限服務器,鑒權的作用并不是說所有的請求都能訪問某些服務的，你需要經過這個 gateway路由服務器去做一次權限認證，也就是我們這個所有的業務邏輯是放在后端tomcat 上跑。然后這個 nginx 只做這個業務中轉請求中轉，所有的請求全都打到我們的后端服務器上，這是最簡單的應用，也是最傳統的應用技術架構，比較適合小型項目，傳統項目以及這個傳統的互聯網項目，像傳統項目的一些 ERP、 CRM 、CMS 等等，這些雖然看起來非常龐大，動不動的一個壓縮包。就有一兩個G大小的這種源代碼，看起來非常龐大，但是它的這個并發量其實并不高，如果并發量并不是特別高的話。尤其是給一些內網用戶使用的話啊，那我們這種直接代理過去就可以了。

在接觸到這種中小型互聯網項目的時候，nginx 作為反向代理服務器，它要起到更多的功能了，比如說我要幫我們去偽裝一下當前訪問的這個地址真實地址，比如想要請求這個item?serviceid=100，這請求呢 URL 打給本來是要給tomcat 的，你直接給了 nginxnginx 能把這個請求直接給我轉發過去，讓用戶正常訪問，這是沒有問題的，
但是這種暴露 URL 的缺點,其實也是無關大雅的，但是有時候讓人看起來好像并不是那么高級，那我們可以把它換成一種展現形式，
比如說/item/100，這 service 其實我沒必要暴露給用戶,不需要讓他知道這是一個什么服務，
然后 ID也不需要讓他去傳遞了，這樣看起來更好記一些。
這是 URL rewrite 這個功能，可以把原本這個 URL 呢，給它變成這個/item/100，也就用戶在請求這個請求這個 URL 的時候呢。通過 nginx 可以幫我們去轉換成真實的 URL，然后把這真實的URL再轉發給我們后端的服務器。
這樣做還有另外一個好處，就是面向于一些搜索引擎，它可能會看起來你這是一個獨立的頁面。它權重會更高一些。
然后 nginx 在這里邊不光是起到反向代理的作用，還可以起到一些額外的這些功能上，業務邏輯上的作用，比如說。轉發一下這個請求，改變一下URL，那這是對于業務邏輯的這種轉發，

業務的數據包不會特別大，比如說我就想要一個 json 數據。我就想是提交一下呃，我修改的密碼，這份數據那幾 k 大小也就夠了，所以在這 nginx 比較能扛，它可能一臺 nginx 后邊對應了數十臺這個業務邏輯服務器。
那 如果nginx 后邊代理的是文件服務器，同樣是業務邏輯轉發，那轉發到我們的 nginx 上之后， nginx 后邊代理的是文件服務器，那這時候的 nginx 很明顯就成了瓶頸了。
因為你后端的數據存儲服務器的存儲的是非常非常多的這種數據，而且數據非常大，比如說一些電影，一些軟件啊非常大的這種數據包那它在傳這個傳遞數據的時候，
nginx 就會成為網絡的瓶頸。那么如果你想要用 nginx 做反向代理的話，那你就得多配一些 nginx，然后去分組去代理就可以了。

負載均衡

負載均衡就是訪問到一個這個服務器，一旦它不可用的時候，它可以把故障轉移到另外一臺服務器。

反向代理

proxy_pass http://baidu.com;

location / {proxy_pass http://baidu.com/;# proxy_pass root 二選一
}

基于反向代理的負載均衡

worker_processes  1;events {worker_connections  1024;
}http {include       mime.types;default_type  application/octet-stream;sendfile        on;keepalive_timeout  65;upstream httpds { # httpds 隨意定義 server 192.168.1.102:80;server 192.168.1.103:80;}server {listen       80;server_name  localhost;location / {proxy_pass http://httpds;# root   vod;# index  index.html index.htm;}error_page   500 502 503 504  /50x.html;location = /50x.html {root   html;}}
}

負載均衡策略

輪詢

默認情況下使用輪詢方式，逐一轉發，這種方式適用于無狀態請求。

weight(權重)

指定輪詢幾率，weight和訪問比率成正比，用于后端服務器性能不均的情況。

upstream httpds {server 127.0.0.1:8050 weight=10 down;server 127.0.0.1:8060 weight=1;server 127.0.0.1:8060 weight=1 backup;}

down：表示當前的server暫時不參與負載

weight：默認為1.weight越大，負載的權重就越大。

backup： 其它所有的非backup機器down或者忙的時候，請求backup機器。

ip_hash

根據客戶端的ip地址轉發同一臺服務器，可以保持回話。

least_conn

最少連接訪問

url_hash

根據用戶訪問的url定向轉發請求

fair

根據后端服務器響應時間轉發請求