登录  /  注册
首页 > 运维 > Nginx > 正文

深析如何通过Nginx源码来实现worker进程隔离

藏色散人
发布: 2022-11-06 16:41:15
转载
1774人浏览过

背景

最近我们线上网关替换为了 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 <p>我们要做修改就是在 for 循环中多启动 1 个或 N 个子进程,专门用来处理特定端口的请求。</p><p>这里的 demo 以启动 1 个 worker process 为例,修改 ngx_start_worker_processes 的逻辑如下,多启动一个 worker process,命令名为 "isolation process" 表示内部隔离进程。</p><pre class="brush:php;toolbar:false">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 <p>随后在 <code>ngx_worker_process_cycle</code> 的逻辑对第 0 号 worker 做特殊处理,这里的 demo 使用 18080、18081、18082 作为隔离端口示意。</p><pre class="brush:php;toolbar:false">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-&gt;listening.elts;    for (int i = 0; i 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 &amp;&amp; !is_isolation_port) {            // 调用 epoll_ctl 移除事件监听
            ngx_del_event(c-&gt;read, NGX_READ_EVENT, 0);
            ngx_free_connection(c);
            c-&gt;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-&gt;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-&gt;listening.elts;    for (int i = 0; i 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 &amp;&amp; is_isolation_port) { 
            ngx_del_event(c-&gt;read, NGX_READ_EVENT, 0);
            ngx_free_connection(c);
            c-&gt;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-&gt;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进程隔离的详细内容,更多请关注php中文网其它相关文章!

智能AI问答
PHP中文网智能助手能迅速回答你的编程问题,提供实时的代码和解决方案,帮助你解决各种难题。不仅如此,它还能提供编程资源和学习指导,帮助你快速提升编程技能。无论你是初学者还是专业人士,AI智能助手都能成为你的可靠助手,助力你在编程领域取得更大的成就。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系admin@php.cn
作者最新文章
最新问题
热门教程
更多>
最新下载
更多>
网站特效
网站源码
网站素材
前端模板
关于我们 免责申明 意见反馈 讲师合作 广告合作 最新更新
php中文网:公益在线php培训,帮助PHP学习者快速成长!
关注服务号 技术交流群
PHP中文网订阅号
每天精选资源文章推送
PHP中文网APP
随时随地碎片化学习
PHP中文网抖音号
发现有趣的

Copyright 2014-2024 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号