最近、オンライン ゲートウェイが APISIX に置き換えられ、いくつかの問題が発生しました。解決がより困難な問題の 1 つは、APISIX のプロセス分離問題です。
APISIX さまざまな種類のリクエストの相互影響
最初に遭遇したのは、APISIX Prometheus プラグインが通常のビジネス インターフェイスの応答に影響を与えるという問題でした。監視データが多すぎました。 Prometheus プラグインが有効になっている場合、APISIX によって内部的に収集された監視情報を HTTP インターフェイス経由で取得し、特定のダッシュボードに表示できます。
curl http://172.30.xxx.xxx:9091/apisix/prometheus/metrics
当社のゲートウェイに接続されているビジネス システムは非常に複雑で、ルートが 4000 あります。Prometheus プラグインがプルされるたびに、メトリクスの数は 500,000 を超え、サイズは 80M を超えます。この部分の情報が必要です。 lua 層でアセンブルされて送信されます。リクエストが行われると、このリクエストを処理するワーカー プロセスの CPU 使用率が非常に高くなり、処理時間が 2 秒を超えるため、このワーカー プロセスに 2 秒の遅延が発生します。通常のビジネスリクエストを処理するため。 [推奨事項: 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 の問題 (github.com/apache/apis…) について相談した結果、APISIX が商用バージョンでこの機能を提供していることがわかりました。私はまだオープンソースバージョンを直接使用したいので、この問題は当面は回避できるため、これ以上は掘り下げません。
しかし、その後、別の問題が発生しました。つまり、ビジネスのピーク時に Admin API の処理が間に合わなかったのです。バージョンの切り替えには Admin API を使用しますが、ビジネスのピーク時には APISIX の負荷が高く、管理関連のインターフェイスに影響を及ぼし、バージョン切り替えでタイムアウト エラーが発生することがありました。
ここでの理由は明らかであり、影響は双方向です。以前の 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 に基づいて拡張され、権限が追加されていることを知っておく必要があります
特権エージェント 特権プロセスはポートをリッスンせず、外部にサービスを提供しません。主にスケジュールされたタスクなどに使用されます。
私たちが行う必要があるのは、APISIX 内のリクエストを特に処理するために 1 つ以上のワーカー プロセスを追加することです。
Nginx はマルチプロセス モードを採用しており、マスター プロセスはバインドを呼び出してソケットをリッスンします。 fork 関数によって作成されたワーカー プロセスは、これらのリッスン状態のソケット ハンドルをコピーします。
Nginx ソース コードでワーカーの子プロセスを作成するための疑似コードは次のとおりです:
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 进程的无限循环
}
}変更する必要があるのは、さらに 1 つまたは N 個のプロセスを開始することです。 for ループ プロセス内のワーカー。特定のポートに対するリクエストを処理するように特別に設計されています。
ここのデモでは、ワーカー プロセスの起動を例にしています。ngx_start_worker_processes の変更ロジックは次のとおりです。ワーカー プロセスをもう 1 つ起動します。コマンド名は内部分離プロセスを示す「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 に対して特別な処理を実行します。ここでのデモでは、分離ポートとして 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);
}
}2 つの新しいメソッドがここに書かれています
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;
}効果検証
ここでは、18080 ～ 18082 のポートを分離ポート検証として使用し、その他のポートを通常のビジネス エンド ポートとして使用します。リクエストが高い CPU を占有する状況をシミュレートするために、ここでは lua を使用して sqrt を複数回計算し、Nginx のワーカー ロード バランシングをより適切に検証します。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 ソース コードを通じてワーカー プロセスの分離を実装する方法の詳細な分析の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
