修正Nginx源码实现worker进程隔离实现详解
发布时间：2023-02-20 10:34:31 所属栏目：Nginx 来源：互联网
导读：背景 最近我们线上网关替换为了 APISIX，也遇到了一些问题，有一个比较难解决的问题是 APISIX 的进程隔离问题。 APISIX 不同种类请求的互相影响 首先我们遇到的就是 APISIX Prometheus 插件在监控数据过多时影响正常业务接口响应的问题。当启用 Prometheus
|
背景 最近我们线上网关替换为了 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 2 3 4 5 6 7 8 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 配置示例文件如下。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 // 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 子进程的伪代码如下： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 void ngx_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" 表示内部隔离进程。 ngx_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); （编辑：甘南站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
