Warum ich Nginx als Backend-Server-Proxy empfehle (Gründeanalyse)

1. Einleitung

Unsere realen Server sollten nicht direkt dem öffentlichen Internet ausgesetzt sein, da es sonst leichter zum Durchsickern von Serverinformationen kommt und wir anfälliger für Angriffe sind. Eine „zivilere“ Lösung ist die Verwendung von Nginx als Reverse-Proxy. Lassen Sie uns heute über einige der Möglichkeiten der Verwendung des Nginx-Reverse-Proxys sprechen. Der Nginx-Proxy kann uns bei der Implementierung vieler sehr effektiver API-Steuerungsfunktionen helfen. Dies erklärt auch, warum ich immer die Verwendung von Nginx als Proxy für unsere Spring Boot-Anwendung empfehle.

2. Welche Funktionen kann Nginx bieten?

Nginx braucht kein großes Lob, es genießt in der Branche breite Anerkennung. Lassen Sie uns darüber sprechen, welche spezifischen Funktionen es erfüllen kann.

2.1 Agentenfähigkeiten

Dies ist die am häufigsten verwendete Funktion auf der Serverseite. Ein Nginx-Server mit einem öffentlichen Netzwerk kann als Proxy für einen realen Server fungieren, der im Intranet mit ihm kommunizieren kann. Sorgen Sie dafür, dass unsere Server nicht direkt der Außenwelt ausgesetzt sind und erhöhen Sie so ihre Widerstandsfähigkeit gegen Risiken.

Angenommen, der Nginx-Server 192.168.1.8 kann mit dem Anwendungsserver 192.168.1.9 im selben Intranetsegment kommunizieren, und der Nginx-Server verfügt über öffentliche Netzwerkfunktionen und bindet das öffentliche Netzwerk an den Domänennamen felord.cn . Die entsprechende Konfiguration unseres Nginx-Proxys ( nginx.conf ) sieht dann wie folgt aus:

 Server {
  hören Sie 80;
  Servername felord.cn;
 # ^~ bedeutet, dass die URI mit einer regulären Zeichenfolge beginnt. Wenn sie übereinstimmt, wird sie nicht weiter übereinstimmen. Kein regulärer Übereinstimmungsort ^~ /api/v1 {
   Proxy_Set_Header Host $host;
   Proxy-Passwort http://192.168.1.9:8080/;
  }
 }

Nach der obigen Konfiguration lautet die tatsächliche Schnittstellenadresse unseres Servers http://192.168.1.9:8080/foo/get und kann über http://felord.cn/api/v1/foo/get aufgerufen werden.

Wenn proxy_pass mit / endet, ist es gleichbedeutend mit dem absoluten Stammpfad und Nginx wird den Pfadteil, der hinsichtlich des Speicherorts übereinstimmt, nicht als Proxy weiterleiten; wenn es nicht mit / endet, wird auch der Pfadteil, der übereinstimmt, als Proxy weitergeleitet.

2.2 Umschreibfunktion

Nginx bietet auch eine rewrite , mit der wir die URI umschreiben können, wenn die Anforderung den Server erreicht. Dies ähnelt der Bedeutung des Servlet-Filters und führt eine Vorverarbeitung der Anforderung durch.

Wenn wir im Beispiel 2.1 bei einer POST-Anforderung den Wert 405 zurückgeben möchten, müssen wir die Konfiguration lediglich wie folgt ändern:

Standort ^~ /api/v1 {
 Proxy_Set_Header Host $host;
 wenn ($request_method = POST){
  Rückgabe 405;
 }
 Proxy-Passwort http://192.168.1.9:8080/;
}

Sie können von Nginx bereitgestellte globale Variablen (wie etwa $request_method in der obigen Konfiguration) oder von Ihnen als Bedingungen festgelegte Variablen verwenden, kombiniert mit regulären Ausdrücken und Flags ( last , break , redirect , permanent ), um die URI-Umschreibung und -Umleitung zu implementieren.

2.3 HTTPS konfigurieren

Viele Studierende haben in der Gruppe gefragt, wie HTTPS in einem Spring Boot-Projekt konfiguriert wird, und ich empfehle immer, hierfür Nginx zu verwenden. Nginx ist viel praktischer als die Konfiguration von SSL in Spring Boot und hat keine Auswirkungen auf unsere lokale Entwicklung. Die HTTPS-Konfiguration in Nginx kann verwendet werden, indem sie wie folgt geändert wird:

http{
 #Dem HTTP-Knotenserver können mehrere Serverknoten hinzugefügt werden{
  #ssl muss auf Port 443 hören, listen 443;
  #Der dem CA-Zertifikat entsprechende Domänenname server_name felord.cn;
  # SSL aktivieren
  SSL aktiviert;
  # Absoluter Pfad des Serverzertifikats ssl_certificate /etc/ssl/cert_felord.cn.crt;
  # Absoluter Pfad des Serverzertifikatschlüssels ssl_certificate_key /etc/ssl/cert_felord.cn.key;
  SSL-Sitzungszeitüberschreitung 5 Min.
  # Protokolltyp ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  # Liste der SSL-Algorithmen SSL_Chiffren ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5:!RC4:!DHE;
  # Ob der Server entscheidet, welcher Algorithmus verwendet wird/aus TLSv1.1 erfordert ssl_prefer_server_ciphers on;
  
  Standort ^~ /api/v1 {
   Proxy_Set_Header Host $host;
   Proxy-Passwort http://192.168.1.9:8080/;
  }
 }
 # Wenn der Benutzer über http zugreift, schreiben Sie es neu und springen Sie direkt zu https. Dies ist ein sehr notwendiger Operationsserver{
  hören Sie 80;
  Servername felord.cn;
  umschreiben ^/(.*)$ https://felord.cn:443/$1 permanent;
 }

}

Um das Benutzererlebnis zu verbessern, wird hier Rewrite verwendet.

2.4 Lastverteilung

Im Allgemeinen wachsen Projekte von klein zu groß. Zu Beginn reicht es aus, einen Server bereitzustellen. Wenn Ihr Projekt mehr Benutzer hat, herzlichen Glückwunsch, denn das bedeutet, dass Ihr Projekt in die richtige Richtung geht. Damit geht jedoch auch der Serverdruck einher. Sie möchten sicherlich nicht die verschiedenen Verluste erleiden, die durch Serverausfallzeiten verursacht werden. Sie müssen die Druckresistenz des Servers schnell verbessern oder Sie möchten Wartungsarbeiten ohne Unterbrechung durchführen, um Geschäftsunterbrechungen zu vermeiden. Dies kann durch Nginx-Lastausgleich erreicht werden und ist sehr einfach. Angenommen, wir stellen drei Knoten felord.cn bereit:

Die einfachste Polling-Strategie

Die einfachste Konfiguration besteht darin, die Anfragen abwechselnd zu versenden:

http {
 
 Upstream-App {
   # Knoten 1
   Server 192.168.1.9:8080;
   # Knoten 2
   Server 192.168.1.10:8081;
   # Knoten 3
   Server 192.168.1.11:8082;
 }
 
 Server {
  hören Sie 80;
  Servername felord.cn;
 # ^~ bedeutet, dass die URI mit einer regulären Zeichenfolge beginnt. Wenn sie übereinstimmt, wird sie nicht weiter übereinstimmen. Kein regulärer Übereinstimmungsort ^~ /api/v1 {
   Proxy_Set_Header Host $host;
   # Lastenausgleich proxy_pass http://app/;
  }
 }
}

Gewichtete Round Robin Strategie

Geben Sie die Abfragewahrscheinlichkeit an. weight ist proportional zur Zugriffsrate und wird verwendet, wenn die Leistung des Back-End-Servers ungleichmäßig ist:

Upstream-App {
  # Knoten 1
  Server 192.168.1.9:8080 Gewicht = 6;
  # Knoten 2
  Server 192.168.1.10:8081 Gewicht = 3;
  # Knoten 3
  Server 192.168.1.11:8082 Gewicht = 1;
}

Die endgültige Anzahl der Anfragebearbeitungen wird im Verhältnis 6:3:1 verteilt. Bei einer einfachen Umfrage kann man davon ausgehen, dass alle Gewichte gleichmäßig durch 1 geteilt sind. Ausfallzeiten beim Polling können automatisch eliminiert werden.

IP-HASH

Hashen Sie die Zugriffs-IP-Adresse, damit jeder Client einen festen Zugriff auf den Server hat. Wenn der Server ausfällt, muss er manuell entfernt werden.

Upstream-App {
  ip_hash;
  # Knoten 1
  Server 192.168.1.9:8080 Gewicht = 6;
  # Knoten 2
  Server 192.168.1.10:8081 Gewicht = 3;
  # Knoten 3
  Server 192.168.1.11:8082 Gewicht = 1;
}

Wenigste Verbindungen

Die Anfrage wird mit weniger Verbindungen an den Server weitergeleitet, wodurch die Serverressourcen voll ausgenutzt werden:

Upstream-App {
  am wenigsten_Verbindung;
  # Knoten 1
  Server 192.168.1.9:8080 Gewicht = 6;
  # Knoten 2
  Server 192.168.1.10:8081 Gewicht = 3;
  # Knoten 3
  Server 192.168.1.11:8082 Gewicht = 1;
}

Andere Methoden

Wir können einige Plug-Ins verwenden, um andere Arten des Lastausgleichs zu implementieren, beispielsweise die Verwendung des Nginx-Upsync-Moduls, um einen dynamischen Lastausgleich zu erreichen. Können wir dies verwenden, um eine Graustufen-Release-Funktion zu entwickeln?

2.5 Strombegrenzung

Durch die Konfiguration von Nginx können wir den Leaky-Bucket-Algorithmus und den Token-Bucket-Algorithmus implementieren, um die Zugriffsgeschwindigkeit zu begrenzen, indem wir die Anzahl der Anfragen pro Zeiteinheit und die Anzahl der Verbindungen gleichzeitig begrenzen. Ich habe diesen Bereich nicht eingehend studiert, deshalb erwähne ich ihn hier nur. Sie können relevante Informationen für Ihre Recherche nachschlagen.

3. Fazit

Nginx ist sehr leistungsstark und wird als Proxy für unsere Back-End-Anwendungen empfohlen. Wir können viele nützliche Funktionen durch Konfiguration implementieren, ohne etwas nicht geschäftsbezogene Logikcodierung durchführen zu müssen. Wenn Sie die Strombegrenzung implementieren und SSL in Spring Boot konfigurieren, ist dies nicht nur problematisch, sondern wirkt sich auch auf die lokale Entwicklung aus. Die Verwendung von Nginx ermöglicht es uns, uns auf das Geschäft zu konzentrieren. Man kann sagen, dass Nginx hier die Rolle eines kleinen Gateways spielt. Tatsächlich basieren viele bekannte Gateways auf Nginx, wie Kong, Orange, Apache APISIX usw. Wenn Sie interessiert sind, können Sie mit der erweiterten Version von Nginx, Openresty, spielen.

Damit ist dieser Artikel darüber, warum ich Nginx als Backend-Server-Proxy empfehle, abgeschlossen. Weitere Informationen zu Nginx als Backend-Server-Proxy finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den verwandten Artikeln weiter unten. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!