Operasi Middleware Nginx dan Gerbang API: Panduan Prestasi Mendalam

Senario

Bayangkan anda menguruskan persekitaran pengeluaran dengan seni bina mikroservis, dan Nginx menjadi titik masuk bersatu untuk semua permintaan API. Pada waktu puncak perniagaan, pengguna mula mengadu bahawa sesetengah titik akhir mempunyai masa tindak balas yang melonjak daripada 200ms kepada lebih 5 saat, dan sesetengahnya tamat masa. Pemeriksaan awal menunjukkan penggunaan CPU nod Nginx kekal melebihi 90%, dan baris gilir sambungan semakin bertambah.

Gejala

• Kependaman tinggi: Purata masa tindak balas API meningkat dengan ketara, dan kependaman p99 melebihi ambang toleransi perniagaan.
• Kadar ralat meningkat: Sebilangan besar ralat 504 Gateway Timeout dan 502 Bad Gateway muncul.
• Kelainan sambungan: Sambungan aktif Nginx menghampiri had max_connections, dan banyak sambungan berada dalam keadaan menunggu.
• Tekanan sumber: Proses pekerja Nginx menggunakan CPU yang tinggi, dan purata beban sistem melebihi bilangan teras.
• Ketidakseimbangan beban backend: Sesetengah perkhidmatan hulu mempunyai masa tindak balas yang sangat panjang atau bahkan tamat masa.

Diagnosis

1. Sahkan Punca Gejala

Mula-mula, periksa log ralat Nginx dan log akses untuk mengenal pasti laluan permintaan tertentu dan status tindak balas hulu yang menyebabkan ralat.

# Log ralat (biasanya /var/log/nginx/error.log)
tail -n 100 /var/log/nginx/error.log

# Log akses, tapis ralat 5xx
grep ' 5[0-9][0-9] ' /var/log/nginx/access.log | tail -n 100

Jika log mengandungi upstream timed out (110: Connection timed out), ia menunjukkan tamat masa rangkaian antara Nginx dan perkhidmatan backend.

2. Periksa Status Sambungan Secara Langsung

Nginx menyediakan modul stub_status untuk mendapatkan keadaan sambungan semasa. Pastikan ia diaktifkan dalam konfigurasi anda:

location /nginx_status {
    stub_status;
    allow 127.0.0.1;  # Hadkan akses untuk mengelakkan pendedahan maklumat dalaman
    deny all;
}

Kemudian jalankan:

curl http://127.0.0.1/nginx_status
# Contoh output:
# Active connections: 1234
# server accepts handled requests
#  567890 567890 567890
# Reading: 5 Writing: 30 Waiting: 1199

Jika kiraan Waiting kekal tinggi, ia menunjukkan banyak sambungan dalam keadaan terbiar, mungkin disebabkan tetapan keepalive yang tidak betul.

3. Periksa Kesihatan Upstream Backend

Gunakan curl untuk menguji masa tindak balas setiap hulu:

for url in http://service1:8080/health http://service2:8080/health; do
  echo "$url: $(curl -o /dev/null -s -w '%{http_code} %{time_total}\n' $url)"
done

Juga periksa log perkhidmatan backend untuk pertanyaan perlahan atau kesesakan sumber.

4. Analisis Prestasi Sistem

# Penggunaan CPU dan memori
top -bn1 | head -n 20

# Status sambungan rangkaian
ss -s

# Perhatikan keadaan proses pekerja
ps aux | grep nginx

Jika nginx: worker process menggunakan CPU tinggi dan setiap pekerja hampir 100%, ia mungkin disebabkan penyulitan TLS yang intensif CPU atau logik routing.

5. Periksa Konfigurasi Kernel dan Nginx

# Had deskriptor fail
ulimit -n

# Panjang baris gilir sambungan TCP
cat /proc/sys/net/core/somaxconn

# Tetapan Nginx semasa
ginx -T | grep -E 'worker_processes|worker_connections|keepalive|proxy_read_timeout'

Arahan dan Tindakan

1. Laraskan Konfigurasi Nginx dengan Selamat

Sebelum membuat perubahan, sandarkan konfigurasi sedia ada:

cp -r /etc/nginx /etc/nginx.bak.$(date +%Y%m%d%H%M%S)

Ubah suai parameter utama, contohnya:

events {
    worker_connections 10240;
    use epoll;
}

http {
    keepalive_timeout 65;
    keepalive_requests 1000;
    proxy_connect_timeout 5s;
    proxy_read_timeout 30s;
    proxy_send_timeout 30s;
    upstream backend {
        server service1:8080 max_fails=3 fail_timeout=30s;
        server service2:8080 max_fails=3 fail_timeout=30s;
        keepalive 32;  # Bilangan sambungan keepalive terbiar ke hulu
    }
}

Fokus utama: - worker_processes biasanya ditetapkan kepada bilangan teras CPU untuk mengelakkan pertukaran konteks yang berlebihan. - worker_connections perlu diselaraskan berdasarkan had deskriptor fail sistem dan konkurensi sebenar. - Menggunakan model peristiwa epoll meningkatkan prestasi. - Aktifkan kumpulan sambungan keepalive untuk hulu bagi mengurangkan overhed jabat tangan TCP.

Selepas pengubahsuaian, uji konfigurasi:

nginx -t

Jika ujian lulus, lakukan muat semula secara beransur:

nginx -s reload

Nota Keselamatan: nginx -s reload tidak mengganggu sambungan sedia ada dan selamat. Walau bagaimanapun, jika sintaks konfigurasi tidak sah, jangan paksa muat semula; betulkannya dahulu.

2. Laksanakan Had Kadar dan Penampan

Jika gerbang API menghadapi lonjakan trafik, anda boleh buat sementara waktu mengaktifkan had kadar:

limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;

location /api/ {
    limit_req zone=api_limit burst=20 nodelay;
    proxy_pass http://backend;
}

Tetapkan penampan proksi yang munasabah untuk mengelakkan kehabisan memori:

proxy_buffering on;
proxy_buffer_size 4k;
proxy_buffers 8 4k;
proxy_busy_buffers_size 8k;

Kawalan Risiko

• Pelepasan Canary: Sahkan perubahan konfigurasi pada sebahagian nod atau dalam persekitaran pementasan dahulu, kemudian lancarkan ke pengeluaran setelah mengesahkan tiada anomali.
• Kesiapan Pengembalian: Simpan versi konfigurasi sebelumnya. Jika kadar ralat melonjak selepas muat semula, anda boleh segera menjalankan nginx -s reload untuk membuat pengembalian (memerlukan kandungan konfigurasi lama disimpan).
• Pemantauan dan amaran: Semasa operasi, pantau erat metrik utama seperti sambungan aktif, kadar ralat, dan masa tindak balas backend. Tetapkan amaran ambang—contohnya, cetuskan amaran jika kadar ralat melebihi 1% atau kependaman p99 melebihi 500ms.
• Elakkan penalaan berlebihan: Ubah suai hanya satu parameter pada satu masa, dan buat keputusan berdasarkan data yang boleh diukur untuk mengelakkan tingkah laku yang tidak dapat diramalkan.

Pengembalian

Jika masalah bertambah buruk selepas muat semula, atau ralat baru muncul (contohnya, sambungan ditolak), gunakan konfigurasi sandaran untuk membuat pengembalian:

# Pulihkan sandaran
cp /etc/nginx.bak/nginx.conf /etc/nginx/nginx.conf
# Uji dan muat semula
nginx -t && nginx -s reload

Jika konfigurasi itu sendiri tidak bermasalah tetapi proses Nginx ranap, anda boleh melaksanakan:

ginx -s quit   # Keluar secara beransur, menunggu semua permintaan selesai
systemctl restart nginx

Nota Keselamatan: Jangan gunakan nginx -s stop untuk penamatan paksa, kerana ia mungkin menggugurkan permintaan yang sedang diproses.

Pengesahan

• Pengesahan fungsi: Gunakan curl untuk menguji beberapa titik akhir API penting, mengesahkan respons normal dan bebas daripada ralat 5xx.
• Pengesahan prestasi: Jalankan curl -w semula untuk mengukur masa tindak balas, atau gunakan Apache Bench (ab) untuk ujian beban mudah: bash ab -n 1000 -c 100 https://your-gateway/api/health
• Pengesahan log: Periksa sama ada log ralat mempunyai entri baru, dan perhatikan taburan masa tindak balas dalam log akses.
• Metrik pemantauan: Sahkan bahawa sambungan aktif telah menurun, dan penggunaan CPU telah kembali ke tahap normal.

Bila Perlu Menghantar Tiket OpsGlobal

Jika isu prestasi masih tidak diselesaikan selepas mengikuti langkah-langkah di atas, atau mana-mana situasi berikut timbul, kami mengesyorkan menghantar tiket OpsGlobal dengan segera:

• Penalaan parameter kernel: Perlu mengubah suai parameter peringkat sistem seperti net.ipv4.tcp_tw_reuse atau net.core.somaxconn, tetapi tidak pasti kesannya terhadap perniagaan peringkat lebih tinggi.
• Isu seni bina: Contohnya, perkhidmatan hulu menghadapi kehabisan kolam sambungan, memerlukan ujian beban untuk menilai kapasiti atau mereka bentuk strategi pengimbangan beban yang lebih kompleks.
• Keperluan keselamatan dan pematuhan: Perlu meningkatkan peraturan WAF tanpa menjejaskan prestasi, atau mengkonfigurasi pengesahan bersama mTLS.
• Kesesakan prestasi yang berterusan: Selepas pelbagai pelarasan konfigurasi, keperluan SLA masih tidak dapat dipenuhi; analisis prestasi profesional dan cadangan penalaan diperlukan.

Pasukan pakar SRE OpsGlobal menyediakan sokongan jauh 24×7 dan boleh membantu anda dengan profil prestasi mendalam, pengoptimuman konfigurasi, dan pemulihan bencana, memastikan gerbang API anda berjalan dengan stabil dan cekap.

Artikel ini ditulis oleh pasukan teknikal OpsGlobal. Kami pakar dalam perkhidmatan sokongan operasi DevOps/SRE komersial untuk membantu anda menangani cabaran infrastruktur.