Nginx 負載均衡實現(xiàn)上游服務健康檢查

Author：Arsen
Date：2024/06/20

---

---

前言

如果你使用云負載均衡（如阿里云 CLB），我們可以通過配置健康檢查來實現(xiàn)后端服務故障轉(zhuǎn)移（通過 4/7 層實現(xiàn)）。而如果你使用 Nginx 作為負載均衡器時，又如何實現(xiàn)后端（上游）服務器的健康檢查呢？要解決這個問題，就需要使用到 Nginx 的 nginx_upstream_check_module 模塊，因為在不使用 nginx_upstream_check_module 模塊的情況下，Nginx 的常規(guī)負載均衡機制并不具備自動移除不健康服務器的功能。默認情況下，Nginx 不會主動檢查上游服務器的健康狀態(tài)，因此無法在服務器出現(xiàn)故障時自動將其從負載均衡池中移除。

接下來將演示如何通過 nginx_upstream_check_module 實現(xiàn)負載均衡上游服務器的故障轉(zhuǎn)移。

注意：nginx_upstream_check_module 是一個第三方模塊，不屬于官方 NGINX 發(fā)行版的一部分，因此需要我們手動將其集成到 NGINX 中，而不是通過官方預編譯的 NGINX 包來使用它。

一、Nginx 部署并新增模塊

1、下載 nginx、nginx_upstream_check_module 源碼包

nginx_upstream_check_module 模塊地址：https://github.com/yaoweibin/nginx_upstream_check_module

wget http://nginx.org/download/nginx-1.18.0.tar.gz
wget https://github.com/yaoweibin/nginx_upstream_check_module/archive/refs/tags/v0.4.0.tar.gz

2、解壓安裝包

tar xzf v0.4.0.tar.gz
tar xzf nginx-1.18.0.tar.gz

3、為 NGINX 源碼打補丁

# 安裝補丁工具
yum install -y patch

補丁列表（在我們上面下載的第三方模塊中）：

在補丁文件列表中，沒有直接與 nginx-1.18.4 對應的補丁文件。通常情況下，選擇一個版本號最接近但不高于你的 NGINX 版本的補丁文件會是最佳選擇。如上圖，使用 check_1.16.1+.patch，因為它是最接近 1.18.0 的可用補丁且不高于1.18.0 。

# 開始打補丁
cd nginx-1.18.0/
patch -p1 < ../nginx_upstream_check_module-0.4.0/check_1.16.1+.patch

4、開始編譯安裝

關于模塊安裝注意事項，可以查看有道云筆記 nginx 編譯安裝部分。

# 安裝nginx編譯安裝的依賴環(huán)境yum -y install make gcc gcc-c++ pcre pcre-devel gd-devel openssl openssl-devel zlib zlib-devel

./configure \
--with-http_gzip_static_module \
--with-http_ssl_module \
--with-http_stub_status_module \
--with-http_ssl_module \
--with-pcre \
--with-file-aio \
--with-http_realip_module \
--without-http_scgi_module \
--without-http_uwsgi_module \
--without-http_fastcgi_module \
--with-compat --add-module=../nginx_upstream_check_module-0.4.0# --with-compat 是一個用于構建兼容模塊的選項，它允許你編譯 NGINX 時，使其模塊在不同版本的 NGINX 上保持兼容。
# 這里僅僅是測試使用，我就不具體規(guī)劃路徑了（如安裝路徑、日志路徑等），使用默認即可

如上圖，Nginx 編譯完成，默認輸出了相關的工作路徑，接下來就根據(jù)上圖路徑開始安裝了：

make && make install

此時我們需要驗證新增的第三方模塊是否被成功集成：

二、健康檢查配置

2.1 準備 nodeJS 應用程序

1、node 安裝

過程略.

2、安裝 pm2 守護進程管理器

npm install -g pm2

3、創(chuàng)建測試項目并啟動項目

vim /data/nginx-test-projects/node-js-demo/app-1.js

const http = require('http');const server = http.createServer((req, res) => {res.setHeader("Content-Type", "application/json");res.writeHead(200);res.end(`{ "status": "success", "message": "app-1 請求成功!\n" }`);
});server.listen(3001, 'localhost', () => {console.log('running on http://localhost:3001/');
});

vim /data/nginx-test-projects/node-js-demo/app-2.js

const http = require('http');const server = http.createServer((req, res) => {res.setHeader("Content-Type", "application/json");res.writeHead(200);res.end(`{ "status": "success", "message": "app-2 請求成功!\n" }`);
});server.listen(3002, 'localhost', () => {console.log('running on http://localhost:3002/');
});

vim /data/nginx-test-projects/node-js-demo/app-3.js

const http = require('http');const server = http.createServer((req, res) => {res.setHeader("Content-Type", "application/json");res.writeHead(200);res.end(`{ "status": "success", "message": "app-3 請求成功!\n" }`);
});server.listen(3003, 'localhost', () => {console.log('running on http://localhost:3003/');
});

啟動應用：

pm2 start /data/nginx-test-projects/node-js-demo/app-1.js
pm2 start /data/nginx-test-projects/node-js-demo/app-2.js
pm2 start /data/nginx-test-projects/node-js-demo/app-3.js

2.2 Nginx 配置負載均衡健康檢查

1、nginx 配置

vim /usr/local/nginx/conf/nginx.conf

http {upstream backend {server 127.0.0.1:8080;server 127.0.0.1:8081;check interval=3000 rise=2 fall=5 timeout=1000 type=http;check_http_send "HEAD / HTTP/1.0\r\n\r\n";check_http_expect_alive http_2xx http_3xx;}server {listen 80;location / {proxy_pass http://backend;}}
}

配置說明：

• upstream backend { ... }: 定義名為 backend 的上游服務器組。

• server 127.0.0.1:8080;: 定義一個地址為 127.0.0.1:8080 的上游服務器。

• check interval=3000 rise=2 fall=5 timeout=1000 type=http;

  配置健康檢查參數(shù)：

  • interval=3000: 每隔 3000 毫秒（3 秒）進行一次健康檢查。
  • rise=2: 如果服務器連續(xù)通過 2 次健康檢查，則認為它是健康的。
  • fall=5: 如果服務器連續(xù) 5 次健康檢查失敗，則認為它是故障的。
  • timeout=1000: 每次健康檢查必須在 1000 毫秒（1 秒）內(nèi)完成。
  • type=http: 指定進行 HTTP 健康檢查。

• check_http_send "HEAD / HTTP/1.0\r\n\r\n";: 向服務器發(fā)送 HTTP HEAD 請求。

• check_http_expect_alive http_2xx http_3xx;: 如果服務器返回的狀態(tài)碼在 2xx 或 3xx 范圍內(nèi)，則認為服務器是健康的。

2、健康檢查驗證

while sleep 0.5; do curl http://192.168.56.120; done

后端服務健康情況時，是正常的負載均衡的：

這里我分兩種情況來驗證：

1）未配置 nginx_upstream_check_module 的情況

此時，我停掉 app-1

pm2 stop app-1

看看 nginx 的錯誤日志是否持續(xù)輸出，如果持續(xù)輸出，說明 nginx 一直在輪詢請求后端上游服務，且請求不到，這就證明默認的 nginx 負載均衡模式下，并不能實現(xiàn)后端上游服務的健康檢查，客戶的請求依然會打到壞掉的 app-1 服務上。如下圖，正符合我們的假設。

2）配置了 nginx_upstream_check_module 的情況

這里，我們先恢復后端服務，使 3 臺都正常工作。然后我們保持請求不要斷，繼續(xù)將 app-1 stop 掉，看會不會故障轉(zhuǎn)移到其他節(jié)點：判斷是否轉(zhuǎn)移其實就是你看 nginx 是否有如上圖相同的錯誤日志持續(xù)輸出，如果有，那證明這個檢測模塊我們就沒配置正確，否則證明我們的檢測模塊生效，且將壞掉的 app-1 從負載均衡中摘掉，恢復時自動加入負載均衡。

停掉 app-1

pm2 stop app-1

再看看 Nginx 的錯誤日志：

這里你會注意到，此時的錯誤日志與上一張圖的錯誤日志不同了，那他們的區(qū)別是什么呢？

1）未配置 nginx_upstream_check_module 的錯誤日志分析：

由于我們沒有配置了 Nginx 健康檢查，在連接已建立后，NGINX 嘗試連接到上游服務器時，連接被拒絕而拋出如下錯誤日志：

2024/06/20 13:19:55 [error] 14553#0: *510 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.56.120, server: localhost, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:3001/", host: "192.168.56.120"

這通常是由于上游服務器未能正常啟動或者未響應

客戶端請求處理：

• 如果 NGINX 配置中沒有健康檢查，或者健康檢查無法檢測到上游服務器的問題，客戶端的請求可能會繼續(xù)被發(fā)送到無法處理請求的上游服務器。
• 這種情況下，客戶端請求可能會因為上游服務器的問題而遭遇連接失敗或者長時間的等待響應。

2）配置了 nginx_upstream_check_module 的錯誤日志分析：

由于我們配置了 Nginx 健康檢查，在連接已建立后，NGINX 嘗試發(fā)送數(shù)據(jù)到上游服務器時，連接被拒絕而拋出如下錯誤日志：

2024/06/20 13:35:06 [error] 15030#0: send() failed (111: Connection refused)
2024/06/20 13:35:09 [error] 15030#0: send() failed (111: Connection refused)
2024/06/20 13:35:12 [error] 15030#0: send() failed (111: Connection refused)
2024/06/20 13:35:15 [error] 15030#0: send() failed (111: Connection refused)

在連接建立后，即使上游服務器通過了健康檢查確認為健康狀態(tài)，但在實際發(fā)送數(shù)據(jù)時，服務器可能由于負載過高、連接限制或其他原因拒絕處理請求。

客戶端請求處理：

• 配置了健康檢查后，NGINX 會在發(fā)送實際請求之前先檢查上游服務器的健康狀態(tài)。
• 如果上游服務器在健康檢查時被標記為不可用，NGINX 將不會將客戶端的請求發(fā)送到該上游服務器。
• 這種情況下，客戶端的請求不會被打到處于故障狀態(tài)的上游服務器，因為 NGINX 在發(fā)送請求之前會先確認上游服務器的可用性。

小結

1、nginx 未設置健康檢查報錯

這類報錯是在連接建立階段出現(xiàn)連接被拒絕的錯誤，通常因為上游服務器未能正常啟動或者未響應。

2、nginx 設置了健康檢查報錯

康狀態(tài)，但在實際發(fā)送數(shù)據(jù)時，服務器可能由于負載過高、連接限制或其他原因拒絕處理請求。

3、健康檢查的目的

實現(xiàn)高可用。

—END