【從單體架構到分散式架構】（三）請求增多，單點變叢集(2)：Nginx

會點程式碼的大叔發表於2020-06-14
架構分散式Nginx
上一個章節，我們學習了負載均衡的理論知識，那麼是不是把應用部署多套，前面掛一個負載均衡的軟體或硬體就可以應對高併發了？其實還有很多問題需要考慮。比如：

1. 當一臺伺服器掛掉，請求如何轉發到其他正常的伺服器上？
2. 掛掉的伺服器，怎麼才能不再訪問？
3. 如何保證負載均衡的高可用性？

等等等等...

讓我們帶著這些問題，實戰學習一下 Nginx 的配置和使用。

1. 前置概念

在正式介紹 Nginx 之前，首先讓我們先了解一下概念。

1. 中介軟體

幹 IT 太累了，我準備辭職開了個燒烤攤，賣羊肉串；

賣羊肉串首先就得有羊肉，於是我就聯絡了很多養殖場，我又是一個比較負責任的人，為了保證羊肉的質量，我就去考察了一家又一家養殖場，同時我也是個“小氣”的人，所以我考察過程中，和對方談判、比價，最終選了一個養殖場作為我的羊肉供應商，為我提供羊肉。

經營了一陣子，這個養殖場提供的羊肉質量沒有以前好了，那麼我就重新考察、談判、比價，如此反覆，我投入了大量的時間和精力。

於是我找到了一個信得過的代理公司，約定要羊肉的質量和數量，談好價錢，以後我只找代理商拿貨，具體代理商找的哪家養殖場我不去過問，甚至代理商可以送貨上門。

在這個例子裡面，賣燒烤就是業務，我的燒烤攤是業務端，養殖場是底層，而 這個信得過的代理公司，就是中介軟體。

2. 正向代理和反向代理

正向代理：我住在北京，但是想回老家買套房，但是我沒辦法親自回老家考察，於是我就派我的管家回老家考察；管家就是正向代理伺服器；正向代理伺服器代表了客戶端，在正向代理的過程中，服務端只和代理伺服器打交道（房東只和我的管家談），並不知道真正的客戶端是誰。

正向代理

反向代理：我住在北京，但是想回老家買套房，但是我沒辦法親自回老家考察，於是我打個電話聯絡了老家的房屋中介去辦這件事兒；房屋中介就是反向代理；這裡的反向代理，代表的是房東，在反向代理的過程中，客戶端只和反向代理伺服器打交道，並不知道真正的服務端是誰。

反向代理

當然，我的管家也可以聯絡我老家的房屋中介，那麼架構圖就會變成：

2. Nginx 的概念

瞭解完上面的幾個概念，那麼 Nginx 的概念理解起來就簡單很多了：

Nginx 就是一個開源的、高效能的、可靠的 Http 中介軟體； 它經常被用作 Http 代理、反向代理、負載均衡等等，當然它也能做正向代理，但是實際很少有這麼用的。

3. 最簡單的 Nginx 使用示例

本章節專案的程式碼：chapter3

Step 1. 部署多套環境

我們將章節 1 中的專案 chapter1 複製出來一份，改名為 chapter3，表示是第 3 章節的專案，同時修改：

1. pom.xml 中的 artifactId 修改為 chapter3
2. application.yml 中的 server.port 修改成 8089

這樣我們分別啟動 chapter1 和 chapter3，這樣就相當於把相同的專案部署了兩套，埠分別是 8088 和 8089 。

Step 2. 下載 Nginx

我們可以在 Nginx 的官網 下載我們所需的版本，因為我使用 windows 環境開發，所以我在這裡就選擇了 nginx/Windows-1.14.2 這個版本。

下載完成解壓縮，不需要額外的安裝，可以直接使用。

Step 3. 配置 Nginx

進入 nginx-1.14.2\conf 目錄下，用文字編輯器開啟 nginx.conf，對配置檔案進行如下修改：

1. 在 http 中增加 upstream，並配置兩臺環境的地址；
2. 在 http.server.location 中增加 proxy_pass 的配置；

http {
    ...

    #增加 upstream 的配置，其中 myserver 是自己起的名字
    upstream myserver{
	     server 127.0.0.1:8088;  #有幾套環境，就配置幾條
	     server 127.0.0.1:8089;
    }

    server {
        listen       80;
        server_name  localhost;

        #charset koi8-r;

        #access_log  logs/host.access.log  main;

        location / {
            root   html;
            index  index.html index.htm;
            proxy_pass  http://myserver; #增加，其中 http://myserver 的 myserver 要和上文對應
        }

      }
    }
    ...
}

完整配置檔案請參考：nginx.conf

Step 4. 啟動 Nginx

我們可以直接雙擊 nginx-1.14.2 目錄下的 nginx.exe 啟動；也可以通過 cmd 命令開啟控制檯，進入 nginx-1.14.2 目錄執行如下命令啟動 Nginx：

start nginx //啟動 Nginx ；啟動後可能一閃而過，我們可以看一下工作管理員是否有名字叫做 nginx.exe 的程式

nginx.exe -s stop //停止 Nginx
nginx.exe -s quit //停止 Nginx

nginx-start

Step 5. 測試 Nginx

讓我們測試一下 Nginx 是否配置並啟動成功，開啟瀏覽器輸入：

http://127.0.0.1/queryAdmin

注意這裡並沒有加埠號，是因為 url 中沒有埠號的時候表示埠號為 80，而我們 Nginx 的配置檔案中，監聽的正是 80 埠 (listen 80)；我們可以在瀏覽器中看到服務返回的結果：

User : Admin

這就說明 Nginx 已經轉發了我們的請求到了服務端，並正確返回，那麼負載均衡是如何體現的呢？讓我們多重新整理幾次瀏覽器，然後看看後臺日誌：

console

我前後一共呼叫了 5 次服務，可以看到兩個服務端分別接收到了 2 次和 3 次請求，負載均衡達到了效果。

4. Nginx 常見的路由策略

1. 輪詢法

最簡單的輪詢法，多餘的配置不需要增加。

upstream myserver{
   server 127.0.0.1:8088;  # 有幾套環境，就配置幾條
   server 127.0.0.1:8089;
}

2. 源地址雜湊法

使用 ip_hash 關鍵字，每一個請求，都按 hash(IP) 的結果決定訪問哪臺伺服器；

upstream myserver{
   ip_hash; # hash(IP)
   server 127.0.0.1:8088;  # 有幾套環境，就配置幾條
   server 127.0.0.1:8089;
}

如果我們本地測試，多次訪問介面，可以發現請求永遠落到同一個服務上，因為本地 IP 一直沒有改變。

console_ip

3. 加權輪詢法

使用 weight 關鍵字，設定每臺伺服器的權重；

upstream myserver{
   server 127.0.0.1:8088 weight=1;  # 20% 請求會發給8088
   server 127.0.0.1:8089 weight=4;
}

console_weight

4. 最小連線數法

根據每個伺服器節點的連線數，動態地選擇當前連線數最少的伺服器轉發請求；

upstream myserver{
   least_conn;
   server 127.0.0.1:8088;
   server 127.0.0.1:8089;
}

5. 最快響應速度法

根據每個伺服器節點的響應時間（請求的往返延遲），動態地選擇當前響應速度最快的伺服器轉發請求；需要額外安裝 nginx-upstream-fair 模組。

upstream myserver{
   fair; # 額外安裝 nginx-upstream-fair 模組
   server 127.0.0.1:8088;
   server 127.0.0.1:8089;
}

6. URL 雜湊演算法

對 URL 進行 Hash 運算，根據結果來分配請求，這樣每個 URL 都可以訪問到同一個服務端；當服務端有快取的時候，比較有效。

upstream myserver{
   hash $request_uri;
   server 127.0.0.1:8088;  # 有幾套環境，就配置幾條
   server 127.0.0.1:8089;
}

也可以安裝第三方模組，比如我們要使用 URL 一致性雜湊演算法，那麼我們可以安裝 ngx_http_upstream_consistent_hash 模組。

upstream myserver{
   consistent_hash $request_uri;
   server 127.0.0.1:8088;
   server 127.0.0.1:8089;
}

參考資料：Upstream Consistent Hash

5. Nginx 常用功能

5.1 請求失敗重試

當一臺伺服器掛掉，請求如何轉發到其他正常的伺服器上？

我們可以先做個試驗，就是關閉 8089 埠的服務，只保留 8088 埠的服務，然後呼叫幾次介面，如果其中一次呼叫長時間不返回（瀏覽器訪問狀態圖示一直在打轉），表示本次請求傳送到了 8089 埠，那麼讓我們等待一段時間...大約一分鐘之後，8080 埠服務的後臺日誌，列印出來日誌，呼叫端接收到了返回，這說明：

  1. Nginx 預設有失敗重試機制；
  2. 預設的超時時間為 60s 。

console-one-down

這裡的超時時間是可以修改的，需要在 http.server.location 中增加如下配置：

location / {
            root   html;
            index  index.html index.htm;
            proxy_pass  http://myserver;
            proxy_connect_timeout 5; # 連線超時時間
            proxy_send_timeout 5; # 傳送資料給後端伺服器的超時時間
            proxy_read_timeout 5; # 後端伺服器的相應時間
            #proxy_next_upstream off; # 是否要關閉重試機制
        }

完整配置檔案請參考：設定超時重試時間5秒-nginx.conf

不過這裡要注意一點，如果設定了伺服器相應超時時間(比如設定了 10s )，萬一應用的業務處理時間比較慢(業務處理花費了 15s )，那麼會導致 Nginx 超時重試，那麼可能會造成重複處理。

5.2 後端伺服器節點健康狀態檢查

如果掛掉一臺伺服器，路由到這臺伺服器請求每次都要等到超時時間過去，才能發起重試，如果 Nginx 不再把請求傳送給掛掉的伺服器，那就省事多了；

這就叫做“後端伺服器節點健康狀態檢查”。

如果不安裝第三方模組，可以做如下配置完成“後端伺服器節點健康狀態檢查”：

1. 設定超時時間：

location / {
            root   html;
            index  index.html index.htm;
            proxy_pass  http://myserver;
            proxy_connect_timeout 5; # 連線超時時間
            proxy_send_timeout 5; # 傳送資料給後端伺服器的超時時間
            proxy_read_timeout 5; # 後端伺服器的相應時間
            #proxy_next_upstream off; # 是否要關閉重試機制
        }

2. 設定嘗試重試的次數：

upstream myserver{
  	server 127.0.0.1:8088 max_fails=1 fail_timeout=100s;
  	server 127.0.0.1:8089 max_fails=1 fail_timeout=100s;
}

其中 max_fails 表示最多失敗次數，fail_timeout 表示在一個時間段內，伺服器不會再次嘗試訪問；上面的配置表示在 100s 內，只要超時失敗 1 次，就不再訪問該伺服器。

完整配置檔案請參考：設定超時重試時間5s-失敗1次100秒之內不再訪問-nginx.conf

除此之外，我們還可以安裝第三方模組來實現“後端伺服器節點健康狀態檢查”：

5.3 Nginx 的高可用

以為使用 Nginx ，部署了多臺應用伺服器，可以保證應用伺服器的高可用（掛掉一臺，還有其他伺服器可以用）；

但是如何保證負載均衡的高可用性？也就是萬一 Nginx 掛了怎麼辦？

Nginx 同樣也需要部署多臺，架構大概是這個樣子的：

nginx-master-backups

現在應用比較廣泛的是利用 keepalived 實現 Nignx 的高可用：
nginx-keeplived-1
nginx-keeplived-2

5.4 其他

除了以上的常見功能，強大的 Nginx 還可以：

  1. 限制 IP 訪問頻率和頻寬佔用；
  2. 快取靜態資源；
  3. 檔案壓縮；
  4. TCP 負載；
  5. 防盜鏈；
  6. 等等等等...

總結

我們現在的架構已經變成了：

相關文章