Nginx反向代理和負載均衡（後端複習）

Nginx反向代理和負載均衡（後端複習）

一，Nginx基礎

1.Nginx簡介

nginx是一個開源高性能，可靠的http中間件，代理服務。它是一個web服務器，能夠用做反向代理，負載均衡器和http緩存

2.Nginx由來

早期

一個網站的初期，訪問的流量比較小，選用的架構可能就是用戶經過域名，通過域名解析，拿到後端服務器的IP地址，直接訪問這個ip對應的Tomcat服務器。

發展

隨着用戶流量的增大，一臺Tomcat服務器沒法知足用戶的請求，人們會想到兩個辦法：

• 垂直擴展：升級服務器硬件（成本高）
• 水平擴展：增長新的服務器來分擔流量（DNS服務器難以管理這麼多的ip）
  • 後端的某臺機器宕機後，DNS 服務器不知道該機器宕機，仍然解析到了這個 IP，若是用戶訪問到了這個宕機的 IP，那麼系統沒法爲用戶提供服務；
  • DNS 服務器配置新的 IP 後，它不會當即生效，那麼在它生效的這個時間段，新加的服務器不會爲用戶提供服務。

反向代理和負載均衡

如今，用戶經過域名訪問，DNS服務器返回反向代理服務器的IP，反向代理服務器根據被代理服務器的IP配置和負載均衡策略，轉發用戶的請求到不一樣的後端服務器處理，後端服務器將處理結果響應給反向代理服務器，在經過反向代理服務器反映給用戶。這就是nginx所要作的.

集羣

隨着流量的繼續增大，單臺反向代理服務器成爲了瓶頸，咱們就會對其作集羣，解決高性能的問題，對其作主備解決高可用的問題。

二，Nginx反向代理實現

1.正向代理和反向代理

正向代理

• 正向代理隱藏了真實的客戶端，服務端不知道是哪一個客戶端請求服務端，雖然客戶端是經過代理服務器請求的服務端，可是由於服務端只知道是代理服務器的請求，因此，正向代理能夠將真實客戶端和代理服務器整個當作一個客戶端

反向代理

• 反向代理則和正向代理相反，在反向代理中，客戶端不知道請求的服務端是誰，只知道是代理服務器帶來的響應，因此在反向代理中，能夠將服務端和代理服務器總體當作是服務端。

2.反向代理實例

啓動Tomcat8080端口

將本機ip加監聽端口的請求轉發到8080端口

server {
        listen       8082;  #監聽端口
        
        #server_name  localhost;

		location / {
            proxy_pass   http://127.0.0.1:8080;
			proxy_set_header Host $host;
			index  index.html index.htm index.jsp;
        }
複製代碼

三，Nginx負載均衡實現

1.什麼是負載均衡？

負載均衡就是用戶經過（IP）訪問入口訪問nginx服務器，nginx服務器經過負載均衡策略將請求分發到某一個後端Tomcat服務器

2. 負載均衡如何選擇要轉發的後端服務器

• 第一個就是確保所選擇的後端服務器是正常工做的，能給對用戶的請求作出響應

• 第二個就是根據負載均衡算法從健康服務器池中進行選擇。

3.負載均衡算法

在具體談負載均衡算法時，咱們先了解下nginx中的upstream模塊中的參數

upstream test.net{
   #ip_hash;
     server 127.0.0.1:8082;
     server 127.0.0.1:8080;
    #server 127.0.0.1:8080 down;
    #server 127.0.0.1:8080 backup;
}
複製代碼

在upstream模塊中配置的是server即後端服務器列表，上邊我配置了兩個，是同一ip下的（條件不容許我，也沒去弄虛擬機，願體諒）

- down：配上down的server不參與負載均衡
- weight：權重，weight越大的，權重越大
- backup：其餘所有的非backup機器忙或者down的時候，才請求backup機器，backup 不能和ip_hash一塊兒使用
- ip_hash：使用ip哈希負載均衡算法,weight\backup 不能和 ip_hash 關鍵字一塊兒使用。
-  least_conn 最少鏈接數
複製代碼

• 輪詢：

爲第一個請求選擇健康池中的第一個後端服務器，而後按順序日後依次選擇，直到最後一個，而後循環。 沒必要關心服務器實際的鏈接數和當前的系統負載

​ 正常狀況下沒配置，默認是輪詢算法

upstream test.net{
     server 127.0.0.1:8082;
     server 127.0.0.1:8080;
}
複製代碼

• ip_hash：

根據請求源的 IP 的散列（hash）來選擇要轉發的服務器。這種方式能夠必定程度上保證特定用戶能鏈接到相同的服務器。若是你的應用須要處理狀態而要求用戶能鏈接到和以前相同的服務器，能夠考慮採起這種方式。（同一ip地址的客戶端，當後端服務器列表不變時，他每次都會映射到同一臺後端服務器進行訪問）

upstream test.net{
     ip_hash;
     server 127.0.0.1:8082;
     server 127.0.0.1:8080;
}
複製代碼

• 最小鏈接優先：

優先選擇鏈接數最少，也就是壓力最小的後端服務器，在會話較長的狀況下能夠考慮採起這種方式。

upstream test.net{
     least_conn;
     server 127.0.0.1:8082;
     server 127.0.0.1:8080;
}
複製代碼

• 隨機分配：

  經過系統的隨機算法，隨機從後端服務器列表選取一臺服務器進行訪問

• 加權輪詢：

  根據給後端服務器分配的比重不一樣，nginx在分配請求時會根據權重不一樣，把配置高，負載低的機器配置更高的權重，讓這些機器處理更多的請求，讓配置低，負載高的機器分配的權重低，處理的請求少。 將請求順序且按照權重分配到後端。

  upstream test.net{
       server 127.0.0.1:8082 weight=3;
       server 127.0.0.1:8080 weight=1;
  }
  複製代碼

• 加權隨機：

  與加權輪詢法同樣，加權隨機法也根據後端機器的配置，系統的負載分配不一樣的權重。不一樣的是，它是按照權重隨機請求後端服務器，而非順序。

4.實例

upstream www.kevin.com {
         server 127.0.0.1:8082 weight=3;
         server 127.0.0.1:8080 weight=1;
     }


    server {
        listen       80;  #監聽端口
        
        #server_name  localhost;

		location / {
             proxy_pass   http://www.kevin.com;
			proxy_set_header Host $host;
			index  index.html index.htm index.jsp;
        }
複製代碼

啓動一個springboot項目，內置Tomcat是8082端口，由於這是個原先的項目，我直接用來nginx測試，待會若是看到報錯500是由於請求須要token，可是看到這個以後，證實分到了這個端口

在開啓8080的tomacat

​ 在瀏覽器使用本機ip加監聽端口訪問，nginx會根據權重輪詢，分發請求

第一次請求：

第二次請求：

第三次請求：