修改Nginx源码实现worker进程隔离实现详解

杵桩王

背景

最近我们线上网关替换为了 APISIX，也遇到了一些问题，有一个比较难解决的问题是 APISIX 的进程隔离问题。

APISIX 不同种类请求的互相影响

首先我们遇到的就是 APISIX Prometheus 插件在监控数据过多时影响正常业务接口响应的问题。当启用 Prometheus 插件以后，可以通过 HTTP 接口获取 APISIX 内部采集的监控信息然后展示到特定的看板中。

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

复制代码

我们网关接入的业务系统非常繁杂，有 4000+ 路由，每次拉取 Prometheus 插件时，metrics 条数超过 50 万条，大小超过 80M+，这部分信息需要在 lua 层拼装发送，当请求时会造成处理此请求的 worker 进程 CPU 占用非常高，处理的时间超过 2s，导致此 worker 进程处理正常业务请求会有 2s+ 的延迟。

当时临时想到的措施是修改 Prometheus 插件，减少采集发送的范围和数量，先临时绕过了此问题。经过对 Prometheus 插件采集信息的分析，采集的数据条数如下。

1. 407171 apisix_http_latency_bucket
   
2. 29150 apisix_http_latency_sum
   
3. 29150 apisix_http_latency_count
   
4. 20024 apisix_bandwidth
   
5. 17707 apisix_http_status
   
6.   11 apisix_etcd_modify_indexes
   
7.    6 apisix_nginx_http_current_connections
   
8.    1 apisix_node_info

复制代码

结合我们业务实际需要，去掉了部分信息，减少了部分延迟。
然后经 github issue 咨询（github.com/apache/apis… ），发现 APISIX 在商业版本中有提供此功能。因为还是想直接使用开源版本，此问题也暂时可以绕过，就没有继续深究下去。
但是后面又遇到了一个问题，就是 Admin API 处理在业务峰值处理不及时。我们使用 Admin API 来进行版本切换的功能，在一次业务高峰期时，APISIX 负载较高，影响了 Admin 相关的接口，导致版本切换时偶发超时失败。
这里的原因显而易见，影响是双向的：前面的 Prometheus 插件是 APISIX 内部请求影响了正常业务请求。这里的是反过来的，正常业务请求影响了 APISIX 内部的请求。因此把 APISIX 内部的请求和正常业务请求隔离开就显得至关重要，于是花了一点时间实现了这个功能。
上述对应会生成如下的

1. nginx.conf

复制代码

配置示例文件如下。

1. // 9091 端口处理 Prometheus 插件接口请求
   
2. server {
   
3.     listen 0.0.0.0:9091;
   
4.     access_log off;
   
5.     location / {
   
6.         content_by_lua_block {
   
7.             local prometheus = require("apisix.plugins.prometheus.exporter")
   
8.             prometheus.export_metrics()
   
9.         }
   
10.     }
    
11. }
    
12. // 9180 端口处理 admin 接口
    
13. server {
    
14.     listen 0.0.0.0:9180;
    
15.     location /apisix/admin {
    
16.         content_by_lua_block {
    
17.             apisix.http_admin()
    
18.         }
    
19.     }
    
20. }
    
21. // 正常处理 80 和 443 的业务请求
    
22. server {
    
23.     listen 0.0.0.0:80;
    
24.     listen 0.0.0.0:443 ssl;
    
25.     server_name _;
    
26.     location / {
    
27.         proxy_pass  $upstream_scheme://apisix_backend$upstream_uri;
    
28.     access_by_lua_block {
    
29.         apisix.http_access_phase()
    
30.     }
    
31. }

复制代码

修改 Nginx 源码实现进程隔离

对于 OpenResty 比较了解的同学应该知道，OpenResty 在 Nginx 的基础上进行了扩展，增加了 privilege

privileged agent 特权进程不监听任何端口，不对外提供任何服务，主要用于定时任务等。
我们需要做的是增加 1 个或者多个 woker 进程，专门处理 APISIX 内部的请求即可。
Nginx 采用多进程模式，master 进程会调用 bind、listen 监听套接字。fork 函数创建的 worker 进程会复制这些 listen 状态的 socket 句柄。

Nginx 源码中创建 worker 子进程的伪代码如下：

1. void
   
2. ngx_master_process_cycle(ngx_cycle_t *cycle) {
   
3.     ngx_setproctitle("master process");
   
4.     ngx_start_worker_processes()
   
5.         for (i = 0; i < n; i++) { // 根据 cpu 核心数创建子进程
   
6.             ngx_spawn_process(i, "worker process");
   
7.                 pid = fork();
   
8.                 ngx_worker_process_cycle()
   
9.                     ngx_setproctitle("worker process")
   
10.                     for(;;) { // worker 子进程的无限循环
    
11.                         // ...
    
12.                     }
    
13.         }
    
14.     }
    
15.     for(;;) {
    
16.         // ... master 进程的无限循环
    
17.     }
    
18. }

复制代码

我们要做修改就是在 for 循环中多启动 1 个或 N 个子进程，专门用来处理特定端口的请求。
这里的 demo 以启动 1 个 worker process 为例，修改 ngx_start_worker_processes 的逻辑如下，多启动一个 worker process，命令名为 "isolation process" 表示内部隔离进程。

1. static void
   
2. ngx_start_worker_processes(ngx_cycle_t *cycle, ngx_int_t n, ngx_int_t type)
   
3. {
   
4.     ngx_int_t  i;
   
5.     // ...
   
6.     for (i = 0; i < n + 1; i++) { // 这里将 n 改为了 n+1，多启动一个进程
   
7.         if (i == 0) { // 将子进程组中的第一个作为隔离进程
   
8.             ngx_spawn_process(cycle, ngx_worker_process_cycle,
   
9.                               (void *) (intptr_t) i, "isolation process", type);
   
10.         } else {
    
11.             ngx_spawn_process(cycle, ngx_worker_process_cycle,
    
12.                               (void *) (intptr_t) i, "worker process", type);
    
13.         }
    
14.     }
    
15.     // ...
    
16. }

复制代码

随后在

1. ngx_worker_process_cycle

复制代码

的逻辑对第 0 号 worker 做特殊处理，这里的 demo 使用 18080、18081、18082 作为隔离端口示意。

1. static void
   
2. ngx_worker_process_cycle(ngx_cycle_t *cycle, void *data)
   
3. {
   
4.     ngx_int_t worker = (intptr_t) data;
   
5.     int ports[3];
   
6.     ports[0] = 18080;
   
7.     ports[1] = 18081;
   
8.     ports[2] = 18082;
   
9.     ngx_worker_process_init(cycle, worker);
   
10.     if (worker == 0) { // 处理 0 号 worker
    
11.         ngx_setproctitle("isolation process");
    
12.         ngx_close_not_isolation_listening_sockets(cycle, ports, 3);
    
13.     } else { // 处理非 0 号 worker
    
14.         ngx_setproctitle("worker process");
    
15.         ngx_close_isolation_listening_sockets(cycle, ports, 3);
    
16.     }
    
17. }

复制代码

这里新写了两个方法

• 1. ngx_close_not_isolation_listening_sockets

  复制代码
  ：只保留隔离端口的监听，取消其它端口监听
  
• 1. ngx_close_isolation_listening_sockets

  复制代码
  ：关闭隔离端口的监听，只保留正常业务监听端口，也就是处理正常业务
  

1. ngx_close_not_isolation_listening_sockets

复制代码

精简后的代码如下：

1. // used in isolation process
   
2. void
   
3. ngx_close_not_isolation_listening_sockets(ngx_cycle_t *cycle, int isolation_ports[], int port_num)
   
4. {
   
5.     ngx_connection_t  *c;
   
6.     int port_match = 0;
   
7.     ngx_listening_t* ls = cycle->listening.elts;
   
8.     for (int i = 0; i < cycle->listening.nelts; i++) {
   
9.         c = ls[i].connection;
   
10.         // 从 sockaddr 结构体中获取端口号
    
11.         in_port_t port = ngx_inet_get_port(ls[i].sockaddr) ;
    
12.         // 判断当前端口号是否是需要隔离的端口
    
13.         int is_isolation_port = check_isolation_port(port, isolation_ports, port_num);
    
14.         // 如果不是隔离端口，则取消监听事情的处理
    
15.         if (c && !is_isolation_port) {
    
16.             // 调用 epoll_ctl 移除事件监听
    
17.             ngx_del_event(c->read, NGX_READ_EVENT, 0);
    
18.             ngx_free_connection(c);
    
19.             c->fd = (ngx_socket_t) -1;
    
20.         }
    
21.         if (!is_isolation_port) {
    
22.             port_match++;
    
23.             ngx_close_socket(ls[i].fd); // close 当前 fd
    
24.             ls[i].fd = (ngx_socket_t) -1;
    
25.         }
    
26.     }
    
27.     cycle->listening.nelts -= port_match;
    
28. }

复制代码

对应的

1. ngx_close_isolation_listening_sockets

复制代码

关闭所有的隔离端口，只保留正常业务端口监听，简化后的代码如下。

1. void
   
2. ngx_close_isolation_listening_sockets(ngx_cycle_t *cycle, int isolation_ports[], int port_num)
   
3. {
   
4.     ngx_connection_t  *c;
   
5.     int port_match;
   
6.     port_match = 0;
   
7.     ngx_listening_t   * ls = cycle->listening.elts;
   
8.     for (int i = 0; i < cycle->listening.nelts; i++) {
   
9.         c = ls[i].connection;
   
10.         in_port_t port = ngx_inet_get_port(ls[i].sockaddr) ;
    
11.         int is_isolation_port = check_isolation_port(port, isolation_ports, port_num);
    
12.         // 如果是隔离端口，关闭监听
    
13.         if (c && is_isolation_port) {
    
14.             ngx_del_event(c->read, NGX_READ_EVENT, 0);
    
15.             ngx_free_connection(c);
    
16.             c->fd = (ngx_socket_t) -1;
    
17.         }
    
18.         if (is_isolation_port) {
    
19.             port_match++;   
    
20.             ngx_close_socket(ls[i].fd); // 关闭 fd
    
21.             ls[i].fd = (ngx_socket_t) -1;
    
22.         }
    
23.     }
    
24.     cle->listening.nelts -= port_match;
    
25. }

复制代码

如此一来，我们就实现了 Nginx 基于端口的进程隔离。

效果验证

这里我们使用 18080~18082 端口作为隔离端口验证，其它端口作为正常业务端端口。为了模拟请求占用较高 CPU 的情况，这里我们用 lua 来计算多次 sqrt，以更好的验证 Nginx 的 worker 负载均衡。

1. server {
   
2.         listen 18080; // 18081,18082 配置一样
   
3.         server_name localhost;
   
4.         location / {
   
5.             content_by_lua_block {
   
6.                  local sum = 0;
   
7.                  for i = 1,10000000,1 do
   
8.                     sum = sum + math.sqrt(i)
   
9.                  end
   
10.                  ngx.say(sum)
    
11.             }
    
12.         }
    
13. }
    
14. server {
    
15.     listen 28080;
    
16.     server_name localhost;
    
17.     location / {
    
18.         content_by_lua_block {
    
19.              local sum = 0;
    
20.              for i = 1,10000000,1 do
    
21.                 sum = sum + math.sqrt(i)
    
22.              end
    
23.              ngx.say(sum)
    
24.         }
    
25.     }
    
26. }

复制代码

首先来记录一下当前 worker 进程情况。

可以看到现在已经启动了 1 个内部隔离 worker 进程（pid=3355），4 个普通 worker 进程（pid=3356~3359）。
首先我们可以看通过端口监听来确定我们的改动是否生效。

可以看到隔离进程 3355 进程监听了 18080、18081、18082，普通进程 3356 等进程监听了 20880、20881 端口。
使用 ab 请求 18080 端口，看看是否只会把 3355 进程 CPU 跑满。

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

复制代码

可以看到此时只有 3355 这个 isolation process 被跑满。

接下来看看非隔离端口请求，是否只会跑满其它四个 woker process。

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

复制代码

符合预期，只会跑满 4 个普通 worker 进程（pid=3356~3359），此时 3355 的 cpu 使用率为 0。
到此，我们就通过修改 Nginx 源码实现了特定基于端口号的进程隔离方案。此 demo 中的端口号是写死的，我们实际使用的时候是通过 lua 代码传入的。

1. init_by_lua_block {
   
2.     local process = require "ngx.process"
   
3.     local ports = {18080, 18081, 18083}
   
4.     local ok, err = process.enable_isolation_process(ports)
   
5.     if not ok then
   
6.        ngx.log(ngx.ERR, "enable enable_isolation_process failed")
   
7.        return
   
8.     else
   
9.        ngx.log(ngx.ERR, "enable enable_isolation_process success")
   
10.     end
    
11. }

复制代码

这里需要 lua 通过 ffi 传入到 OpenResty 中，这里不是本文的重点，就不展开讲述。

后记

这个方案有一点 hack，能比较好的解决当前我们遇到的问题，但是也是有成本的，需要维护自己的 OpenResty 代码分支，喜欢折腾的同学或者实在需要此特性可以试试。
上述方案只是我对 Nginx 源码的粗浅了解做的改动，如果有使用不当的地方欢迎跟我反馈。
以上就是修改Nginx源码实现worker进程隔离实现详解的详细内容，更多关于Nginx worker 进程隔离的资料请关注脚本之家其它相关文章！

来源:https://www.jb51.net/article/265895.htm
免责声明：由于采集信息均来自互联网，如果侵犯了您的权益，请联系我们【E-Mail:cb@itdo.tech】 我们会及时删除侵权内容，谢谢合作！