目錄

• 背景
• APISIX 不同種類請求的互相影響
• 修改 Nginx 源碼實現進程隔離
• 效果驗證
• 后記

背景

最近我們線上網關替換為了 APISIX，也遇到了一些問題，有一個比較難解決的問題是 APISIX 的進程隔離問題。

APISIX 不同種類請求的互相影響

首先我們遇到的就是 APISIX Prometheus 插件在監控數據過多時影響正常業務接口響應的問題。當啟用 Prometheus 插件以后，可以通過 HTTP 接口獲取 APISIX 內部采集的監控信息然后展示到特定的看板中。

curl http://172.30.xxx.xxx:9091/apisix/prometheus/metrics

我們網關接入的業務系統非常繁雜，有 4000+ 路由，每次拉取 Prometheus 插件時，metrics 條數超過 50 萬條，大小超過 80M+，這部分信息需要在 lua 層拼裝發送，當請求時會造成處理此請求的 worker 進程 CPU 占用非常高，處理的時間超過 2s，導致此 worker 進程處理正常業務請求會有 2s+ 的延遲。

當時臨時想到的措施是修改 Prometheus 插件，減少采集發送的范圍和數量，先臨時繞過了此問題。經過對 Prometheus 插件采集信息的分析，采集的數據條數如下。

407171 apisix_http_latency_bucket29150 apisix_http_latency_sum29150 apisix_http_latency_count20024 apisix_bandwidth17707 apisix_http_status  11 apisix_etcd_modify_indexes   6 apisix_nginx_http_current_connections   1 apisix_node_info

結合我們業務實際需要，去掉了部分信息，減少了部分延遲。

然后經 github issue 咨詢（github.com/apache/apis… ），發現 APISIX 在商業版本中有提供此功能。因為還是想直接使用開源版本，此問題也暫時可以繞過，就沒有繼續深究下去。

但是后面又遇到了一個問題，就是 Admin API 處理在業務峰值處理不及時。我們使用 Admin API 來進行版本切換的功能，在一次業務高峰期時，APISIX 負載較高，影響了 Admin 相關的接口，導致版本切換時偶發超時失敗。

這里的原因顯而易見，影響是雙向的：前面的 Prometheus 插件是 APISIX 內部請求影響了正常業務請求。這里的是反過來的，正常業務請求影響了 APISIX 內部的請求。因此把 APISIX 內部的請求和正常業務請求隔離開就顯得至關重要，于是花了一點時間實現了這個功能。

上述對應會生成如下的 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 的業務請求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 源碼實現進程隔離

對于 OpenResty 比較了解的同學應該知道，OpenResty 在 Nginx 的基礎上進行了擴展，增加了 privilege

privileged agent 特權進程不監聽任何端口，不對外提供任何服務，主要用于定時任務等。

我們需要做的是增加 1 個或者多個 woker 進程，專門處理 APISIX 內部的請求即可。

Nginx 采用多進程模式，master 進程會調用 bind、listen 監聽套接字。fork 函數創建的 worker 進程會復制這些 listen 狀態的 socket 句柄。

Nginx 源碼中創建 worker 子進程的偽代碼如下：

voidngx_master_process_cycle(ngx_cycle_t *cycle) {    ngx_setproctitle("master process");    ngx_start_worker_processes()for (i = 0; i < n; i++) { // 根據 cpu 核心數創建子進程    ngx_spawn_process(i, "worker process");pid = fork();ngx_worker_process_cycle()    ngx_setproctitle("worker process")    for(;;) { // worker 子進程的無限循環 // ...    }}    }    for(;;) {// ... master 進程的無限循環     }}

我們要做修改就是在 for 循環中多啟動 1 個或 N 個子進程，專門用來處理特定端口的請求。

這里的 demo 以啟動 1 個 worker process 為例，修改 ngx_start_worker_processes 的邏輯如下，多啟動一個 worker process，命令名為 "isolation process" 表示內部隔離進程。

static voidngx_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，多啟動一個進程if (i == 0) { // 將子進程組中的第一個作為隔離進程    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 號 worker 做特殊處理，這里的 demo 使用 18080、18081、18082 作為隔離端口示意。

static voidngx_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 號 worker ngx_setproctitle("isolation process");ngx_close_not_isolation_listening_sockets(cycle, ports, 3);    } else { // 處理非 0 號 workerngx_setproctitle("worker process");ngx_close_isolation_listening_sockets(cycle, ports, 3);    }}

這里新寫了兩個方法

• ngx_close_not_isolation_listening_sockets：只保留隔離端口的監聽，取消其它端口監聽
• ngx_close_isolation_listening_sockets：關閉隔離端口的監聽，只保留正常業務監聽端口，也就是處理正常業務

ngx_close_not_isolation_listening_sockets 精簡后的代碼如下：

// used in isolation processvoidngx_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 結構體中獲取端口號in_port_t port = ngx_inet_get_port(ls[i].sockaddr) ;// 判斷當前端口號是否是需要隔離的端口int is_isolation_port = check_isolation_port(port, isolation_ports, port_num);// 如果不是隔離端口，則取消監聽事情的處理if (c && !is_isolation_port) {    // 調用 epoll_ctl 移除事件監聽    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 當前 fd    ls[i].fd = (ngx_socket_t) -1;}    }    cycle->listening.nelts -= port_match;}

對應的 ngx_close_isolation_listening_sockets 關閉所有的隔離端口，只保留正常業務端口監聽，簡化后的代碼如下。

voidngx_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);// 如果是隔離端口，關閉監聽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); // 關閉 fd    ls[i].fd = (ngx_socket_t) -1;}    }    cle->listening.nelts -= port_match;}

如此一來，我們就實現了 Nginx 基于端口的進程隔離。

效果驗證

這里我們使用 18080~18082 端口作為隔離端口驗證，其它端口作為正常業務端端口。為了模擬請求占用較高 CPU 的情況，這里我們用 lua 來計算多次 sqrt，以更好的驗證 Nginx 的 worker 負載均衡。

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 dosum = sum + math.sqrt(i)     end     ngx.say(sum)}    }}

首先來記錄一下當前 worker 進程情況。

可以看到現在已經啟動了 1 個內部隔離 worker 進程（pid=3355），4 個普通 worker 進程（pid=3356~3359）。

首先我們可以看通過端口監聽來確定我們的改動是否生效。

可以看到隔離進程 3355 進程監聽了 18080、18081、18082，普通進程 3356 等進程監聽了 20880、20881 端口。

使用 ab 請求 18080 端口，看看是否只會把 3355 進程 CPU 跑滿。

ab -n 10000 -c 10 localhost:18080top -p 3355,3356,3357,3358,3359

可以看到此時只有 3355 這個 isolation process 被跑滿。

接下來看看非隔離端口請求，是否只會跑滿其它四個 woker process。

ab -n 10000 -c 10 localhost:28080top -p 3355,3356,3357,3358,3359

符合預期，只會跑滿 4 個普通 worker 進程（pid=3356~3359），此時 3355 的 cpu 使用率為 0。

到此，我們就通過修改 Nginx 源碼實現了特定基于端口號的進程隔離方案。此 demo 中的端口號是寫死的，我們實際使用的時候是通過 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 中，這里不是本文的重點，就不展開講述。

后記

這個方案有一點 hack，能比較好的解決當前我們遇到的問題，但是也是有成本的，需要維護自己的 OpenResty 代碼分支，喜歡折騰的同學或者實在需要此特性可以試試。

上述方案只是我對 Nginx 源碼的粗淺了解做的改動，如果有使用不當的地方歡迎跟我反饋。

以上就是修改Nginx源碼實現worker進程隔離實現詳解的詳細內容，更多關于Nginx worker 進程隔離的資料請關注其它相關文章！