Vollständige Schritte zum Bereitstellen einer Front-End- und Back-End-getrennten Nginx-Konfiguration

Vorwort

Es ist ein Klischee. Hier werde ich über mein Verständnis der Trennung von Front-End und Back-End sprechen. Eine einfache Trennung ist nichts anderes als das Entfernen der ursprünglichen MVC-Ansichtsebene und deren Umwandlung in einen unabhängigen Servlet-Dienst. Die Servlets sind über http verbunden. Der Ansichts-Servlet-Container kann hier jeder beliebige serverseitige Dienst sein, beispielsweise Tomcat, Apache, Nginx oder IIS. Hier nehmen wir das häufig verwendete Nginx als Beispiel, um eine kurze Einführung zu geben.

Bedarfsanalyse

Beginnen wir mit einer Bedarfsanalyse.

• Einzelprojekt
  • Ein einzelnes Projekt bedeutet, dass ein Front-End-Dienst auf einem Server bereitgestellt wird, wodurch www.xxx.com => index.html zu einem einzelnen Punkt wird.
• Mehrere Projekte
  • Multiprojekt bedeutet, dass ein Server mit mehreren Front-End-Diensten eingesetzt wird, sodass www.xxx.com/a => a.html, www.xxx.com/b => b.html usw. auf mehrere Sites verweisen können.
• Fordern Sie einen Agenten an.
• Neuschreiben der Cookie-Domäne.
• Cookie-Pfad überschreiben.

Tipp: Besser ist es, hier conf.d/*.conf zu schreiben, damit die Konfiguration separat bearbeitet werden kann.

Öffentliche Konfiguration

Server{
 listen 80; # Port server_name _ konfigurieren; # Domänennamen konfigurieren charset utf-8; # Kodierung access_log /xxx/log/nginx_access.log main; # Erfolgsprotokoll error_log /xxx/log/nginx_error.log error; # Fehlerprotokoll index index.html; # Dateireihenfolge für die Suche festlegen $root /xxx/nginx/; # Variableneinstellung, öffentlichen Pfad festlegen # Anderer Speicherort
}

Bitte erstellen Sie manuell entsprechende Dateien unter /xxx/log/nginx_access.log und /xxx/log/nginx_error.log. Beim ersten Ausführen von Nginx Reload kann ein Fehler auftreten.

Der $root-Pfad von set ist ein absoluter Pfad und access_log und error_log sind ebenfalls absolute Pfade.

Einzelprojektkonfiguration

Verzeichnisstruktur

nginx
|----- index.html
|----- benutzer.html

Standortkonfiguration

Standort / {
	Wurzel $root;
}

Die einfachste Konfiguration auf Basis des Stammpfads sieht folgendermaßen aus. Dabei muss lediglich ein Pfad über den Standort konfiguriert und dann auf die Datei index.html im Ordner $root verwiesen werden.

Multiprojektkonfiguration

Verzeichnisstruktur

nginx
|----- ein
    |----- index.html
|----- b
    |----- index.html

Mehrere Standortkonfigurationen

Standort ^~ /a {
  Alias ​​$root/a;
}

Standort ^~ /b {
  Alias ​​$root/b;
}

Standort / {
  Wurzel $root;
}

Der einzige Unterschied zwischen den Nachahmerprojekten ist der Unterschied zwischen Root und Alias. Root bezieht sich auf den absolut passenden Pfad der Datei, während Alias ​​eine relative Übereinstimmung ist. Root kann in http, Server und Standort konfiguriert werden, während Alias ​​nur im Standort konfiguriert werden kann. Ich habe auch den regulären Ausdruck ^~ hinzugefügt. Beim Abgleichen von /a oder /b muss der tatsächliche Pfad der Ressource der durch den Alias ​​angegebene Pfad sein, unabhängig vom Standortpfad. Auf diese Weise kann ich dafür sorgen, dass /a und /b übereinstimmende Pfade haben und zu festen Pfaden springen. Dies ist in Front-End-Projekten im SPA-Stil sehr nützlich, da es tatsächlich nur eine index.html-Datei als Kerndatei gibt (Ressourcendateien sind eine andere Sache). Auf diese Weise kann ich immer zu index.html springen, um sicherzustellen, dass der Browser beim manuellen Aktualisieren nicht basierend auf dem Stammpfad in anderen Pfaden des Servers nach Ressourcen sucht. Legen Sie dann den Stammpfad von Spa fest, und /b muss übereinstimmen.

Warum besteht eine solche Nachfrage? Das Front-End ist leichtgewichtig und wir verwenden diesen Mechanismus, um Server zu sparen und den gleichen Geschäftstyp zu aggregieren. Genauso wie Sie admin.xxxx.com/a => Operations Management Desk und admin.xxxx.com/b => ERP Management Desk möchten. Wir müssen nur den Unterpfad unter dem Administratordomänennamen ausschneiden. Einfach und leicht.

Weiterleitung der Anfrage

Standort ^~ /api {
  Proxy-Passwort http://api.xxx.com/;
}

Das ist ganz einfach. Ich vergleiche die /api-Anfrage mit einem regulären Ausdruck und leite die Anfrage über das Attribut proxy_pass an http://api.xxx.com weiter. Du kannst

Cookiedomäne ändern

Manchmal legen wir aus Sicherheitsgründen bestimmte Cookie-Domänenattribute fest, was für die Nginx-Weiterleitung nicht besonders benutzerfreundlich ist. Natürlich gibt es eine Lösung, und sie ist ganz einfach.

Standort {
  proxy_cookie_domain <Domäne dieser Domäne> <Domäne, die Sie ändern möchten>;
}

Ändern des Cookie-Pfads

Wenn wir zur API-Schnittstelle zurückleiten, kann der API-Domänenname manchmal das Cookie nicht abrufen. Neben der Domäne besteht auch die Möglichkeit des Cookie-Pfads. Natürlich ist die Lösung einfach

Standort {
  proxy_cookie_path <Pfad dieser Domäne> <zu ändernder Pfad>;
}

Nachträgliche Optimierung

Dies ist nur das einfachste Beispiel für eine Nginx-Konfiguration. Es gibt auch Konfigurationen wie das Aktivieren von GZIP, Cache-Einstellungen, Plug-Ins zum Zusammenführen von Ressourcenanforderungen, das Festlegen von 50x- und 40x-Seiten, das Beurteilen von Sprüngen auf Mobilgeräten und PCs usw. Nginx ist immer noch sehr leistungsstark.

Zusammenfassen

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, dass der Inhalt dieses Artikels einen gewissen Lernwert für Ihr Studium oder Ihre Arbeit hat. Vielen Dank für Ihre Unterstützung von 123WORDPRESS.COM.