发布到线上的生产接口服务一直好端端的 ,今天突然运营反馈说很多功能无法正常使用 。环境经过排查 ,大面发现前端调用后端接口时 ,积锅部分接口出现404的不背现象 。
今天 ,生产我到公司比较晚 ,环境肯定是大面哪个小伙伴昨晚下班,走出办公室前没有祈祷服务器不要出问题 。积锅要把这个人揪出来 ,不背吊在服务器上祭天!生产
得知运营的环境反馈后 ,香港云服务器我迅速登录服务器排查问题。大面首先,积锅查看了接口服务的不背启动进程正常。验证接口服务的ip和端口是否正常 ,结果也是没啥问题。接下来,通过Nginx转发请求,此时出现了问题,无法访问接口 。同时Nginx的access.log文件中输出了如下日志信息。
复制192.168.175.120 - - [2024-08-03 21:34:21 +0800] "GET /third/system/base/thirdapp/get_detail HTTP/1.1" 404 0 "http://192.168.175.100/api/index.html" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:85.0) Gecko/20100101 Firefox/85.0" 192.168.175.120 - - [2024-08-03 21:34:22 +0800] "GET /third/system/base/thirdapp/get_detail HTTP/1.1" 404 0 "http://192.168.175.100/api/index.html" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:85.0) Gecko/20100101 Firefox/85.0" 192.168.175.120 - - [2024-08-03 21:34:26 +0800] "GET /third/system/base/thirdapp/get_detail HTTP/1.1" 404 0 "http://192.168.175.100/api/index.html" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:85.0) Gecko/20100101 Firefox/85.0"1.2.3.此时 ,服务器租用从Nginx日志中发现 ,输出的状态为404,未找到后端的接口服务 。为了进一步定位问题,我直接在线上环境通过curl命令的方式来访问接口服务,结果是正常的。
经过这一系列的操作之后,我们就可以确定问题是出在Nginx上了。
既然已经定位到问题了,源码库那我们接下来就要分析下产生问题的具体原因了 。既然是Nginx的问题,我第一时间想到的就是调试Nginx查找错误原因 。于是我在服务器命令行输入了如下命令来查看安装Nginx时的配置情况 。
复制nginx -V1.注意:这里已经为Nginx配置了系统环境变量,如果没有配置系统环境变量 ,则需要输入nginx命令所在目录的完整路径 ,例如:
复制/usr/local/nginx/sbin/nginx -v1.命令行输出了如下信息 。源码下载
复制configure arguments: --prefix=/usr/local/nginx --with-http_stub_status_module --add-module=/usr/local/src/fastdfs/fastdfs-nginx-module-1.22/src --with-openssl=/usr/local/src/openssl-1.0.2s --with-pcre=/usr/local/src/pcre-8.43 --with-zlib=/usr/local/src/zlib-1.2.11 --with-http_ssl_module1.可以看到,安装Nginx时没有配置Nginx的debug模块。
于是我在服务器上找到了Nginx的安装文件 ,在命令行输入如下命令重新编译Nginx。
复制cd /usr/local/src/nginx/ #进入Nginx的安装文件根目录 make clean #清除编译信息 ./configuration --prefix=/usr/local/nginx-1.17.8 --with-http_stub_status_module --add-module=/usr/local/src/fastdfs/fastdfs-nginx-module-1.22/src --with-openssl=/usr/local/src/openssl-1.0.2s --with-pcre=/usr/local/src/pcre-8.43 --with-zlib=/usr/local/src/zlib-1.2.11 --with-http_ssl_module --with-debug #设置编译Nginx的配置信息 make #编译Nginx,切记不要输入make install1.2.3.4.上述命令中,切记不要输入make install 进行安装。
执行完 make 命令后 ,会在当前目录的objs目录下生成nginx命令,此时我们需要先停止Nginx服务,备份/usr/local/nginx/sbin/目录下的云计算nginx命令,然后将objs目录下的nginx命令复制到/usr/local/nginx/sbin/目录下,然后启动Nginx服务。
复制nginx_service.sh stop #通过脚本停止Nginx服务 mv /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx.bak #备份原有nginx命令 cp ./objs/nginx /usr/local/nginx/sbin/nginx #复制nginx命令 nginx_service.sh start #通过脚本启动Nginx服务1.2.3.4.注意 :这里 ,在停止Nginx服务前 ,已经将此Nginx从接入层网关中移除了 ,所以不会影响线上环境 。为了避免使用新编译的nginx命令重启Nginx出现问题,这里通过脚本先停止Nginx服务,然后复制nginx命令后 ,再启动Nginx服务。
在Nginx的nginx.conf文件中配置如下信息 。
复制error_log logs/error.log debug;1.此时,建站模板开启了Nginx的debug日志功能,并将debug信息输出到error.log文件中 。
接下来,在服务器命令行输入如下命令监听error.log文件的输出日志。
复制tail -F /usr/local/nginx/logs/error.log1.然后模拟访问http接口 ,可以看到error.log文件中输出如下信息 。
复制2024-08-03 21:34:26 [debug] 31486#0: *56 http request line: "GET /third/system/base/thirdapp/get_detail HTTP/1.1" 2024-08-03 21:34:26 [debug] 31486#0: *56 http uri: "/third/system/base/thirdapp/get_detail" 2024-08-03 21:34:26 [debug] 31486#0: *56 http args: "" 2024-08-03 21:34:26 [debug] 31486#0: *56 http exten: "" 2024-08-03 21:34:26 [debug] 31486#0: *56 posix_memalign: 0000000000FF6450:4096 @16 2024-08-03 21:34:26 [debug] 31486#0: *56 http process request header line 2024-08-03 21:34:26 [debug] 31486#0: *56 http header: "Host: 10.31.5.66" 2024-08-03 21:34:26 [debug] 31486#0: *56 http header: "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:85.0) Gecko/20100101 Firefox/85.0" 2024-08-03 21:34:26 [debug] 31486#0: *56 http header: "Accept: */*" 2024-08-03 21:34:26 [debug] 31486#0: *56 http header: "Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2" 2024-08-03 21:34:26 [debug] 31486#0: *56 http header: "Accept-Encoding: gzip, deflate" 2024-08-03 21:34:26 [debug] 31486#0: *56 http header: "Referer: http://192.168.175.100/api/index.html" 2024-08-03 21:34:26 [debug] 31486#0: *56 http header: "Connection: keep-alive" 2024-08-03 21:34:26 [debug] 31486#0: *56 http header done 2024-08-03 21:34:26 [debug] 31486#0: *56 rewrite phase: 0 2024-08-03 21:34:26 [debug] 31486#0: *56 test location: "/" 2024-08-03 21:34:26 [debug] 31486#0: *56 test location: "file/" 2024-08-03 21:34:26 [debug] 31486#0: *56 test location: ~ "/base" 2024-08-03 21:34:26 [debug] 31486#0: *56 using configuration "/base"1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.从上面的输出日志中,我们可以看到 :访问的接口地址为“/third/system/base/thirdapp/get_detail” ,如下所示 。
复制2024-08-03 21:34:26 [debug] 31486#0: *56 http uri: "/third/system/base/thirdapp/get_detail"1.Nginx在进行转发时,分别匹配了“/”,“file/”,“~/base” ,最终将请求转发到了“/base” ,如下所示 。
复制2024-08-03 21:34:26 [debug] 31486#0: *56 test location: "/" 2024-08-03 21:34:26 [debug] 31486#0: *56 test location: "file/" 2024-08-03 21:34:26 [debug] 31486#0: *56 test location: ~ "/base" 2024-08-03 21:34:26 [debug] 31486#0: *56 using configuration "/base"1.2.3.4.我们再来看看Nginx的配置,打开nginx.conf文件 ,找到下面的配置 。
复制location ~/base { proxy_pass http://base; proxy_set_header Host $host:$server_port; } location ~/third { proxy_pass http://third; proxy_set_header Host $host:$server_port; }1.2.3.4.5.6.7.8.那么问题来了,访问的接口明明是“/third/system/base/thirdapp/get_detail” ,为啥会走到“/base”下面呢 ?
说到这里 ,相信细心的小伙伴已经发现问题了,没错,又是运维的锅!!
看了Nginx的配置后,相信很多小伙伴应该都知道如何解决问题了,没错那就是把nginx.conf中的如下配置。
复制location ~/base { proxy_pass http://base; proxy_set_header Host $host:$server_port; } location ~/third { proxy_pass http://third; proxy_set_header Host $host:$server_port; }1.2.3.4.5.6.7.8.修改为如下所示。
复制location /base { proxy_pass http://base; proxy_set_header Host $host:$server_port; } location /third { proxy_pass http://third; proxy_set_header Host $host:$server_port; }1.2.3.4.5.6.7.8.去掉“~”符号即可。
接下来 ,再次模拟访问http接口,能够正常访问接口。
接下来 ,将Nginx的debug功能关闭 ,也就是将nginx.conf文件中的 error_log logs/error.log debug; 配置注释掉,如下所示 。
复制# error_log logs/error.log debug;1.重新加载nginx.conf文件 。
复制nginx_service.sh reload1.最终 ,将Nginx加入到接入层网关 ,问题解决 。
示例1:
复制location / { }1.匹配任意请求
示例2:
复制location ~* .(gif|jpg|jpeg)$ { rewrite .(gif|jpg|jpeg)$ /logo.png; }1.2.3.不区分大小写匹配任何以gif 、jpg 、jpeg结尾的请求 ,并将该请求重定向到 /logo.png请求
示例3 :
复制location ~ ^.+\.txt$ { root /usr/local/nginx/html/; }1.2.3.区分大小写匹配以.txt结尾的请求 ,并设置此location的路径是/usr/local/nginx/html/ 。也就是以.txt结尾的请求将访问/usr/local/nginx/html/ 路径下的txt文件
示例如下 :
复制location ^~ /binghe/ { alias /usr/local/nginx/html/binghetic/; }1.2.3. 请求:http://test.com/binghe/binghe1.html实际访问 :/usr/local/nginx/html/binghetic/binghe1.html 文件 复制location ^~ /binghe/ { root /usr/local/nginx/html/; }1.2.3. 请求:http://test.com/binghe/binghe1.html实际访问:/usr/local/nginx/html/binghe/binghe1.html 文件(1)last 和 break 当出现在location 之外时 ,两者的作用是一致的没有任何差异
(2)last 和 break 当出现在location 内部时:
last 使用了last 指令,rewrite 后会跳出location 作用域,重新开始再走一次刚才的行为break 使用了break 指令,rewrite后不会跳出location 作用域,其整个生命周期都在当前location中 。将符合某个正则表达式的URL重定向到一个固定页面
比如:我们需要将符合“/test/(\d+)/[\w-.]+” 这个正则表达式的URL重定向到一个固定的页面 。符合这个正则表达式的页面可能是:http://test.com/test/12345/abc122.html 、http://test.com/test/456/11111cccc.js等
从上面的介绍可以看出 ,这里可以使用rewrite重定向或者alias关键字来达到我们的目的 。因此 ,这里可以这样做:
(1)使用rewrite关键字
复制location ~ ^.+\.txt$ { root /usr/local/nginx/html/; } location ~* ^/test/(\d+)/[\w-\.]+$ { rewrite ^/test/(\d+)/[\w-\.]+$ /testpage.txt last; }1.2.3.4.5.6.这里将所有符合条件的URL(PS:不区分大小写)都重定向到/testpage.txt请求,也就是 /usr/local/nginx/html/testpage.txt 文件
(2)使用alias关键字
复制location ~* ^/test/(\d+)/[\w-\.]+$ { alias /usr/local/nginx/html/binghetic/binghe1.html; }1.2.3.这里将所有符合条件的URL(不区分大小写)都重定向到/usr/local/nginx/html/binghetic/binghe1.html 文件