Nginx sebagai Gerbang API: Panduan Lapangan untuk Penyelesaian Masalah Prestasi Middleware

Senario

Sebuah platform e-dagang menggunakan Nginx sebagai gerbang API (API gateway), menyalurkan semua permintaan mikroservis melalui lapisan ini. Kebelakangan ini, dengan trafik yang meningkat, gerbang mula menunjukkan kependaman tinggi dan ralat 5xx secara berselang, terutamanya apabila perkhidmatan hulu (upstream) bertindak balas dengan perlahan. Kami ditugaskan untuk menyelesaikan masalah dan menala prestasi middleware gerbang Nginx.

Gejala

• Pelanggan melaporkan masa tindak balas API meningkat daripada purata 200ms kepada 1 saat atau lebih.
• Log ralat Nginx menunjukkan banyak entri upstream timed out dan connection refused.
• Beban sistem menunjukkan penggunaan CPU worker Nginx tinggi, tetapi memori normal.
• Carta pemantauan menunjukkan sambungan aktif menghampiri had worker_connections.

Diagnosis

Mulakan dengan memeriksa konfigurasi dan status runtime Nginx.

1. Pengesahan proses dan konfigurasi Nginx bash nginx -t # Mengesahkan sintaks konfigurasi nginx -V # Menunjukkan pilihan kompilasi dan modul ps aux | grep nginx

2. Analisis log bash tail -f /var/log/nginx/access.log | awk '{print $7, $9, $10, $11}' | sort | uniq -c | sort -nr | head -20 Periksa taburan kod status untuk melihat sama ada 5xx tertumpu. Log ralat biasanya berada di /var/log/nginx/error.log.

3. Semak prestasi respons hulu bash curl -w 'time_total: %{time_total}s time_connect: %{time_connect}s time_ttfb: %{time_starttransfer}s\n' -o /dev/null http://upstream-service/health Perbezaan antara time_connect dan time_ttfb menunjukkan masa pemprosesan hulu. Jika hulu perlahan, isu mungkin bukan pada Nginx.

4. Semak bilangan sambungan dan penggunaan worker bash # Lihat halaman status Nginx (memerlukan konfigurasi stub_status) curl http://localhost/nginx_status # Atau kira sambungan dengan netstat netstat -an | grep :80 | wc -l

5. Tangkapan paket atau log perlahan Jika anda mengesyaki logik middleware (contohnya, rewrite, proxy_pass, had kadar) menyebabkan kelewatan, aktifkan sementara log debug Nginx atau gunakan strace untuk mengesan proses worker.

Arahan

Selepas diagnosis, kami melaksanakan tindakan berikut:

• Tala bilangan proses worker dan had sambungan: Edit nginx.conf, tetapkan worker_processes agar sepadan dengan bilangan teras CPU, dan tingkatkan worker_connections. nginx worker_processes auto; events { worker_connections 4096; }

• Konfigurasi tamat masa hulu dan percubaan semula: Dalam blok location, laraskan proxy_connect_timeout, proxy_send_timeout, dan proxy_read_timeout. Contoh: nginx proxy_connect_timeout 5s; proxy_read_timeout 10s; proxy_send_timeout 10s;

• Aktifkan caching atau mampatan: Jika respons API boleh cache, tambah proxy_cache; aktifkan gzip untuk respons teks untuk mengurangkan saiz penghantaran.

• Semak konfigurasi semasa: bash nginx -T # Dump keseluruhan konfigurasi Simpan dan uji konfigurasi: bash nginx -t && nginx -s reload

Kawalan Risiko

• Sandarkan konfigurasi sebelum muat semula: cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak.
• Elakkan nginx -s stop: Muat semula secara graceful (reload) tidak menggugurkan sambungan.
• Ubah satu parameter pada satu masa: Gunakan ab atau wrk untuk ujian beban selepas setiap perubahan bagi mengesan regresi lebih awal.
• Jika konkurensi sangat tinggi, pertimbangkan untuk melaraskan parameter kernel seperti net.ipv4.ip_local_port_range dan net.core.somaxconn, tetapi ini memberi kesan kepada hos dan perlu dilakukan dengan berhati-hati.

Rollback

Jika perubahan memburukkan keadaan, lakukan rollback:

1. Pulihkan konfigurasi sandaran: bash cp /etc/nginx/nginx.conf.bak /etc/nginx/nginx.conf
2. Sahkan konfigurasi: bash nginx -t
3. Muat semula secara graceful: bash nginx -s reload

Pengesahan

• Semakan fungsi: Panggil API utama dan sahkan kod respons serta kependaman kembali normal.
• Ujian beban: Gunakan ab -n 10000 -c 500 http://your-gateway/api untuk memerhati daya pemprosesan, kependaman, dan kadar ralat.
• Semakan pemantauan: Sahkan sambungan aktif menurun, kadar 5xx rendah, dan entri tamat masa hilang daripada log.

Bila Menghantar Tiket OpsGlobal

Pertimbangkan untuk menghantar tiket ke OpsGlobal apabila:

• Kesuntukan tidak dapat dikenal pasti pada lapisan aplikasi dan mungkin memerlukan penalaan kernel atau peningkatan infrastruktur.
• Pengoptimuman Nginx sahaja tidak dapat memenuhi SLA, dan penyelesaian gerbang yang lebih maju (contohnya, Kong, Envoy) diperlukan.
• Kerjasama pelbagai pasukan diperlukan untuk dasar trafik global atau audit keselamatan.
• Anda memerlukan pemantauan 24/7 dan respons insiden. Pasukan SRE profesional OpsGlobal boleh membantu.