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

Author：Arsen
Date：2024/06/20

---

---

前言

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

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

注意：nginx_upstream_check_module 是一個(gè)第三方模塊，不屬于官方 NGINX 發(fā)行版的一部分，因此需要我們手動(dòng)將其集成到 NGINX 中，而不是通過官方預(yù)編譯的 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 源碼打補(bǔ)丁

# 安裝補(bǔ)丁工具
yum install -y patch

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

在補(bǔ)丁文件列表中，沒有直接與 nginx-1.18.4 對(duì)應(yīng)的補(bǔ)丁文件。通常情況下，選擇一個(gè)版本號(hào)最接近但不高于你的 NGINX 版本的補(bǔ)丁文件會(huì)是最佳選擇。如上圖，使用 check_1.16.1+.patch，因?yàn)樗亲罱咏?1.18.0 的可用補(bǔ)丁且不高于1.18.0 。

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

4、開始編譯安裝

關(guān)于模塊安裝注意事項(xiàng)，可以查看有道云筆記 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 是一個(gè)用于構(gòu)建兼容模塊的選項(xiàng)，它允許你編譯 NGINX 時(shí)，使其模塊在不同版本的 NGINX 上保持兼容。
# 這里僅僅是測(cè)試使用，我就不具體規(guī)劃路徑了（如安裝路徑、日志路徑等），使用默認(rèn)即可

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

make && make install

此時(shí)我們需要驗(yàn)證新增的第三方模塊是否被成功集成：

二、健康檢查配置

2.1 準(zhǔn)備 nodeJS 應(yīng)用程序

1、node 安裝

過程略.

2、安裝 pm2 守護(hù)進(jìn)程管理器

npm install -g pm2

3、創(chuàng)建測(cè)試項(xiàng)目并啟動(dòng)項(xià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 請(qǐng)求成功!\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 請(qǐng)求成功!\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 請(qǐng)求成功!\n" }`);
});server.listen(3003, 'localhost', () => {console.log('running on http://localhost:3003/');
});

啟動(dòng)應(yīng)用：

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 配置負(fù)載均衡健康檢查

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 的上游服務(wù)器組。

• server 127.0.0.1:8080;: 定義一個(gè)地址為 127.0.0.1:8080 的上游服務(wù)器。

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

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

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

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

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

2、健康檢查驗(yàn)證

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

后端服務(wù)健康情況時(shí)，是正常的負(fù)載均衡的：

這里我分兩種情況來驗(yàn)證：

1）未配置 nginx_upstream_check_module 的情況

此時(shí)，我停掉 app-1

pm2 stop app-1

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

2）配置了 nginx_upstream_check_module 的情況

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

停掉 app-1

pm2 stop app-1

再看看 Nginx 的錯(cuò)誤日志：

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

1）未配置 nginx_upstream_check_module 的錯(cuò)誤日志分析：

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

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"

這通常是由于上游服務(wù)器未能正常啟動(dòng)或者未響應(yīng)

客戶端請(qǐng)求處理：

• 如果 NGINX 配置中沒有健康檢查，或者健康檢查無(wú)法檢測(cè)到上游服務(wù)器的問題，客戶端的請(qǐng)求可能會(huì)繼續(xù)被發(fā)送到無(wú)法處理請(qǐng)求的上游服務(wù)器。
• 這種情況下，客戶端請(qǐng)求可能會(huì)因?yàn)樯嫌畏?wù)器的問題而遭遇連接失敗或者長(zhǎng)時(shí)間的等待響應(yīng)。

2）配置了 nginx_upstream_check_module 的錯(cuò)誤日志分析：

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

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)

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

客戶端請(qǐng)求處理：

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

小結(jié)

1、nginx 未設(shè)置健康檢查報(bào)錯(cuò)

這類報(bào)錯(cuò)是在連接建立階段出現(xiàn)連接被拒絕的錯(cuò)誤，通常因?yàn)樯嫌畏?wù)器未能正常啟動(dòng)或者未響應(yīng)。

2、nginx 設(shè)置了健康檢查報(bào)錯(cuò)

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

3、健康檢查的目的

實(shí)現(xiàn)高可用。

—END