阅读文本大概需要3分钟。
严格来说，nginx到目前为止没有针对负载均衡后端节点的健康检测的模块，但是可以通过proxy_next_upstream来间接实现，但proxy_next_upstream还是会把请求转发给故障服务器的，然后再转发给别的服务器，这样就需要多一次转发。nginx_upstream_check_module为淘宝技术团队开发的nginx模块，用来检测后方server的健康状态，如果后端服务器不可用，则请求不再转发到这台服务器。
代码语言：javascript复制官网: https://github.com/yaoweibin/nginx_upstream_check_module
0x01: 安装nginx_upstream_check_module模块
以下命令均在root用户下执行
下载
代码语言：javascript复制wget https://codeload.github.com/yaoweibin/nginx_upstream_check_module/zip/v0.3.0下载zip文件
代码语言：javascript复制unzip nginx_upstream_check_module-0.3.0.zip
进入nginx源码目录，进行打该模块的补丁(这一步千万不能遗漏)
根据官网如下提示
在nginx-1.16.1目录执行如下命令，nginx_upstream_check_module源码目录跟nginx源码目录同级
代码语言：javascript复制patch -p1 < ../nginx_upstream_check_module-0.3.0/check_1.7.2 .patch
出现如下错误，推断可能是版本不兼容
看下官网发现nginx_upstream_check_module-0.3.0标签是2014年打的比较老，查看master源码发现patch已经更新了很多，应该是README文件没有更新
重新执行以下步骤，获取最新nginx_upstream_check_module
代码语言：javascript复制#下载
wget https://codeload.github.com/yaoweibin/nginx_upstream_check_module/zip/master
#解压
unzip nginx_upstream_check_module-master.zip
#重新解压一个nginx
tar -zxvf nginx-1.16.1.tar.gz
#打补丁
patch -p1 < ../nginx_upstream_check_module-master/check_1.16.1 .patch 先查看之前安装nginx的配置项
然后通过./configure --add-module来增加模块
代码语言：javascript复制./configure --prefix=/usr/local/nginx --user=nginx
--group=nginx --add-module=../nginx_upstream_check_module-master
注意：如果之前安装过nginx，需要将之前的configure参数保留
执行mak编译nginx
代码语言：javascript复制makemake之后的操作需要注意，如果nginx第一次安装，直接执行make install即可
代码语言：javascript复制make install如果单纯添加模块，不需要install，而是执行以下操作，将打过补丁的nginx二进制文件覆盖/usr/local/nginx/sbin/目录中的文件即可
代码语言：javascript复制#备份之前的nginx
mv /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx.bak
#拷贝新的nginx到sbin目录
cp /nginx源码目录/objs/nginx /usr/local/nginx/sbin/0x02：配置nginx upstream参数
- 在配置参数之前，可以先参考【Nginx系列：负载均衡】创建两个服务
- 新增接口健康检查接口： /health/status
package com.olive.controller;
import java.util.HashMap;
import java.util.Map;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;
@RestController
public class UserController {
@GetMapping("/health/status")
public Map<String, Object> checkHealth() {
Map<String, Object> result = new HashMap<>();
result.put("code", "000000");
result.put("message", "ok");
result.put("body", "我是服务器8866");
// result.put("body", "我是服务器8867");
return result;
}
}
- 健康检查配置
upstream myserver {
server 192.168.56.1:8866;
server 192.168.56.1:8867;
#http健康检查相关配置
check interval=3000 rise=2 fall=3 timeout=3000 type=http;
#/health/status为后端健康检查接口
check_http_send "HEAD /health/status HTTP/1.0rnrn";
check_http_expect_alive http_2xx http_3xx;
}
详细见图
interval: 向后端发送的健康检查包的间隔，单位为毫秒
rsie: 如果连续成功次数达到rise_count，服务器就被认为是up
fall: 如果连续失败次数达到fall_count，服务器就被认为是down
timeout: 后端健康请求的超时时间，单位为毫秒
type: 健康检查包的类型，支持tcp、ssl_hello、http、mysql、ajp
- 如果想查看后端服务器实时的健康状态，可以在对应server中增加以下location配置
location /nstatus {
check_status;
access_log off;
#allow SOME.IP.ADD.RESS;
#deny all;
}0x03：查看健康检查状态
通过http://localhost:80/nstatus 查看，刚开始后端两个节点都处于停止状态，status为down
server number为后端服务器数量，generation为nginx reload的次数
此时启动其中一台8867，查看nginx的error.log日志，出现如下日志，说明8867这台应用已经处于可检查状态
代码语言：javascript复制2020/08/21 23:03:55 [error] 10809#0: enable check peer: 192.168.56.1:8867 刷新nstatus页面，如下图所示，发现8867这台状态变为了up，表示已连接成功
启动8866，与8867过程相同，最终页面状态变为如下，此时两台状态均为up：
