Tempah Konsultasi Hantar Tiket

Nginx sebagai API Gateway: Amalan Mendalam dalam Penyelesaian Masalah Prestasi

Ketahui cara mendiagnosis dan menyelesaikan kekangan prestasi dalam gerbang API berasaskan Nginx, dengan arahan praktikal, kawalan risiko, dan strategi rollback.

Nginx sebagai API Gateway: Amalan Mendalam dalam Penyelesaian Masalah Prestasi
Performance 7min 10 paparan 2026-08-09
NginxAPI GatewayPenalaan PrestasiSREPenyelesaian Masalah

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:

  1. Periksa log ralat Nginx tail -f /var/log/nginx/error.log Cari upstream timed out atau no live upstreams.

  2. Periksa log akses untuk permintaan perlahan Kami membolehkan $request_time dan $upstream_response_time dalam format log. Arahan untuk mengonfigurasi dan melihat log.

  3. Sahkan konfigurasi Nginx: nginx -t dan nginx -T untuk membuang konfigurasi penuh.

  4. Uji sambungan dan masa ke upstream: Gunakan curl -w untuk mengukur DNS, sambungan, TLS, TTFB, dan masa keseluruhan.

  5. Periksa statistik kumpulan sambungan: ss -s untuk melihat statistik soket, juga netstat -an | grep ESTABLISHED | wc -l.

  6. Ujian beban dengan wrk atau ab untuk 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:

  1. Aktifkan keepalive upstream:
upstream backend {
    server api1:8080 weight=3;
    server api2:8080 weight=2;
    keepalive 32;
}
  1. 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.1 diperlukan untuk keepalive ke upstream.
  • Kepala Connection kosong.
  • Kurangkan masa tamat untuk mengelakkan penggantungan yang berpanjangan.
  1. Laraskan proses/sambungan worker: - Tetapkan worker_processes auto; untuk sepadan dengan teras CPU. - Tingkatkan worker_connections kepada 4096 atau lebih tinggi. - Laraskan keepalive_timeout untuk 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.log menunjukkan tiada lagi ralat tamat masa.
  • Penanda aras wrk menunjukkan peningkatan 40% dalam daya pemprosesan dan kependaman.
  • Statistik soket ss -s menunjukkan 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.

Tiket Hubungi WhatsApp Konsultasi