背景
最近咱们线上网关替换为了 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+ 的推迟。
当时临时想到的办法是修正 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 子进程的伪代码如下:
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” 表示内部阻隔进程。
static void
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);
}
}
// ...
}
随后在 ngx_worker_process_cycle
的逻辑对第 0 号 worker 做特别处理,这儿的 demo 运用 18080、18081、18082 作为阻隔端口示意。
static void
ngx_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 process
void
ngx_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
封闭一切的阻隔端口,只保存正常事务端口监听,简化后的代码如下。
void
ngx_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:18080
top -p 3355,3356,3357,3358,3359
能够看到此刻只有 3355 这个 isolation process 被跑满。
接下来看看非阻隔端口恳求,是否只会跑满其它四个 woker process。
ab -n 10000 -c 10 localhost:28080
top -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 源码的浅显了解做的改动,假如有运用不当的地方欢迎跟我反馈。