Beispiel für die Implementierung des Lastausgleichs mit Nginx+SpringBoot

Einführung in den Lastenausgleich

Bevor wir die Lastausgleichsimplementierung von Nginx vorstellen, wollen wir kurz über die Klassifizierung des Lastausgleichs sprechen, die hauptsächlich in Hardware-Lastausgleich und Software-Lastausgleich unterteilt ist. Beim Hardware-Lastausgleich handelt es sich um ein Gerät, das eine Kombination aus spezialisierter Software und Hardware verwendet. Geräteanbieter bieten vollständige und ausgereifte Lösungen wie F5 an, die in Bezug auf Datenstabilität und -sicherheit sehr zuverlässig sind, aber teurer als Software sind. Der Software-Lastausgleich basiert hauptsächlich auf Software wie Nginx, die einen Nachrichtenwarteschlangenverteilungsmechanismus implementiert.

Vereinfacht ausgedrückt bedeutet Lastenausgleich, viele Anfragen umzuleiten und sie zur Verarbeitung verschiedenen Servern zuzuweisen. Ich habe beispielsweise drei Server, A, B und C, und verwende dann Nginx zum Lastenausgleich mit einer Polling-Strategie. Wenn zu diesem Zeitpunkt 9 Anfragen eingehen, werden diese 9 Anfragen gleichmäßig auf die Server A, B und Cf verteilt, und jeder Server verarbeitet 3 Anfragen. Auf diese Weise können wir die Eigenschaften mehrerer Maschinencluster nutzen, um den Druck auf einen einzelnen Server zu verringern.

Beispieldiagramm der Lastverteilungsimplementierung von Nginx:

Lastausgleichsstrategie

NGINX Open Source unterstützt vier Methoden zum Lastausgleich und NGINX Plus fügt zwei weitere hinzu.

1. Rundenturnier:

Alle Anfragen abfragen und senden. Dies ist die Standardzuweisungsmethode.

Konfigurationsbeispiel für nginx.conf:

stromaufwärts
  Server www.panchengming.com;
  Server www.panchengming2.com;
}

Hinweis: Der oben stehende Domänenname kann auch durch eine IP ersetzt werden.

2. Wenigste Verbindungen:

Senden Sie die Anforderung an den Server mit der geringsten Anzahl aktiver Verbindungen, wobei Sie auch die Servergewichtung berücksichtigen.

Konfigurationsbeispiel für nginx.conf:

stromaufwärts
  am wenigsten_Verbindung;
  Server www.panchengming.com;
  Server www.panchengming2.com;
}

3.IP-Hash:

Der Server, an den die Anfrage gesendet wird, wird durch die IP-Adresse des Clients bestimmt. Zur Berechnung des Hashwertes werden in diesem Fall die ersten drei Bytes der IPv4-Adresse oder die komplette IPv6-Adresse verwendet. Diese Methode stellt sicher, dass Anfragen von derselben Adresse denselben Server erreichen, es sei denn, dieser Server ist nicht verfügbar.

stromaufwärts
   ip_hash;
   Server www.panchengming.com;
   Server www.panchengming2.com;
}

4.Allgemeiner Hash:

Der Server, an den die Anfrage gesendet wird, wird durch einen benutzerdefinierten Schlüssel bestimmt, der eine Textzeichenfolge, eine Variable oder eine Kombination davon sein kann.

	stromaufwärts
	  Hash $request_uri konsistent;
	  Server www.panchengming.com;
    Server www.panchengming2.com;
	}

5. Kürzeste Zeit (nur NGINX Plus)

Für jede Anfrage wählt NGINX Plus den Server mit der niedrigsten durchschnittlichen Latenz und der niedrigsten Anzahl aktiver Verbindungen aus, wobei die niedrigste durchschnittliche Latenz anhand der folgenden Parameter, einschließlich der least_time-Direktive, berechnet wird:

• Header: Der Zeitpunkt, zu dem das erste Byte vom Server empfangen wurde.
• last_byte: Der Zeitpunkt, zu dem die vollständige Antwort vom Server empfangen wurde.
• last_byte inflight: Der Zeitpunkt, zu dem die vollständige Antwort vom Server empfangen wurde.

stromaufwärts
least_time-Header;
Server www.panchengming.com;
Server www.panchengming2.com;
}

6. Zufällig:

Jede Anfrage wird an einen zufällig ausgewählten Server weitergeleitet. Wenn beide Parameter angegeben sind, wählt NGINX zunächst zufällig zwei Server anhand ihrer Servergewichte aus und wählt dann einen davon mit der angegebenen Methode aus.

• least_conn: Mindestanzahl aktiver Verbindungen
• least_time=header (NGINX Plus): Die kürzeste durchschnittliche Zeit zum Empfangen des Antwortheaders vom Server ($upstream_header_time).
• least_time=last_byte (NGINX Plus): Die durchschnittliche Mindestzeit zum Empfangen einer vollständigen Antwort vom Server ($upstream_response_time).

stromaufwärts
zufällig zwei least_time=last_byte;
Server www.panchengming.com;
Server www.panchengming2.com;
}

Nginx+SpringBoot zur Erreichung des Lastausgleichs

Umgebungsvorbereitung

• Hängt von JDK 1.8 oder höher ab;
  
• Hängt von der Nginx-Umgebung ab;
  

Das Projekt hier verwendet ein früheres Springboot-Projekt von mir. Die Projektadresse von SpringBoot lautet: https://github.com/xuwujing/springBoot-study/tree/master/springboot-thymeleaf

Zuerst laden wir das Projekt herunter und geben ein: mvn clean package , um das Projekt in eine JAR-Datei zu packen. Dann legen wir application.properties und dieses JAR-Projekt in einen Ordner, kopieren den Ordner (hier wurde er der Übersichtlichkeit halber kopiert, aber Sie können ihn tatsächlich neu starten, ohne den Port zu ändern) und ändern den Port des kopierten Ordners application.properties beispielsweise in 8086.

Nginx-Konfiguration

Wir suchen die Nginx-Konfigurationsdatei nginx.conf im Verzeichnis nginx/conf/nginx.conf, ändern die Konfiguration und fügen die folgende Konfiguration hinzu:

Upstream-Pancm{
  Server 127.0.0.1:8085;
  Server 127.0.0.1:8086;
}

• Upstream-Pancm: Definieren Sie einen Namen, jeder Name ist in Ordnung;
• Server + IP:Port oder Domänenname;
  

Wenn Sie die Round Robin Strategie nicht nutzen möchten, können Sie auf eine andere Strategie umsteigen.

Fügen Sie dann die folgende Konfiguration auf dem Server hinzu/ändern Sie sie:

 Server {
    hören Sie 80;
    Servername 127.0.0.1;


    Standort / {
      Stamm-HTML;
      Proxy-Passwort http://pancm;
      Proxy-Verbindungs-Timeout 3 s;
      Proxy_Lese-Timeout 5 s;
      Proxy_Sendezeitüberschreitung 3 s;	
      Index Index.html Index.htm;
    }

    Fehlerseite 500 502 503 504 /50x.html;
    Standort = /50x.html {
      Stamm-HTML;
    }
  }

Konfigurationsanleitung:

• Server: der Name des virtuellen Hosts. In einem http können mehrere Server konfiguriert werden.
• hören: Nginx-Standardport;
• server_name: Die Adresse des Nginx-Dienstes. Sie können den Domänennamen verwenden. Mehrere Namen werden durch Leerzeichen getrennt.
• proxy_pass: Proxy-Pfad, im Allgemeinen der Name nach der Upstream-Konfiguration, um einen Lastenausgleich zu erreichen. Sie können die IP direkt für den Sprung konfigurieren.
  

Vollständige Konfiguration von nginx.conf:

Ereignisse {
  Arbeiterverbindungen 1024;
}

Fehlerlog nginx-error.log-Info;
http {
  mime.types einschließen;
  Standardtyp Anwendung/Oktett-Stream;
  sendfile an;
  KeepAlive-Timeout 65;

   Upstream-Pancm{
    Server 127.0.0.1:8085;
    Server 127.0.0.1:8086;
  }
  
  Server {
    hören Sie 80;
    Servername 127.0.0.1;


    Standort / {
      Stamm-HTML;
      Proxy-Passwort http://pancm;
      Proxy-Verbindungs-Timeout 3 s;
      Proxy_Lese-Timeout 5 s;
      Proxy_Sendezeitüberschreitung 3 s;	
      Index Index.html Index.htm;
    }

    Fehlerseite 500 502 503 504 /50x.html;
    Standort = /50x.html {
      Stamm-HTML;
    }
  }
}

Lastausgleichstest

Nachdem wir die Nginx-Konfiguration abgeschlossen haben, starten wir Nginx.
Geben Sie unter Linux /usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf ein. Wenn es gestartet wurde, können Sie den Befehl /usr/local/nginx/sbin/nginx -s reload verwenden, um die Konfigurationsdatei im laufenden Betrieb neu zu laden. Klicken Sie unter Windows direkt im Nginx-Verzeichnis auf nginx.exe oder führen Sie start nginx cmd aus, um es zu starten. Wenn es gestartet wurde, können Sie immer noch nginx -s reload verwenden, um es im laufenden Betrieb neu zu laden.

Nachdem Nginx gestartet ist, starten wir das soeben heruntergeladene Springboot, kopieren nacheinander das Projekt mit dem geänderten Port und geben zum Starten ein: java -jar springboot-jsp-thymeleaf.jar .

Nachdem alles erfolgreich gestartet ist, können wir durch Eingabe der Dienst-IP im Browser darauf zugreifen.

Beispielbild:

Hinweis: Hier verwende ich zum Testen ein Windows-System und das tatsächliche Linux-System ist dasselbe.

Dann machen wir es und prüfen das Konsolenprotokoll!

Aus dem obigen Beispieldiagramm haben wir 4 Schnittstellenaktualisierungsanforderungen gestellt, die schließlich gleichmäßig auf zwei Dienste verteilt wurden. Aus den obigen Testergebnissen haben wir einen Lastenausgleich erreicht.

Hier spreche ich über die Vorsichtsmaßnahmen bei der Verwendung von Nginx. Beim Lernen und Testen gibt es im Allgemeinen kein Problem, den Standardport von Nginx zum Erreichen des Lastenausgleichs zu verwenden. Wenn wir es jedoch in einem Projekt verwenden, insbesondere wenn eine Anmeldeschnittstelle vorhanden ist und der Port nicht 80 ist, kann die Anmeldeschnittstelle nicht umgeleitet werden. Beim Debuggen wird ein Fehler wie net::ERR_NAME_NOT_RESOLVED angezeigt. Der Grund dafür ist, dass der Standardport von Nginx 80 ist und der Standardsprung auch dieser ist. Wenn dies geschieht, müssen Sie daher die Konfiguration proxy_set_header Host $host:port unter Standort hinzufügen, und der Port und der Abhörport müssen konsistent sein.

Oben sind die Einzelheiten des Beispiels von Nginx+SpringBoot zur Erzielung des Lastenausgleichs aufgeführt. Weitere Informationen zur Erzielung des Lastenausgleichs durch Nginx finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!