Nginx正向代理和反向代理

關於代理

說到代理，首先咱們要明確一個概念，所謂代理就是一個表明、一個渠道；

此時就設計到兩個角色，一個是被代理角色，一個是目標角色，被代理角色經過這個代理訪問目標角色完成一些任務的過程稱爲代理操做過程；例如生活中的專賣店，客人到華爲旗艦店買了一部華爲P30 Pro，這個旗艦店就是代理，被代理角色就是華爲廠商，目標角色就是用戶。

 1、正向代理

在現在的網絡環境下，咱們若是因爲技術須要要去訪問國外的某些網站，此時你會發現位於國外的某網站咱們經過瀏覽器是沒有辦法訪問的，此時你們可能都會用一個操做FQ進行訪問，FQ的方式主要是找到一個能夠訪問國外網站的代理服務器，咱們將請求發送給代理服務器，代理服務器去訪問國外的網站，而後將訪問到的數據傳遞給咱們。

上述這樣的代理模式稱爲正向代理，正向代理最大的特色：

1. 客戶端很是明確要訪問的服務器地址；
2. 服務器只清楚請求來自哪一個代理服務器，而不清楚來自哪一個具體的客戶端；
3. 正向代理模式屏蔽或者隱藏了真實客戶端信息。

2、反向代理

客戶端給服務器發送的請求，nginx服務器接收到以後，按照必定的規則分發給了後端的業務處理服務器進行處理了。此時請求的來源也就是客戶端是明確的，可是請求具體由哪臺服務器處理的並不明確了，nginx扮演的就是一個反向代理角色。

反向代理，主要用於服務器集羣分佈式部署的狀況下，反向代理隱藏了服務器的信息。

3、應用場景

 

 

 

4、負載均衡

咱們已經明確了所謂代理服務器的概念，那麼接下來，nginx扮演了反向代理服務器的角色，它是以依據什麼樣的規則進行請求分發的呢？不用的項目應用場景，分發的規則是否能夠控制呢？

這裏提到的客戶端發送的、nginx反向代理服務器接收到的請求數量，就是咱們說的負載量

請求數量按照必定的規則進行分發到不一樣的服務器處理的規則，就是一種均衡規則

因此，將服務器接收到的請求按照規則分發的過程，稱爲負載均衡。

負載均衡在實際項目操做過程當中，有硬件負載均衡和軟件負載均衡兩種。

硬件負載均衡也稱爲硬負載，如F五、NetScaler：

侷限：相對造價昂貴成本較高，一套設備最起碼得上百萬，

優勢：可是數據的穩定性安全性等等有很是好的保障，如中國移動中國聯通這樣的公司纔會選擇硬負載進行操做；

軟件負載均衡也稱爲軟負載，如LVS、Nginx、HAProxy：

更多的公司考慮到成本緣由，會選擇使用軟件負載均衡，軟件負載均衡是利用現有的技術結合主機硬件實現的一種消息隊列分發機制

nginx支持的負載均衡調度算法方式以下：

1. weight輪詢（默認）：接收到的請求按照順序逐一分配到不一樣的後端服務器，即便在使用過程當中，某一臺後端服務器宕機，nginx會自動將該服務器剔除出隊列，請求受理狀況不會受到任何影響。 這種方式下，能夠給不一樣的後端服務器設置一個權重值（weight），用於調整不一樣的服務器上請求的分配率；權重數據越大，被分配到請求的概率越大；該權重值，主要是針對實際工做環境中不一樣的後端服務器硬件配置進行調整的。
2. ip_hash（大部分使用此算法）：每一個請求按照發起客戶端的ip的hash結果進行匹配，這樣的算法下一個固定ip地址的客戶端總會訪問到同一個後端服務器，這也在必定程度上解決了集羣部署環境下session共享的問題。
3. fair：智能調整調度算法，動態的根據後端服務器的請求處理到響應的時間進行均衡分配，響應時間短處理效率高的服務器分配到請求的機率高，響應時間長處理效率低的服務器分配到的請求少；結合了前二者的優勢的一種調度算法。可是須要注意的是nginx默認不支持fair算法，若是要使用這種調度算法，請安裝upstream_fair模塊
4. url_hash（極少數使用此算法）：按照訪問的url的hash結果分配請求，每一個請求的url會指向後端固定的某個服務器，能夠在nginx做爲靜態服務器的狀況下提升緩存效率。一樣要注意nginx默認不支持這種調度算法，要使用的話須要安裝nginx的hash軟件包

👉趕忙戳這看看真實案例叭