Nginx sebagai API Gateway: Amalan Mendalam dalam Penyelesaian Masalah Prestasi
Senario
Di OpsGlobal, kami sering melihat pelanggan menggunakan Nginx sebagai gerbang API di hadapan perkhidmatan mikro mereka. Persediaan biasa melibatkan Nginx menamatkan TLS, menghalaan permintaan ke perkhidmatan upstream, dan mengendalikan had kadar atau cache. Baru-baru ini, salah seorang pelanggan kami melaporkan bahawa kependaman API mereka melonjak dari 50 ms kepada lebih 2 saat, dan mereka melihat 504 Gateway Timeout berselang semasa waktu puncak perniagaan.
Gejala
- Kependaman respons meningkat (kependaman p95 meningkat tiga kali ganda)
- Ralat 504 daripada Nginx apabila upstream gagal bertindak balas dalam had masa lalai
- Sambungan worker Nginx mencapai had
worker_connections - Penggunaan CPU perkhidmatan upstream tinggi tetapi tidak tepu
- Tiada perubahan kod atau peristiwa penggunaan yang jelas
Diagnosis
Kami bermula dengan memeriksa asas:
-
Periksa log ralat Nginx
tail -f /var/log/nginx/error.logCariupstream timed outatauno live upstreams. -
Periksa log akses untuk permintaan perlahan Kami membolehkan
$request_timedan$upstream_response_timedalam format log. Arahan untuk mengonfigurasi dan melihat log. -
Sahkan konfigurasi Nginx:
nginx -tdannginx -Tuntuk membuang konfigurasi penuh. -
Uji sambungan dan masa ke upstream: Gunakan
curl -wuntuk mengukur DNS, sambungan, TLS, TTFB, dan masa keseluruhan. -
Periksa statistik kumpulan sambungan:
ss -suntuk melihat statistik soket, juganetstat -an | grep ESTABLISHED | wc -l. -
Ujian beban dengan
wrkatauabuntuk menghasilkan semula di bawah beban terkawal.
Kami mendapati bahawa konfigurasi Nginx mempunyai proxy_connect_timeout dan proxy_read_timeout ditetapkan kepada lalai (60s), tetapi isu sebenar ialah sambungan keepalive upstream tidak dikonfigurasi dengan betul. Blok upstream tidak mempunyai arahan keepalive, menyebabkan sambungan TCP baharu dan jabat tangan TLS untuk setiap permintaan. Di bawah konkurensi tinggi, ini menambah overhead yang besar.
Arahan yang Digunakan
Berikut adalah arahan utama yang kami gunakan semasa diagnosis dan pembetulan:
Periksa log ralat
tail -f /var/log/nginx/error.log
Periksa log akses dengan masa
Definisi format log akses:
log_format timed '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'$request_time $upstream_response_time';
Kemudian lihat log:
tail -f /var/log/nginx/access.log | awk '$10 > 2 {print}'
(andaikan medan 10 ialah request_time)
Sahkan konfigurasi
nginx -t
nginx -T
Masa curl
curl -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://api.example.com/health
Statistik soket
ss -s
ss -tn state established '( dport = :443 or sport = :443 )' | wc -l
Ujian beban dengan wrk
wrk -t8 -c200 -d30s https://api.example.com/health
Pelaksanaan Pembetulan dengan Kawalan Risiko
Kami membuat perubahan berikut:
- Aktifkan keepalive upstream:
upstream backend {
server api1:8080 weight=3;
server api2:8080 weight=2;
keepalive 32;
}
- Laraskan tetapan HTTP Nginx:
http {
upstream backend {
server api1:8080;
keepalive 32;
}
server {
listen 443 ssl;
location /api/ {
proxy_pass http://backend;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_connect_timeout 5s;
proxy_read_timeout 10s;
proxy_send_timeout 10s;
proxy_buffering off; # hanya jika perlu
}
}
}
proxy_http_version 1.1diperlukan untuk keepalive ke upstream.- Kepala
Connectionkosong. - Kurangkan masa tamat untuk mengelakkan penggantungan yang berpanjangan.
- Laraskan proses/sambungan worker:
- Tetapkan
worker_processes auto;untuk sepadan dengan teras CPU. - Tingkatkanworker_connectionskepada 4096 atau lebih tinggi. - Laraskankeepalive_timeoutuntuk sambungan klien.
Sebelum menggunakan, kami:
- Membuat sandaran konfigurasi asal: cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak
- Menguji dalam persekitaran staging yang mencerminkan produksi.
- Mengesahkan dengan nginx -t sebelum muat semula.
Kami menggunakan nginx -s reload untuk muat semula secara lembut, yang mencipta worker baharu dan mengosongkan sambungan lama.
Strategi Rollback
Sekiranya perubahan menyebabkan masalah:
- Pulihkan sandaran:
cp /etc/nginx/nginx.conf.bak /etc/nginx/nginx.conf - Uji:
nginx -t - Muat semula:
nginx -s reload
Jika isu kritikal, kita boleh bertukar dengan cepat ke konfigurasi lama menggunakan symlink jika pelbagai versi disimpan.
Pengesahan dan Keputusan
Selepas muat semula, kami memantau log ralat, log akses, dan metrik luaran (cth., Datadog).
tail -f /var/log/nginx/error.logmenunjukkan tiada lagi ralat tamat masa.- Penanda aras
wrkmenunjukkan peningkatan 40% dalam daya pemprosesan dan kependaman. - Statistik soket
ss -smenunjukkan kurang sambungan TCP baharu kerana keepalive digunakan semula. - Kependaman p95 pelanggan kami turun kembali kepada ~80 ms.
Bila Perlu Menghantar Tiket OpsGlobal
Tahap penyelesaian masalah ini selalunya dapat dicapai oleh pasukan DevOps dalaman. Walau bagaimanapun, jika anda melihat mana-mana yang berikut, sudah tiba masanya untuk menghubungi OpsGlobal:
- Anda tidak biasa dengan dalaman Nginx atau tidak selesa mengedit konfigurasi produksi.
- Isu berterusan selepas penalaan asas dan mungkin memerlukan parameter kernel (cth.,
tcp_tw_reuse,somaxconn) atau penalaan peringkat sistem. - Anda perlu menskalakan gerbang secara mendatar dan memerlukan kepakaran dalam reka bentuk pengimbang beban atau integrasi service mesh.
- Gejala menunjukkan upstream yang bermasalah, dan anda memerlukan bantuan untuk menjejak atau menginstrumentasikan perkhidmatan mikro anda.
OpsGlobal menawarkan sokongan 24/7. Kami boleh mengambil alih tindak balas insiden, menjalankan audit prestasi yang mendalam, dan melaksanakan perubahan produksi yang mantap dengan pelan rollback yang sesuai.
Senario Penggunaan
Sesuai untuk pasukan yang menyelesaikan isu Performance dan memerlukan aliran kerja yang jelas.
Latar Belakang Masalah
Ketahui cara mendiagnosis dan menyelesaikan kekangan prestasi dalam gerbang API berasaskan Nginx, dengan arahan praktikal, kawalan risiko, dan strategi rollback.
Langkah Penyelesaian
Sahkan impak dan perubahan terkini, kumpul log, konfigurasi dan metrik, kemudian baiki mengikut risiko.
Contoh Arahan
Gantikan contoh dengan nama sumber sebenar dan simpan kata laluan, token atau kunci dalam pembolehubah persekitaran.
Risiko
Sebelum operasi produksi, semak sandaran, akses, tetingkap perubahan dan pelan rollback.
Pelan Rollback
Simpan konfigurasi dan versi asal; rollback konfigurasi, imej atau perubahan pangkalan data jika metrik tidak normal.
Senarai Serahan
Rekod punca isu, arahan penting, langkah pembaikan, hasil pengesahan dan cadangan susulan.
Perlu bantuan isu teknikal serupa?
Jika pelayan, Kubernetes, Docker, CI/CD, pangkalan data atau pemantauan anda bermasalah, hantar log dan konfigurasi untuk diagnosis jauh.