深析如何通過Nginx原始碼來實現worker程序隔離
背景
最近我們線上閘道器替換為了 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+ 的延遲。【推薦：】
php入門到就業線上直播課：進入學習
Apipost = Postman + Swagger + Mock + Jmeter 超好用的API偵錯工具：
當時臨時想到的措施是修改 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 精簡後的程式碼如下：
// 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 do sum = 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程序隔離的詳細內容，更多請關注TW511.COM其它相關文章！
