最近我們線上網關替換為了 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 的延遲。 【推薦：Nginx教學】
當時臨時想到的措施是修改Prometheus 插件，減少採集發送的範圍和數量，先臨時繞過了此問題。經過 Prometheus 插件擷取資訊的分析，擷取的資料條數如下。
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
結合我們業務實際需要，去掉了部分訊息，減少了部分延遲。
接著經 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 号 worker ngx_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
##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; }
這裡我們使用 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 do sum = sum + math.sqrt(i) end ngx.say(sum) } } }
可以看到现在已经启动了 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進程隔離的詳細內容。更多資訊請關注PHP中文網其他相關文章！
