修改Nginx源碼實(shí)現(xiàn)worker進(jìn)程隔離實(shí)現(xiàn)詳解
背景
最近我們線上網(wǎng)關(guān)替換為了 APISIX，也遇到了一些問題，有一個(gè)比較難解決的問題是 APISIX 的進(jìn)程隔離問題。
APISIX 不同種類請求的互相影響
首先我們遇到的就是 APISIX Prometheus 插件在監(jiān)控?cái)?shù)據(jù)過多時(shí)影響正常業(yè)務(wù)接口響應(yīng)的問題。當(dāng)啟用 Prometheus 插件以后，可以通過 HTTP 接口獲取 APISIX 內(nèi)部采集的監(jiān)控信息然后展示到特定的看板中。
curl http://172.30.xxx.xxx:9091/apisix/prometheus/metrics
我們網(wǎng)關(guān)接入的業(yè)務(wù)系統(tǒng)非常繁雜，有 4000+ 路由，每次拉取 Prometheus 插件時(shí)，metrics 條數(shù)超過 50 萬條，大小超過 80M+，這部分信息需要在 lua 層拼裝發(fā)送，當(dāng)請求時(shí)會(huì)造成處理此請求的 worker 進(jìn)程 CPU 占用非常高，處理的時(shí)間超過 2s，導(dǎo)致此 worker 進(jìn)程處理正常業(yè)務(wù)請求會(huì)有 2s+ 的延遲。
當(dāng)時(shí)臨時(shí)想到的措施是修改 Prometheus 插件，減少采集發(fā)送的范圍和數(shù)量，先臨時(shí)繞過了此問題。經(jīng)過對 Prometheus 插件采集信息的分析，采集的數(shù)據(jù)條數(shù)如下。
407171 apisix_http_latency_bucket 29150 apisix_http_latency_sum 29150 apisix_http_latency_count 20024 apisix_bandwidth 17707 apisix_http_status 11 apisix_etcd_modify_indexes 6 apisix_nginx_http_current_connections 1 apisix_node_info
結(jié)合我們業(yè)務(wù)實(shí)際需要，去掉了部分信息，減少了部分延遲。
然后經(jīng) github issue 咨詢（github.com/apache/apis… ），發(fā)現(xiàn) APISIX 在商業(yè)版本中有提供此功能。因?yàn)檫€是想直接使用開源版本，此問題也暫時(shí)可以繞過，就沒有繼續(xù)深究下去。
但是后面又遇到了一個(gè)問題，就是 Admin API 處理在業(yè)務(wù)峰值處理不及時(shí)。我們使用 Admin API 來進(jìn)行版本切換的功能，在一次業(yè)務(wù)高峰期時(shí)，APISIX 負(fù)載較高，影響了 Admin 相關(guān)的接口，導(dǎo)致版本切換時(shí)偶發(fā)超時(shí)失敗。
這里的原因顯而易見，影響是雙向的：前面的 Prometheus 插件是 APISIX 內(nèi)部請求影響了正常業(yè)務(wù)請求。這里的是反過來的，正常業(yè)務(wù)請求影響了 APISIX 內(nèi)部的請求。因此把 APISIX 內(nèi)部的請求和正常業(yè)務(wù)請求隔離開就顯得至關(guān)重要，于是花了一點(diǎn)時(shí)間實(shí)現(xiàn)了這個(gè)功能。
上述對應(yīng)會(huì)生成如下的 nginx.conf 配置示例文件如下。
// 9091 端口處理 Prometheus 插件接口請求
server {
listen 0.0.0.0:9091;
access_log off;
location / {
content_by_lua_block {
local prometheus = require("apisix.plugins.prometheus.exporter")
prometheus.export_metrics()
}
}
}
// 9180 端口處理 admin 接口
server {
listen 0.0.0.0:9180;
location /apisix/admin {
content_by_lua_block {
apisix.http_admin()
}
}
}
// 正常處理 80 和 443 的業(yè)務(wù)請求
server {
listen 0.0.0.0:80;
listen 0.0.0.0:443 ssl;
server_name _;
location / {
proxy_pass $upstream_scheme://apisix_backend$upstream_uri;
access_by_lua_block {
apisix.http_access_phase()
}
}
修改 Nginx 源碼實(shí)現(xiàn)進(jìn)程隔離
對于 OpenResty 比較了解的同學(xué)應(yīng)該知道，OpenResty 在 Nginx 的基礎(chǔ)上進(jìn)行了擴(kuò)展，增加了 privilege
privileged agent 特權(quán)進(jìn)程不監(jiān)聽任何端口，不對外提供任何服務(wù)，主要用于定時(shí)任務(wù)等。
我們需要做的是增加 1 個(gè)或者多個(gè) woker 進(jìn)程，專門處理 APISIX 內(nèi)部的請求即可。
Nginx 采用多進(jìn)程模式，master 進(jìn)程會(huì)調(diào)用 bind、listen 監(jiān)聽套接字。fork 函數(shù)創(chuàng)建的 worker 進(jìn)程會(huì)復(fù)制這些 listen 狀態(tài)的 socket 句柄。
Nginx 源碼中創(chuàng)建 worker 子進(jìn)程的偽代碼如下：
void
ngx_master_process_cycle(ngx_cycle_t *cycle) {
ngx_setproctitle("master process");
ngx_start_worker_processes()
for (i = 0; i < n; i++) { // 根據(jù) cpu 核心數(shù)創(chuàng)建子進(jìn)程
ngx_spawn_process(i, "worker process");
pid = fork();
ngx_worker_process_cycle()
ngx_setproctitle("worker process")
for(;;) { // worker 子進(jìn)程的無限循環(huán)
// ...
}
}
}
for(;;) {
// ... master 進(jìn)程的無限循環(huán)
}
}
我們要做修改就是在 for 循環(huán)中多啟動(dòng) 1 個(gè)或 N 個(gè)子進(jìn)程，專門用來處理特定端口的請求。
這里的 demo 以啟動(dòng) 1 個(gè) worker process 為例，修改 ngx_start_worker_processes 的邏輯如下，多啟動(dòng)一個(gè) worker process，命令名為 "isolation process" 表示內(nèi)部隔離進(jìn)程。
static void
ngx_start_worker_processes(ngx_cycle_t *cycle, ngx_int_t n, ngx_int_t type)
{
ngx_int_t i;
// ...
for (i = 0; i < n + 1; i++) { // 這里將 n 改為了 n+1，多啟動(dòng)一個(gè)進(jìn)程
if (i == 0) { // 將子進(jìn)程組中的第一個(gè)作為隔離進(jìn)程
ngx_spawn_process(cycle, ngx_worker_process_cycle,
(void *) (intptr_t) i, "isolation process", type);
} else {
ngx_spawn_process(cycle, ngx_worker_process_cycle,
(void *) (intptr_t) i, "worker process", type);
}
}
// ...
}
隨后在 ngx_worker_process_cycle 的邏輯對第 0 號(hào) worker 做特殊處理，這里的 demo 使用 18080、18081、18082 作為隔離端口示意。
static void
ngx_worker_process_cycle(ngx_cycle_t *cycle, void *data)
{
ngx_int_t worker = (intptr_t) data;
int ports[3];
ports[0] = 18080;
ports[1] = 18081;
ports[2] = 18082;
ngx_worker_process_init(cycle, worker);
if (worker == 0) { // 處理 0 號(hào) worker
ngx_setproctitle("isolation process");
ngx_close_not_isolation_listening_sockets(cycle, ports, 3);
} else { // 處理非 0 號(hào) worker
ngx_setproctitle("worker process");
ngx_close_isolation_listening_sockets(cycle, ports, 3);
}
}
這里新寫了兩個(gè)方法
ngx_close_not_isolation_listening_sockets：只保留隔離端口的監(jiān)聽，取消其它端口監(jiān)聽ngx_close_isolation_listening_sockets：關(guān)閉隔離端口的監(jiān)聽，只保留正常業(yè)務(wù)監(jiān)聽端口，也就是處理正常業(yè)務(wù)
ngx_close_not_isolation_listening_sockets 精簡后的代碼如下：
// used in isolation process
void
ngx_close_not_isolation_listening_sockets(ngx_cycle_t *cycle, int isolation_ports[], int port_num)
{
ngx_connection_t *c;
int port_match = 0;
ngx_listening_t* ls = cycle->listening.elts;
for (int i = 0; i < cycle->listening.nelts; i++) {
c = ls[i].connection;
// 從 sockaddr 結(jié)構(gòu)體中獲取端口號(hào)
in_port_t port = ngx_inet_get_port(ls[i].sockaddr) ;
// 判斷當(dāng)前端口號(hào)是否是需要隔離的端口
int is_isolation_port = check_isolation_port(port, isolation_ports, port_num);
// 如果不是隔離端口，則取消監(jiān)聽事情的處理
if (c && !is_isolation_port) {
// 調(diào)用 epoll_ctl 移除事件監(jiān)聽
ngx_del_event(c->read, NGX_READ_EVENT, 0);
ngx_free_connection(c);
c->fd = (ngx_socket_t) -1;
}
if (!is_isolation_port) {
port_match++;
ngx_close_socket(ls[i].fd); // close 當(dāng)前 fd
ls[i].fd = (ngx_socket_t) -1;
}
}
cycle->listening.nelts -= port_match;
}
對應(yīng)的 ngx_close_isolation_listening_sockets 關(guān)閉所有的隔離端口，只保留正常業(yè)務(wù)端口監(jiān)聽，簡化后的代碼如下。
void
ngx_close_isolation_listening_sockets(ngx_cycle_t *cycle, int isolation_ports[], int port_num)
{
ngx_connection_t *c;
int port_match;
port_match = 0;
ngx_listening_t * ls = cycle->listening.elts;
for (int i = 0; i < cycle->listening.nelts; i++) {
c = ls[i].connection;
in_port_t port = ngx_inet_get_port(ls[i].sockaddr) ;
int is_isolation_port = check_isolation_port(port, isolation_ports, port_num);
// 如果是隔離端口，關(guān)閉監(jiān)聽
if (c && is_isolation_port) {
ngx_del_event(c->read, NGX_READ_EVENT, 0);
ngx_free_connection(c);
c->fd = (ngx_socket_t) -1;
}
if (is_isolation_port) {
port_match++;
ngx_close_socket(ls[i].fd); // 關(guān)閉 fd
ls[i].fd = (ngx_socket_t) -1;
}
}
cle->listening.nelts -= port_match;
}
如此一來，我們就實(shí)現(xiàn)了 Nginx 基于端口的進(jìn)程隔離。
效果驗(yàn)證
這里我們使用 18080~18082 端口作為隔離端口驗(yàn)證，其它端口作為正常業(yè)務(wù)端端口。為了模擬請求占用較高 CPU 的情況，這里我們用 lua 來計(jì)算多次 sqrt，以更好的驗(yàn)證 Nginx 的 worker 負(fù)載均衡。
server {
listen 18080; // 18081,18082 配置一樣
server_name localhost;
location / {
content_by_lua_block {
local sum = 0;
for i = 1,10000000,1 do
sum = sum + math.sqrt(i)
end
ngx.say(sum)
}
}
}
server {
listen 28080;
server_name localhost;
location / {
content_by_lua_block {
local sum = 0;
for i = 1,10000000,1 do
sum = sum + math.sqrt(i)
end
ngx.say(sum)
}
}
}
首先來記錄一下當(dāng)前 worker 進(jìn)程情況。
可以看到現(xiàn)在已經(jīng)啟動(dòng)了 1 個(gè)內(nèi)部隔離 worker 進(jìn)程（pid=3355），4 個(gè)普通 worker 進(jìn)程（pid=3356~3359）。
首先我們可以看通過端口監(jiān)聽來確定我們的改動(dòng)是否生效。
可以看到隔離進(jìn)程 3355 進(jìn)程監(jiān)聽了 18080、18081、18082，普通進(jìn)程 3356 等進(jìn)程監(jiān)聽了 20880、20881 端口。
使用 ab 請求 18080 端口，看看是否只會(huì)把 3355 進(jìn)程 CPU 跑滿。
ab -n 10000 -c 10 localhost:18080 top -p 3355,3356,3357,3358,3359
可以看到此時(shí)只有 3355 這個(gè) isolation process 被跑滿。
接下來看看非隔離端口請求，是否只會(huì)跑滿其它四個(gè) woker process。
ab -n 10000 -c 10 localhost:28080 top -p 3355,3356,3357,3358,3359
符合預(yù)期，只會(huì)跑滿 4 個(gè)普通 worker 進(jìn)程（pid=3356~3359），此時(shí) 3355 的 cpu 使用率為 0。
到此，我們就通過修改 Nginx 源碼實(shí)現(xiàn)了特定基于端口號(hào)的進(jìn)程隔離方案。此 demo 中的端口號(hào)是寫死的，我們實(shí)際使用的時(shí)候是通過 lua 代碼傳入的。
init_by_lua_block {
local process = require "ngx.process"
local ports = {18080, 18081, 18083}
local ok, err = process.enable_isolation_process(ports)
if not ok then
ngx.log(ngx.ERR, "enable enable_isolation_process failed")
return
else
ngx.log(ngx.ERR, "enable enable_isolation_process success")
end
}
這里需要 lua 通過 ffi 傳入到 OpenResty 中，這里不是本文的重點(diǎn)，就不展開講述。
后記
這個(gè)方案有一點(diǎn) hack，能比較好的解決當(dāng)前我們遇到的問題，但是也是有成本的，需要維護(hù)自己的 OpenResty 代碼分支，喜歡折騰的同學(xué)或者實(shí)在需要此特性可以試試。
上述方案只是我對 Nginx 源碼的粗淺了解做的改動(dòng)，如果有使用不當(dāng)?shù)牡胤綒g迎跟我反饋。
以上就是修改Nginx源碼實(shí)現(xiàn)worker進(jìn)程隔離實(shí)現(xiàn)詳解的詳細(xì)內(nèi)容，更多關(guān)于Nginx worker 進(jìn)程隔離的資料請關(guān)注腳本之家其它相關(guān)文章！
相關(guān)文章
這篇文章主要介紹了在CentOS 7下編譯安裝Nginx 1.11.10的方法，文中給出了詳細(xì)的安裝步驟，相信對大家具有一定的參考價(jià)值，需要的朋友們下面來一起看看吧。2017-03-03
這篇文章主要介紹了nginx的服務(wù)配置及重定向問題,具有很好的參考價(jià)值,希望對大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2024-06-06
nginx實(shí)現(xiàn)請求轉(zhuǎn)發(fā)
本文給大家分享的是使用nginx實(shí)現(xiàn)代理（請求轉(zhuǎn)發(fā)）的教程及簡單示例，非常實(shí)用，有需要的小伙伴可以參考下2017-07-07
Nginx是一款輕量級的HTTP服務(wù)器，采用事件驅(qū)動(dòng)的異步非阻塞處理方式框架，這讓其具有極好的IO性能，時(shí)常用于服務(wù)端的反向代理和負(fù)載均衡，這篇文章主要介紹了Nginx速查手冊及常見問題，,需要的朋友可以參考下2022-04-04
Nginx 是開源、高性能、高可靠的 Web 和反向代理服務(wù)器，而且支持熱部署，幾乎可以做到 7 * 24 小時(shí)不間斷運(yùn)行，即使運(yùn)行幾個(gè)月也不需要重新啟動(dòng)，這篇文章主要介紹了CentOS用nginx搭建文件下載服務(wù)器,需要的朋友可以參考下2023-11-11
Nginx+Tomcat群集的實(shí)現(xiàn)示例
這篇文章主要介紹了Nginx+Tomcat群集的實(shí)現(xiàn)示例,文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2024-07-07
基于nginx設(shè)置瀏覽器協(xié)商緩存過程詳解
這篇文章主要介紹了基于nginx設(shè)置瀏覽器協(xié)商緩存過程詳解,文中通過示例代碼介紹的非常詳細(xì)，對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友可以參考下2019-12-12
Nginx實(shí)現(xiàn)404頁面的幾種方法(三種)
一個(gè)網(wǎng)站項(xiàng)目，肯定是避免不了404頁面的，通常使用Nginx作為Web服務(wù)器時(shí),有些相關(guān)配置方法，下面小編給大家?guī)砹薔ginx實(shí)現(xiàn)404頁面的幾種方法，感興趣的朋友一起看看吧2018-08-08
nginx中的proxy_set_header參數(shù)指令詳解
本文介紹了Nginx中的proxy_set_header指令,用于自定義代理請求的HTTP頭部信息,實(shí)現(xiàn)更靈活的反向代理功能,提供了實(shí)際應(yīng)用場景和配置示例,幫助讀者更好地理解和使用proxy_set_header指令,感興趣的朋友一起看看吧2025-03-03
Nginx設(shè)置日志打印post請求參數(shù)的方法
這篇文章主要介紹了Nginx設(shè)置日志打印post請求參數(shù)的方法，文中通過示例代碼介紹的非常詳細(xì)，對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2020-11-11